Problem with HDR panos: bracket shots not well managed
hurodal
This is my first message here. I'm a pro photographer; I did my first
360º pano at 1998 and now I'm doing spherical panos with an RRS VR and
different lenses.
I ussually combine panos with HDR shots, and found that, even shooting
over a solid pro tripod, well leveled, with fixed angle turning, PTGui
doesn't align well HDR brackets. Seems that it doesn't apply the same
image transformation to all the brackets of an individual area of a
pano; it tries to detect points on all of the photos.
The solution is very easy: do equal transformation to all braket
shoots if they are shoot on a tripod (or, at least, the same
tranformation but a very little displacement if all of the brackets
has not absolutely perfect alignment).
Can this be done? Wouldn't be easy that PTGui shows added files (at
the begginning) not in a single row, but into some rows, allowing user
to drag and place brackets over an under the normal shot, so user
tells PTGui what shots has to be proccessed the same way?
Regards,
Joergen Geerds
> I ussually combine panos with HDR shots, and found that, even shooting
> over a solid pro tripod, well leveled, with fixed angle turning, PTGui
> doesn't align well HDR brackets. Seems that it doesn't apply the same
> image transformation to all the brackets of an individual area of a
> pano; it tries to detect points on all of the photos.
when you shoot for HDR, the camera doesn't move between the brackets.
IF the camera moves, then either you are operating handheld, or your
tripod/head isn't all that stable after all.
so in theory, since each bracket matches the rest almost pixel
perfect, you can/should go ahead and link all brackets in ptgui
(images -> link HDR). this lets ptgui transform each tile exactly like
the others.
i hope this solves your problem.
joergen
Tom Sharpless
PTGui offers two HDR alignment modes, 'linked' assumes bracketed image
sets are perfectly aligned and applies the same transformation to all;
'unlinked' tries to align them using independent control points. That
often does not work well, but if you shoot from a stable tripod with
not too long a lens it should never be necessary. So just select
'link the exposures' before aligning.
You can also link and unlink views individually on the 'image
parameters' tab by checking or unchecking in the first column. For
example you can unlink a hand-held nadir shot, or just one view where
the tripod jiggled.
I believe that PTGui will only link images that have consecutive file
names (or timestamps?) and a series of exposures that is repeated in
the pano. But maybe it is even more flexible than that.
Another nice feature of PTGui is that you don't have to take an equal
number of exposures in every part of the picture. I normally shoot 3
autobracketed exposures per view, and those would be linked for
alignment. But I often go back and retake the brightest places with a
4th, shorter exposure. Those images must of course be aligned
'unlinked' since I moved the camera. But PTGui combines them
correctly with the others in either exposure fusion or true HDR mode.
Cheers, Tom
hurodal
Thanks for your answer. I think I didn't explained well (I'm sorry,
english is not my native languaje).
I agree with you, and I do my workflow that way, but results are not
always correct.
I shoot quickly an spherical pano, and I can't imagine how PTGui can
detect which photos join a group of brackets. It doesn't know which is
the sequence I use to bracket (+/0/-, -/0/+ or 0/+/-) and and time
lapses between all photos are very similar (in my case).
So I suggest photos can be manually dragged to let PTGui how is the
whole pano.
Regards,
PTGui Support
this is enough for PTGui to automatically recognize it and will prompt
to link your images.
Linking takes place in the Image Parameters tab: every image for which
the "Link" checkbox is checked is linked to the image directly above it.
So if you for some reason would like to link images manually, the linked
images should be adjacent in the image list.
Linked images share the same yaw, pitch, roll and lens parameters. For
details see the Help of the Image Parameters tab.
Regardless of linking, a full panorama should be shot for each exposure
time. During stitching PTGui groups the images based on the exposure
time, aperture and ISO, and creates a blend plane for each set of images
with identical exposure. This is completely independent from Linking,
i.e. you can create HDR without using linking at all.
More info:
HDR tutorial: http://www.ptgui.com/hdrtutorial.html
HDR Faq #9.x: http://www.ptgui.com/support.html#9_1
Joost
hurodal
I understand you. I use the "linked" option always, but even this way
doesn't work perfectly all times. I didn't know that I could by
checking or unchecking in the first column of that tab. I'll try it
quickly and post some feedback. Do I have to check them before
aligning images, do I?
Some times I do shoot 2 or 3 shots at every rotation, but sometime I
do shot brackets only for the area of the pano that really has HDR.
And for the nadir I normally do not shoot bracket, because it doesn't
need to.
Regards,
>
> - Mostrar texto de la cita -
hurodal
How can I post images?
John Houghton
> A simple question:
>
> How can I post images?
John
hurodal
parameters between brackets. Good!
But another problems remains:
a) PTGui always searchs for control points, and seems never assume a
pano was shooted using VR head. This way there's no need for search
thoroughly for control points, but to trust that individual shots or
groups of brackets were shooted by rotating a fixed angle. Isn't it?
b) HDR blend is soooo smooth, causing objects appears two or three
times when this objects are moving. Specially, trees.
Couldn't be solved easily? I think that a possible way is to:
a) add an option to let user tell that 1) pano is shooted using a VR
head, 2) nodal point has been find and is used and 3) rotation were
done at fixed angles (with or without rotation base).
b1) Add control points only under horizon line (allowing to not create
points on trees, which normally are over the horizon line) or add an
option to delete control points of a pair of images, not the whole
panorama (to allow user quickly delete points of a tree).
b2) Also, and the most important: add functions to control the curve
used to blend HDR. One of them could blend using a quick transition
and not a smooth blend. This way, trees will not become double and
noise at shadows of the underexposed shoot will not "dirt" the
overexposed shoot. The curve should switch from 0 to +2 shots (for
example) quickly, using only highlights (highest EVs) from the 0 shot
and all the rest from the +2 shot.
b3)A function to avoid ghosts of n pixels around one pixel will be so
useful. This way, if a tree is moving by the wind, algorithm will
search if in 10 or 15 pixels it detects movement, and will use only 1
image and not blend the pair of brackets.
regards,
Hugo Rodriguez
Hugo Rodriguez
> -----Mensaje original-----
> De: pt...@googlegroups.com [mailto:pt...@googlegroups.com] En
> nombre de John Houghton
> Enviado el: domingo, 06 de junio de 2010 11:43
> Para: PTGui Support
> Asunto: [PTGui] Re: Problem with HDR panos: bracket shots not
> well managed
> --
> You received this message because you are subscribed to the
> Google Groups "PTGui" group.
> To post to this group, send email to pt...@googlegroups.com
> To unsubscribe from this group, send email to
> ptgui+un...@googlegroups.com
> Please do not add attachments to your posts; instead you may
> upload files at
> http://groups.google.com/group/ptgui/files
> For more options, visit this group at
> http://groups.google.com/group/ptgui
Joergen Geerds
> Some times I do shoot 2 or 3 shots at every rotation, but sometime I
> do shot brackets only for the area of the pano that really has HDR.
> And for the nadir I normally do not shoot bracket, because it doesn't
> need to.
this the the flaw in your process: you need to shoot your HDR pano
with a complete set of brackets, meaning each tile needs to have the
same amount of shots (i.e.). mixing it up will not work, and will give
you a wrong/bad final result. resist the urge to save shots/space/
time, always shoot a compete bracket set for each pano/tile.
since you also have problems with moving objects, here are a couple of
strategies you can try:
1. use an alpha mask (tiff) on each exposure, masking out the moving
object... make sure that the spot you masked exists in the same EV
value in another tile... load brackets into ptgui, and your HDR should
come out perfect.
2. pre-render your bracket set into open-exr (HDRi). photomatix allows
batches for HDRi, and has an option to reduce ghosts (moving objects).
Photoshop CS5 also has the same function.
3. batch pre-enfuse your brackets with enfuseGUI, and mask out the
moving objects. this has also the advantage that you don't have to
deal with bracket sets in ptgui any more, and you can simply render
blended and layers from ptgui, and do additional retouching easy in
photoshop.
good luck
joergen
Erik Krause
> b2) Also, and the most important: add functions to control the curve
> used to blend HDR. One of them could blend using a quick transition
> and not a smooth blend.
This isn't trivial. If the brightness of an object changes gradually,
there would be a step instead of a ghost. You'd need an algorithm to
recognize structures. However, there are specialized programs that try
to achieve this: http://www.fdrtools.com/fdrtools_advanced_e.php
In PTGui you could try exposure fusion instead of true HDR. Exposure
fusion recognizes structures to some extent.
> b3)A function to avoid ghosts of n pixels around one pixel will be so
> useful. This way, if a tree is moving by the wind, algorithm will
> search if in 10 or 15 pixels it detects movement, and will use only 1
> image and not blend the pair of brackets.
The usual solution to this is to output the single bracket layers
together with the panorama (using one of the layered photoshop formats
preferably), then use the respective content from a single bracket layer
painting it's mask in photoshop. To deal with brightness differences you
can use a local "match color" in photoshop.
--
Erik Krause
http://www.erik-krause.de
Bjørn K Nilssen
>
> The usual solution to this is to output the single bracket layers
> together with the panorama (using one of the layered photoshop formats
> preferably), then use the respective content from a single bracket layer
> painting it's mask in photoshop. To deal with brightness differences you
> can use a local "match color" in photoshop.
Can you handle layered HDR images in th standard (non-extended) version of CS5?
In CS3 standard you could only use non-layered HDR images :(
--
Bjørn K Nilssen - http://bknilssen.no - panoramas and 3D
Erik Krause
>> > The usual solution to this is to output the single bracket layers
>> > together with the panorama (using one of the layered photoshop formats
>> > preferably), then use the respective content from a single bracket layer
>> > painting it's mask in photoshop. To deal with brightness differences you
>> > can use a local "match color" in photoshop.
> Can you handle layered HDR images in th standard (non-extended) version of CS5?
> In CS3 standard you could only use non-layered HDR images:(
No idea. However, you would save tone mapped LDR or better use exposure
fusion. In my opinion true HDR is for image based lighting only.
Exposure fused panoramas not only look much better, they are much better
to fix too, since the local contrast isn't exaggerated.
hurodal
Thank you. I understand you perfectly. I shoot not always the same
sequence, because I try to minimize camera handling (to minimize
possible movement when using shutter dial.
I mean: I start doing 0, +2, +4 and then +4, +2, 0. I never shoot +,
0 ,-; always 0 to overexposed, because I first determine exposure to
the right and then I overexpose; this is the best way with RAW.
PTGui Support
> Ok, that checkboxes solved partially the problem of different image
> parameters between brackets. Good!
> But another problems remains:
>
> a) PTGui always searchs for control points, and seems never assume a
> pano was shooted using VR head. This way there's no need for search
> thoroughly for control points, but to trust that individual shots or
> groups of brackets were shooted by rotating a fixed angle. Isn't it?
Sure there is: just skip the Align Images step and go straight to Create
Panorama. To do this you must switch PTGui to Advanced mode first. And
of course you need to position your images first by entering the
coordinates in the Image Parameters tab or by using a template.
> b1) Add control points only under horizon line (allowing to not create
> points on trees, which normally are over the horizon line) or add an
> option to delete control points of a pair of images, not the whole
> panorama (to allow user quickly delete points of a tree).
Might be a good idea in certain cases, I'll keep this in mind.
> b2) Also, and the most important: add functions to control the curve
> used to blend HDR. One of them could blend using a quick transition
> and not a smooth blend. This way, trees will not become double and
> noise at shadows of the underexposed shoot will not "dirt" the
> overexposed shoot. The curve should switch from 0 to +2 shots (for
> example) quickly, using only highlights (highest EVs) from the 0 shot
> and all the rest from the +2 shot.
I don't think this would work; the problem is that your tree consist of
pixels with different brightness, so the HDR merger would still pick
pixels from different blend planes. Automatic ghost removal is
difficult, in particular with moving tree leaves. I'll leave this
challenge to the dedicated HDR applications for now.
Joost
PTGui Support
> I mean: I start doing 0, +2, +4 and then +4, +2, 0.
That's fine but you just will need to link the images yourself, PTGui
won't do this automatically (or worse it might think that you are using
6 image brackets). You can do this with a template.
Joost
Joergen Geerds
> a) PTGui always searchs for control points, and seems never assume a
> pano was shooted using VR head. This way there's no need for search
> thoroughly for control points, but to trust that individual shots or
> groups of brackets were shooted by rotating a fixed angle. Isn't it?
feature, I think I am asking for it now for 12-18 months. I don't
really mind how ptgui is looking for CPs, and even if it has to look
in all image pairings, the actual time it needs is relative little.
although it would help with false-positives.
> b) HDR blend is soooo smooth, causing objects appears two or three
> times when this objects are moving. Specially, trees.
> Couldn't be solved easily?
only using a fairly simple method to de-ghost by letting the user
select his/her favorite exposure... photomatix has it's own method of
de-ghosting, and you can use your own method (i.e. doing a separate
set of HDR/enfused tiles from only 1 exposure (fake HDR/enfusion), and
use those for heavily moving objects. the other method would be
shooting on days with little wind, or embrace the wind (i.e. longer
exposures to get more blur), or actually pay attention to what you are
photographing.
> I think that a possible way is to:
> a) add an option to let user tell that 1) pano is shooted using a VR
> head, 2) nodal point has been find and is used and 3) rotation were
> done at fixed angles (with or without rotation base).
do with your HDR problem, and all of the above are already
systematically build into the panorama-tool paradigm.
> b1) Add control points only under horizon line (allowing to not create
> points on trees, which normally are over the horizon line) or add an
> option to delete control points of a pair of images, not the whole
> panorama (to allow user quickly delete points of a tree).
you). not all CPs in trees are bad (unless your pano has only straw-
like trees like birches in scandinavia in a storm). second, landscapes
are not the only use for ptgui, there are enough people that do
architecture and other things with it (like me). on the other hand,
some sort of lasso functionality for the CPs would be nice to have.
> b2) Also, and the most important: add functions to control the curve
> used to blend HDR. One of them could blend using a quick transition
> and not a smooth blend. This way, trees will not become double and
> noise at shadows of the underexposed shoot will not "dirt" the
> overexposed shoot. The curve should switch from 0 to +2 shots (for
> example) quickly, using only highlights (highest EVs) from the 0 shot
> and all the rest from the +2 shot.
panos. since you don't shoot complete bracket sets, your workflow is
already flawed and can't produce ideal results.
> b3)A function to avoid ghosts of n pixels around one pixel will be so
> useful. This way, if a tree is moving by the wind, algorithm will
> search if in 10 or 15 pixels it detects movement, and will use only 1
> image and not blend the pair of brackets.
since it is already available in other applications that you can use
within the workflow, it wouldn't make sense for joost to waste already
scarce development time on those features. ptgui is not a hdr
tonemapping app, it just offers those features as a convenience, not
as it's main feature.
joergen
Joergen Geerds
> No idea. However, you would save tone mapped LDR or better use exposure
> fusion. In my opinion true HDR is for image based lighting only.
> Exposure fused panoramas not only look much better, they are much better
> to fix too, since the local contrast isn't exaggerated.
extended version does also, but I do not know, since I always owned
the extended versions.
I totally agree with you... for HDR to work as LDR one would need to
have mastered the tonemapping process... and I would say that more
than 95% of everything tonemapped out there is garbage and a waste of
time, and true HDR isn't used as often at the moment as we think.
enfusion does much nicer results.
joergen
Joergen Geerds
> I understand you perfectly. I shoot not always the same
> sequence, because I try to minimize camera handling (to minimize
> possible movement when using shutter dial.
> I mean: I start doing 0, +2, +4 and then +4, +2, 0. I never shoot +,
> 0 ,-; always 0 to overexposed, because I first determine exposure to
> the right and then I overexpose; this is the best way with RAW.
functionality in your camera (together with a wired/IR remote)? Even
if your Nikon does only 1EV steps, you can still shoot 5 brackets to
get to your +-2EV (which is the same as your 0, +2, +4), and discard
the +-1EV brackets since they are not necessary.
If you want to get fancier, you can buy a promote from
promotesystems.com and shoot all the brackets your want.
joergen
Bjørn K Nilssen
Well, I'm one of those few who need the real HDR file, because I need them for 3D work
and IBL.
A long ago I asked for a "feature" that allowed us to save the HDR along with a fused LDR
instead of the tonemapped version, but unfortunately it only made it to the wish list so
far..
Bjørn K Nilssen
> On Jun 6, 11:32 am, Erik Krause <erik.kra...@gmx.de> wrote:
> > No idea. However, you would save tone mapped LDR or better use exposure
> > fusion. In my opinion true HDR is for image based lighting only.
> > Exposure fused panoramas not only look much better, they are much better
> > to fix too, since the local contrast isn't exaggerated.
>
> Photoshop CS5 extended does 32bit layers, I would assume the non-
> extended version does also, but I do not know, since I always owned
> the extended versions.
CS3 extended did HDR layers, but not the standard version.
Adobes site is impossible for finding such "details" as comparisons between versions.
Anybody know where to find such a list with differences between CS5 and CS5 extended?
> I totally agree with you... for HDR to work as LDR one would need to
> have mastered the tonemapping process... and I would say that more
> than 95% of everything tonemapped out there is garbage and a waste of
> time, and true HDR isn't used as often at the moment as we think.
> enfusion does much nicer results.
I totally agree too in that the fused images usually looks better than tonemapped. I
really wish I could get both HDR and fused at the same time, because most of the time
spent could be done once instead of twice.
I really hate it when I have to run that long process twice just because I'm apparently
the only PTgui user that needs both HDR+LDR(fused) :(
BTW, I believe that a lot of the tonemapped stuff looks so great that viewers never think
of them as HDR/tonemapped. What is usually considered tonemapped HDR is when they go
overboard. Lots of "normal" photos may be tonemapped HDR without anyone noticing.
Just take a look at Christian Blochs gallery at :
http://www.hdrlabs.com/gallery/flashpanos.html
to view some panos that certainly don't have that "HDR look", even though they are
tonemapped.
Joergen Geerds
> CS3 extended did HDR layers, but not the standard version.
> Adobes site is impossible for finding such "details" as comparisons between versions.
> Anybody know where to find such a list with differences between CS5 and CS5 extended?
the main feature that makes the extended version is 3D and editing
movies, for the rest I believe that they are identical. Why don't you
use the 30 day trial and check it out? but since you do 3D, the
extended version might be more up your alley.
> BTW, I believe that a lot of the tonemapped stuff looks so great that viewers never think
> of them as HDR/tonemapped. What is usually considered tonemapped HDR is when they go
> overboard. Lots of "normal" photos may be tonemapped HDR without anyone noticing.
> Just take a look at Christian Blochs gallery at :http://www.hdrlabs.com/gallery/flashpanos.html
> to view some panos that certainly don't have that "HDR look", even though they are
> tonemapped.
pleasant/well done/unoffensive. the remaining 95% look unfortunately
like clown vomit.
joergen
hurodal
Well, now I think it's clear that it's not necessary to shoot all
brackets. Using the link function does the job, even if PTGui doesn't
like too much that doesn't exists all brackets.
From a point of view about quality of capture , it's not necessary to
shoot brackets at all angles; only those that have really deep shadows
(assuming you expose to highlights); from a point about things PTGui
like, maybe it's easier to shoot brackets all the time...
Anyway, thanks for you help; I do know and have used those methods,
but none of them satisfy my totally, because all of them makes me
spend a lot of time with every HDR pano. They are very time-consuming.
2) photomatix loose some shadow detail when blending brackets. I don't
like it too much for blending. And usually does not avoid ghosts
properly. I'll upload some screen captures to you to see. They are two
final blends, one with Photomatix and one manually by me. I do blend
to mantain aspect, I don't like too much the "photomatix look". If I
apply levels to both images, you can see the difference in the
shadows. This pair of images shows an easy example: arquitectural,
with no moving elements.
3) If I have to blend manually brackets, I prefer to do it manually in
PS (with an action I developed) and to remap manually, but enfuse does
a good job. But my question is: if I process various brackets with
enfuse using the same parameters, are they easy to stitch after or
this is a nwe problem to PTGui to solve?
Hugo,
Joergen Geerds
> 3) If I have to blend manually brackets, I prefer to do it manually in
> PS (with an action I developed) and to remap manually, but enfuse does
> a good job. But my question is: if I process various brackets with
> enfuse using the same parameters, are they easy to stitch after or
> this is a nwe problem to PTGui to solve?
I am not sure if I follow your correctly, but ptgui has almost never a
problem with pre-enfused tiles, and processes them actually extremely
fast (almost any pano on my websites is enfused (or similar process)).
I assume that ptgui also does a nice job with open-exr files in the
same fashion it handles tiffs, but since i never use HDR, i can't
really tell.
joergen
hurodal
b2) Oh, yes, I know, but I think that is the key to save a lot of time
retouching in photoshop. But it wouldn't be so difficult to add a
function that does search around one pixel if there are changes in the
other shoot related of the same bracket, so it can decide to show the
first or the second shoot, but not to blend both, causing ghosts,
isn't it?
Exposure fusion works very well, but does nothing related to ghosts,
isn't it? (I don't know)
b3) yes, but I'd like to avoid that. I know how to do that, but it
consumes a lot of time and resources of the computer. What I'd like is
to minimize that kind of work.
BTW, I've just uploaded to files section some screen captures of the
difference in shadows between photomatix blend and manual blend (with
an action I developed)
Regards,
Erik Krause
> But it wouldn't be so difficult to add a
> function that does search around one pixel if there are changes in the
> other shoot related of the same bracket, so it can decide to show the
> first or the second shoot, but not to blend both, causing ghosts,
> isn't it?
Unfortunately it isn't that easy. Furthermore it's a specialized thing
that should be left to specialized programs. There are several that
attempt to remove ghosts. Have a look at
http://wiki.panotools.org/HDR_Software_overview
"HDR creation and tonemapping" section.
For outdoor panoramas bracketing isn't always necessary. Sometimes it is
enough to shoot raw with a good DSLR and extract the whole dynamic range
either with some raw converter settings like described here:
http://wiki.panotools.org/RAW_dynamic_range_extraction
or use virtual bracketing.
> Exposure fusion works very well, but does nothing related to ghosts,
> isn't it? (I don't know)
Play with Sigma. It doesn't make a huge difference, but it sometimes is
a bit better.
Hugo Rodriguez
1 EV steps are unuseful with digital raw capture... I hope brands do change
them quickly.
As I use a quite firmly tripod and head, I do it manually with care.
I knew promote; it's funny, but expensive and another gadget to carry. No,
thanks ;-)
Hugo
> -----Mensaje original-----
> De: pt...@googlegroups.com [mailto:pt...@googlegroups.com] En
> nombre de Joergen Geerds
> Enviado el: domingo, 06 de junio de 2010 20:34
> Para: PTGui Support
> Asunto: [PTGui] Re: Problem with HDR panos: bracket shots not
> well managed
>
Hugo Rodriguez
in this case.
Hugo
> -----Mensaje original-----
> De: pt...@googlegroups.com [mailto:pt...@googlegroups.com] En
> nombre de PTGui Support
> Enviado el: domingo, 06 de junio de 2010 19:21
> Para: pt...@googlegroups.com
> Asunto: Re: [PTGui] Re: Problem with HDR panos: bracket shots
> not well managed
>
Joergen Geerds
wrote:
> 1 EV steps are unuseful with digital raw capture... I hope brands do change
> them quickly.
offer only 3 brackets up to +-2EV, and nothing has compelled canon so
far to change anything.
nikon on the other hand already gives you a much wider latitude, by
allowing 9 brackets (in 1EV steps), resulting in max +-4EV, that is
4EV more dynamic range than canon, without touching the camera in
between shots. the only inconvenience is moving the RAW files that you
don't need into a separate folder/trash on your computer, but this is
so ridiculously easy, that i coulnd't believe that this would be
bothering you. storage&memory cards are too cheap these days.
> As I use a quite firmly tripod and head, I do it manually with care.
camera while doing a bracket set, you could as well shoot handheld and
unlink your brackets in ptgui, because they aren't pixel perfect
anymore. i tried it once, and i will never do it again.
> I knew promote; it's funny, but expensive and another gadget to carry. No, thanks ;-)
photographer it payed for itself (and i never thought the promote as
"funny", "incredible useful" would be more appropriate). i can
understand that amateurs would see it as an expensive and unnecessary
gadget.
but I hope this lengthy sunday afternoon discussion has solved some of
your problems and gave you a deeper understanding into the issue.
Joergen
Bjørn K Nilssen
> On Jun 6, 2:50 pm, Bjørn K Nilssen <b...@bknilssen.no> wrote:
> > CS3 extended did HDR layers, but not the standard version.
> > Adobes site is impossible for finding such "details" as comparisons between
> versions.
> > Anybody know where to find such a list with differences between CS5 and CS5
> extended?
>
> http://en.wikipedia.org/wiki/Adobe_Photoshop
Still no comparisons between standard/extended I'm afraid :(
> the main feature that makes the extended version is 3D and editing
> movies, for the rest I believe that they are identical. Why don't you
> use the 30 day trial and check it out? but since you do 3D, the
> extended version might be more up your alley.
I don' think so. According to those who have used the 3D tools it's just a joke, and not
useful at all if you're using real 3D programs already. Guess it's like using PS for
stitching spherical panoramas? ;)
> > BTW, I believe that a lot of the tonemapped stuff looks so great that viewers never
> think
> > of them as HDR/tonemapped. What is usually considered tonemapped HDR is when they go
> > overboard. Lots of "normal" photos may be tonemapped HDR without anyone noticing.
> > Just take a look at Christian Blochs gallery at
> :http://www.hdrlabs.com/gallery/flashpanos.html
> > to view some panos that certainly don't have that "HDR look", even though they are
> > tonemapped.
>
> yes, those are the remaining 5% that I mentioned that look good/
> pleasant/well done/unoffensive. the remaining 95% look unfortunately
> like clown vomit.
How can you tell that a good image isn't using HDR?
If you read Blochs HDRI handbook you'll find lots of tonemapped images that looks great,
made by a lot of different people. There are also examples of more "artistic" use of
HDR/tonemapping which you'll probably classify as clowns vomit, which I like. I agree
that there are a lot of ugly so called HDR images out there on the net, but it is still a
perfectly legal technique, and possible to use to make great pictures. It's the end
result that matters, and not the tools used.
Joergen Geerds
> I don' think so. According to those who have used the 3D tools it's just a joke, and not
> useful at all if you're using real 3D programs already. Guess it's like using PS for
> stitching spherical panoramas? ;)
limited... but I am no 3D person, so I can't tell.
> > yes, those are the remaining 5% that I mentioned that look good/
> > pleasant/well done/unoffensive. the remaining 95% look unfortunately
> > like clown vomit.
> How can you tell that a good image isn't using HDR?
why so defensive about HDR all of a sudden?
what's above is not the point, and it is not what I said... i can tell
a good image from a bad image, and I don't care what technique the
photographer used to achieve a good image. all i said is that the
majority of all tonemapped images (they are no HDRs anymore when we
see them) isn't good.
> If you read Blochs HDRI handbook you'll find lots of tonemapped images that looks great,
> made by a lot of different people.
outstanding examples, including images that appeal only to a portion
of the audience, and then you go to the HDR group on flicks and find a
huge repository of clown vomit.
> but it is still a
> perfectly legal technique, and possible to use to make great pictures. It's the end
> result that matters, and not the tools used.
their photography, instead of using techniques like HDR to spice up
their mediocre photos... but I guess that is the Dunning-Kruger-Effect
in full force :-)
joergen
Bjørn K Nilssen
> On Jun 6, 6:26 pm, Bjørn K Nilssen <b...@bknilssen.no> wrote:
> > I don' think so. According to those who have used the 3D tools it's just a joke, and
> not
> > useful at all if you're using real 3D programs already. Guess it's like using PS for
> > stitching spherical panoramas? ;)
> yes, if you compare it to a real 3D app, the features are somewhat
> limited... but I am no 3D person, so I can't tell.
>
> > > yes, those are the remaining 5% that I mentioned that look good/
> > > pleasant/well done/unoffensive. the remaining 95% look unfortunately
> > > like clown vomit.
> > How can you tell that a good image isn't using HDR?
>
> Bjørn,
>
> why so defensive about HDR all of a sudden?
My point was simply that 95% of all tonemapped HDR images may very well be "hidden", or
simply "disguised" as good, normal images (but with a larger/better dynamic range) - iow
the technique used doesn't show/shout, but is used discreetly to enhance the image.
It is just too easy to blame HDR/tonemapping because it can also be used for making clown
vomit, as you called it.
>
> what's above is not the point, and it is not what I said... i can tell
> a good image from a bad image, and I don't care what technique the
> photographer used to achieve a good image. all i said is that the
> majority of all tonemapped images (they are no HDRs anymore when we
> see them) isn't good.
>
> > If you read Blochs HDRI handbook you'll find lots of tonemapped images that looks
> great,
> > made by a lot of different people.
> again, this isn't what I said... you'll find for any technique
> outstanding examples, including images that appeal only to a portion
> of the audience, and then you go to the HDR group on flicks and find a
> huge repository of clown vomit.
>
> > but it is still a
> > perfectly legal technique, and possible to use to make great pictures. It's the end
> > result that matters, and not the tools used.
>
> I totally agree with you. I just wish people would spend more time on
> their photography, instead of using techniques like HDR to spice up
> their mediocre photos... but I guess that is the Dunning-Kruger-Effect
> in full force :-)
Yes, I suppose Dunning-Kruger is at play here, just like in "bokeh images", soft
waterfalls, gigapixel images, "oil painting", shadow/highlight and other popular
techniques used to make "pretty" or impressive images. Misused a lot, but with some great
results too. There is no law that enforces everyone to use "natural" colors in their
photos. And there are a lot of easier ways to spice up your photos than using
HDR/tonemapping ;)
PTGui Support
> Well, now I think it's clear that it's not necessary to shoot all
> brackets.
If you use PTGui to merge your brackets to HDR then you do need to shoot
all brackets at all angles. Otherwise there will be holes in the blend
planes, resulting in visible edges.
Joost
l_d_allan
> because I try to minimize camera handling (to minimize
> possible movement when using shutter dial.
> I mean: I start doing 0, +2, +4 and then +4, +2, 0. I never shoot +,
> 0 ,-; always 0 to overexposed, because I first determine exposure to
> the right and then I overexpose; this is the best way with RAW.
When I do HDR panos, I have my Canon 50d set to -2 / 0 / +2, with the
self-timer. One shutter button push, and the three images are
captured. Then rotate the panohead, and get the next set of three with
one shutter button activation.
Or perhaps I don't understand your remark?
hurodal
I prepared and example for you to see how a little utility can blend
perfectly a difficult HDR. I selected one bracket of an HDR pano I
shooted recently, with trees moving and high contrast, with sun at
front. Those are the shots:
http://groups.google.com/group/ptgui/web/HDR-CS4_PTGui-ZeroNoise_0.jpg
After blending both with CS4, PTGui and a small utility developed by a
friend of mine, called ZeroNoise, the result is this (note each one in
the title):
http://groups.google.com/group/ptgui/web/HDR-CS4_PTGui-ZeroNoise_1.jpg
If I zoom to actual size, you can see the difference in the clouds:
http://groups.google.com/group/ptgui/web/HDR-CS4_PTGui-ZeroNoise_2.jpg
in the leaves of the tree's branches:
http://groups.google.com/group/ptgui/web/HDR-CS4_PTGui-ZeroNoise_3.jpg
Note the difference in sharpness, because NEFs are respectively
developed with CS4, C1 Pro and dcraw.
Finally, the most difficult area, where leaves and branches are moving
highly:
http://groups.google.com/group/ptgui/web/HDR-CS4_PTGui-ZeroNoise_4.jpg
All these examples are not retouched in photoshop at all. I know I can
place every shot in a layer, create masks, etc.. but I said I want a
software that can minimize that kind of work, by doing two key thins:
quickly switch from one shot to the other and mask by searching
differences between shots with a radius around every pixel. This is
what this little utility exactly does, and the quality is very high,
but it's workflow is very slow. It's called ZeroNoise and you can see
here:
http://groups.google.com/group/ptgui/web/ZeroNoise_1.jpg
Regards,
PD: Did you see the other comparisons I uploaded yesterday? (4 images)
http://ptgui.googlegroups.com/web/comparison+PMatix-manual+blend+01.jpg?gda=w47v6FcAAACqL5rYl_CiD4E4c-gNoyDxsKnSq2_fML5JScQEIpTq0xOQrPh-PhwAjT9Yr6DRVzFFr_R3dG20IO0WWwxa-SB-4jX5QZ0vdHnBDt87893RKnleHbr-qQzBoYYWXY0JTQM&gsc=EpRrwwsAAAAPyLNKr220tUsPNzrr4Vyi
hurodal
> Some sort of grid pre-arrangement in ptgui is an often requested
> feature, I think I am asking for it now for 12-18 months. I don't
> really mind how ptgui is looking for CPs, and even if it has to look
> in all image pairings, the actual time it needs is relative little.
> although it would help with false-positives.
loaded, user could arrange manually them by dragging:
http://groups.google.com/group/ptgui/web/suggestion%20PTGui_1.jpg
to finally set this:
http://groups.google.com/group/ptgui/web/suggestion%20PTGui_2.jpg
> not really. de-ghosting is not an easy task, and even photoshop is
> only using a fairly simple method to de-ghost by letting the user
> select his/her favorite exposure... photomatix has it's own method of
> de-ghosting, and you can use your own method (i.e. doing a separate
> set of HDR/enfused tiles from only 1 exposure (fake HDR/enfusion), and
> use those for heavily moving objects. the other method would be
> shooting on days with little wind, or embrace the wind (i.e. longer
> exposures to get more blur), or actually pay attention to what you are
> photographing.
http://groups.google.com/group/ptgui/web/HDR-CS4_PTGui-ZeroNoise_4.jpg
> I have no idea what this should accomplish, since this has nothing to
> do with your HDR problem, and all of the above are already
> systematically build into the panorama-tool paradigm.
where to search for control points, making the whole process quicker
and allowing better results. This way, PTGui will only find little
displacements between shots, but it could pre-set parameters with low
errors.
> this feature would only benefit a very small set of ptgui users (aka
> you). not all CPs in trees are bad (unless your pano has only straw-
> like trees like birches in scandinavia in a storm). second, landscapes
> are not the only use for ptgui, there are enough people that do
> architecture and other things with it (like me). on the other hand,
> some sort of lasso functionality for the CPs would be nice to have.
think? I live in Barcelona, Spain, and here is difficult to shoot an
urban pano without any tree...
> I am not sure how deeply you are into how HDR is supposed to work for
> panos. since you don't shoot complete bracket sets, your workflow is
> already flawed and can't produce ideal results.
you so sure my workflow is flawed? Maybe PTGui does like full
brackets, but often they aren't necessary at all... for example: how
many HDR floors (nadir) did you see in your life?
Hugo Rodriguez
hurodal
> I am not sure if I follow your correctly, but ptgui has almost never a
> problem with pre-enfused tiles, and processes them actually extremely
> fast (almost any pano on my websites is enfused (or similar process)).
> I assume that ptgui also does a nice job with open-exr files in the
> same fashion it handles tiffs, but since i never use HDR, i can't
> really tell.
manage so good movements, as ZeroNoise do.
Hugo
hurodal
> If you use PTGui to merge your brackets to HDR then you do need to shoot
> all brackets at all angles. Otherwise there will be holes in the blend
> planes, resulting in visible edges.
PTgui uses unly one image to fill that angle, for example, the nadir.
Hugo
hurodal
> unlikely... take canon for example: all but the highest end model
> offer only 3 brackets up to +-2EV, and nothing has compelled canon so
> far to change anything.
in this area than 1Ds MkIII or 1D MkIV. It offer 3 brackets up to +/-3
EV. Combined with exp. compensation, it will allow to quickly do 0,
+3, +6 EV, which is such a good sequence.
> nikon on the other hand already gives you a much wider latitude, by
> allowing 9 brackets (in 1EV steps), resulting in max +-4EV, that is
> 4EV more dynamic range than canon, without touching the camera in
> between shots.
me. This is a very simple question that nikon could fix with a simple
update in firmware, but they simply won't do.
> the only inconvenience is moving the RAW files that you
> don't need into a separate folder/trash on your computer, but this is
> so ridiculously easy, that i coulnd't believe that this would be
> bothering you. storage&memory cards are too cheap these days.
there's absolutely no reason (technological) for Nikon to change this
> there isn't enough care in the world... every time you touch your
> camera while doing a bracket set, you could as well shoot handheld and
> unlink your brackets in ptgui, because they aren't pixel perfect
> anymore. i tried it once, and i will never do it again.
panos, except if you shoot arquitecture or something really detailed.
> that is quite ok. i love my promote, and as a professional
> photographer it payed for itself (and i never thought the promote as
> "funny", "incredible useful" would be more appropriate). i can
> understand that amateurs would see it as an expensive and unnecessary
> gadget.
solutions (one is use the iphone with the wifi accesory of the camera,
other is the promote).
> but I hope this lengthy sunday afternoon discussion has solved some of
> your problems and gave you a deeper understanding into the issue.
PTGui...
Oh, and an interesting discussion with all of you :-)
Hugo
Erik Krause
> I know I can
> place every shot in a layer, create masks, etc.. but I said I want a
> software that can minimize that kind of work, by doing two key thins:
> quickly switch from one shot to the other and mask by searching
> differences between shots with a radius around every pixel. This is
> what this little utility exactly does, and the quality is very high,
> but it's workflow is very slow. It's called ZeroNoise and you can see
> here:
>
> http://groups.google.com/group/ptgui/web/ZeroNoise_1.jpg
I think it is the technique described on
http://www.guillermoluijk.com/article/nonoise/index_en.htm
is it?
This is an interesting technique indeed and perhaps Josst considers
implementing it some time. But since there is a specialized application
already and since PTGui is a panorama stitcher - not primarily a HDR
application - it might as well not happen. For my share I would rather
see it at the very bottom of the whish list, since other improvements
are far more important. Most likely photomatix will implement it soon...
Joergen Geerds
> http://groups.google.com/group/ptgui/web/ZeroNoise_1.jpg
> I think it is the technique described onhttp://www.guillermoluijk.com/article/nonoise/index_en.htm
> is it?
good noise reduction from the enfusion process, so I can afford to
shoot at ISO 2500 and 5000, and I read the article above in 2008, and
was really excited when enfuse/photomatix picked up on the idea... if
they are significantly different, then I would like to hear what the
difference is (that is using well exposed values from the middle, not
from the bottom).
joergen
Joergen Geerds
> On Jun 6, 7:38 am, hurodal <info.hugorodrig...@gmail.com> wrote:
> > b1) Add control points only under horizon line (allowing to not create
> > points on trees, which normally are over the horizon line) or add an
> > option to delete control points of a pair of images, not the whole
> > panorama (to allow user quickly delete points of a tree).
>
> this feature would only benefit a very small set of ptgui users (aka
> you). not all CPs in trees are bad (unless your pano has only straw-
> like trees like birches in scandinavia in a storm). second, landscapes
> are not the only use for ptgui, there are enough people that do
> architecture and other things with it (like me). on the other hand,
> some sort of lasso functionality for the CPs would be nice to have.
When you requested that CPs are only generated below the horizon, and
I dismissed the idea as impractical, I was a bit too quick with my
answer. basically your problem is that CPs in trees are not reliable
due to wind, and you want to do away with them completely. Assuming
that your panorama head is perfectly calibrated (and you are not using
a fisheye lens, because they don't have a single NPP), you can use the
"delete worst CPs" functionality, either auto, or manually.
a well calibrated head will give you an average error below 1px, and a
max of 2px after full optimization and CP culling. if you generate
enough points, you can use the CP list, soft by distance, and delete
all the CPs >2.5px. this will eliminate all CPs on leaves/branches
that are moving too much, yet keep good CPs and trunks and other non-
moving objects.
joergen
Erik Krause
> isn't this what enfuse does at it's basic core? I mean I get really
> good noise reduction from the enfusion process, so I can afford to
> shoot at ISO 2500 and 5000, and I read the article above in 2008, and
> was really excited when enfuse/photomatix picked up on the idea... if
> they are significantly different, then I would like to hear what the
> difference is (that is using well exposed values from the middle, not
> from the bottom).
I don't think the program uses the Mertens, Kautz and Van Reeth pyramid
blending algorithm to merge different exposures like f.e. enfuse does.
If I understand it correctly all images are adjusted to the same
brightness, then either averaged or taken the least noisy parts of each.
That's why ZeroNoise can easily avoid ghosts - it simply uses only one
exposure step if it detects ghosts (which is easy too, since all images
have same brightness).
Hugo Rodriguez
Oh, yes, it is the same. Guillermo's utility is very interesting, because
simply switch to take pixels always from the best capture, avoiding blending
if it's possible. I completely agree with him that this is the very best
technique for HDR blending. Now I'm telling him some suggestions to improve
his software, so it lets user develop raw files with other software (not
always dcraw), to speed up workflow and to add a batch feature.
I think that it's engine is so simple that it could be implemented easily in
PTGui. If I can help you in that (testing it, not programming), I'd happily
do.
Hugo Rodriguez
> -----Mensaje original-----
> De: pt...@googlegroups.com [mailto:pt...@googlegroups.com] En
> nombre de Erik Krause
> Enviado el: lunes, 07 de junio de 2010 22:23
> Para: pt...@googlegroups.com
> Asunto: [PTGui] Re: Problem with HDR panos: bracket shots not
> well managed
>
Erik Krause
> Oh, yes, it is the same. Guillermo's utility is very interesting,
The results are intersting indeed. The user interface however is a mess.
Not more than a technical demo at the moment...
> I completely agree with him that this is the very best
> technique for HDR blending.
I still don't believe that this can be called HDR. I wonder how the tool
would cope with f.e. 9 brackets at 2 EV steps (18 EV total). But may be
the technique could actually be used to create real HDR images.
> Now I'm telling him some suggestions to improve
> his software, so it lets user develop raw files with other software (not
> always dcraw), to speed up workflow and to add a batch feature.
Yes, that would be absolutely necessary.
> I think that it's engine is so simple that it could be implemented easily in
> PTGui. If I can help you in that (testing it, not programming), I'd happily
> do.
I'm not involved in PTGui development - only as a satisfied long time
user (and tester of course ;-)
Hugo Rodriguez
step is only 1 EV, so I prefer to do it manually... At least until Nikon
improves it with a new firmware (or a new model, sigh!)
Hugo Rodriguez
> -----Mensaje original-----
> De: pt...@googlegroups.com [mailto:pt...@googlegroups.com] En
> nombre de l_d_allan
> Enviado el: lunes, 07 de junio de 2010 16:34
> Para: PTGui Support
> Asunto: [PTGui] Re: Problem with HDR panos: bracket shots not
> well managed
>
Hugo Rodriguez
> When you requested that CPs are only generated below the horizon, and
> I dismissed the idea as impractical, I was a bit too quick with my
> answer. basically your problem is that CPs in trees are not reliable
> due to wind, and you want to do away with them completely. Assuming
> that your panorama head is perfectly calibrated (and you are not using
> a fisheye lens, because they don't have a single NPP), you can use the
> "delete worst CPs" functionality, either auto, or manually.
Oh, I did know that feature, but I didn't tried it in this case; I'll do,
thanks,
> a well calibrated head will give you an average error below 1px, and a
> max of 2px after full optimization and CP culling. if you generate
> enough points, you can use the CP list, soft by distance, and delete
> all the CPs >2.5px. this will eliminate all CPs on leaves/branches
> that are moving too much, yet keep good CPs and trunks and other non-
> moving objects.
Aha, I understand. I'll try it, many thanks for this useful info.
Hugo Rodriguez
Hugo Rodriguez
> is a mess.
> Not more than a technical demo at the moment...
Ha ha, yes, I think the same, but Guillermo feels happy with it
> I still don't believe that this can be called HDR. I wonder
> how the tool
> would cope with f.e. 9 brackets at 2 EV steps (18 EV total).
> But may be
> the technique could actually be used to create real HDR images.
I believe it's process is true HDR. The only problem is that it can't
actually output a 32bit file, only 16 bit TIFF. But considering that a
linear 16bit TIFF can actually have 12 or 13 EV steps with quality, only
gamma compensated TIFFs are a solution, as well as 32 bit files. They can
have hundreds of EV steps with very high quality (at least, 256 Evs, each
one with 256 tonal range per channel).
Oh, I'm sorry. Maybe Joost reads me (is he involved in development, isn't
it?)
Hugo Rodriguez
Erik Krause
> I believe it's process is true HDR. The only problem is that it can't
> actually output a 32bit file, only 16 bit TIFF.
Well, if the process is essentially what is described on
http://jtrujillo.net/qpix/ it is not HDR. It's simply replacing the
shadows with a darker version of a longer exposure. The dynamic range
can't be larger than in the non-adjusted source image - otherwise it
won't match.
The page http://www.guillermoluijk.com/ seems not to be available any
more. All I get is: "You don't have permission to access
/article/nonoise/index_en.htm on this server.
Additionally, a 403 Forbidden error was encountered while trying to use
an ErrorDocument to handle the request."
what happened?
Hugo Rodriguez
I think I know this guy...
But there's an important difference between this method and the one used by
Guillermo: images must be developed absolutely without curves or any
luminance adjustment, and have to be in linear-space gamma before blended.
And Camera RAW is not capable of that, but dcraw or CaptureOne are.
That way is the only to obtain images with the most pure adding of two or
more original images, and with much improved noise level in the final image.
There's always one of the images with much higher quality quality on every
pixel, right? Noise and partial or full saturation are the key to know if
it's in the first or second image. So, knowing that every pixel has always
higher quality in one of the images, the best pixel in the final image is
obtained by picking that pixel, not by blending both (which cause loss of
quality, because the other pixel is worse).
Hugo Rodriguez
> -----Mensaje original-----
> De: pt...@googlegroups.com [mailto:pt...@googlegroups.com] En
> nombre de Erik Krause
> Enviado el: lunes, 14 de junio de 2010 22:50
> Para: pt...@googlegroups.com
> Asunto: [PTGui] Re: Problem with HDR panos: bracket shots not
> well managed
>
Hugo Rodriguez
I have some suggestions for improving QTVR generation. I feel that both
nadir and zenith are overprocessed, sometimes causing a visible vertex in
the center of them.
1) Is it possible to allow user to generate cube faces directly in the
ouptput tab, without having to generate previously the full espherical pano?
I think that cause the vertex.
2) It will be very useful to see the faces before creating the final file,
like in cubic converter, allowing to quickly export and load an retouched
shoot for nadir, for example.
3) Stamp a logo (vectorial or with alpha channel) to any point/s of the
panorama (to nadir, into heaven, randomly, etc...), with options to decide
transparency, position, size...
I hope you find them useful. Cheers
Hugo Rodriguez
Hugo Rodriguez
I'm seeing the article now in this url:
http://www.guillermoluijk.com/article/nonoise/index_en.htm
Try again...
Hugo Rodriguez
> -----Mensaje original-----
> De: pt...@googlegroups.com [mailto:pt...@googlegroups.com] En
> nombre de Erik Krause
> Enviado el: lunes, 14 de junio de 2010 22:50
> Para: pt...@googlegroups.com
> Asunto: [PTGui] Re: Problem with HDR panos: bracket shots not
> well managed
>
Erik Krause
> 1) Is it possible to allow user to generate cube faces directly in the
> ouptput tab, without having to generate previously the full espherical pano?
> I think that cause the vertex.
As far as I know this is on the wish list (at least direct stitching to
cube faces). However, if you provide good enough input (high resolution
TIFF) there should be no vortex visible.
> 2) It will be very useful to see the faces before creating the final file,
> like in cubic converter, allowing to quickly export and load an retouched
> shoot for nadir, for example.
>
> 3) Stamp a logo (vectorial or with alpha channel) to any point/s of the
> panorama (to nadir, into heaven, randomly, etc...), with options to decide
> transparency, position, size...
IMHO PTGui should focus on panorama stitching, not on presentation -
especially not on a format that is virtually dead like QTVR. There are
much better and far more sophisticated programs to do that (Pano2VR),
even free ones (Pano2QTVR, PanoCube).