Hi everyone! I'm new to this group. I use Hugin 2011.4.0 on Linux.
I've been googling for a Hugin tutorial on how to build a Panorama from a series of bracketed images, to no avail. In my case I take 5 hand-held bracketed images for every "tile" in the final panorama, and usually I don't take more than 3-4 "tiles" in a single row.
Could anyone teach me how to get a pseudo HDR Panorama with my picture series? I tried several ways of doing it but I always end up with a very diffused image. I step-by-step guide would be really appreciated.
There are some different approaches you can use, hugin itself can do the
exposition fusion, for what it uses enfuse, but I usually prefer to combine
the different expositions before mounting the panorama, so I deal with them
as there were no panorama at all.
I usually use enfuse (which comes with hugin) and just let it do its job
with no other specific configuration, them I stitch the resulting images on
hugin. As you are in linux you can maybe make a script for that. I usually
list the directory and redirect the output to a script, which I edit with
vi, but this hint makes no sense if you are not familiar with those tools.
this creates the output01.jpg file, combining the 4 different expositions.
If you haven't made the expositions with a tripod and need to realign the
images, then you can use the command "align_image_stack", which also comes
with hugin. Run it with no arguments for a small help.
> Hi everyone! I'm new to this group.
> I use Hugin 2011.4.0 on Linux.
> I've been googling for a Hugin tutorial on how to build a Panorama from a
> series of bracketed images, to no avail.
> In my case I take 5 hand-held bracketed images for every "tile" in the
> final panorama, and usually I don't take more than 3-4 "tiles" in a single
> row.
> Could anyone teach me how to get a pseudo HDR Panorama with my picture
> series? I tried several ways of doing it but I always end up with a very
> diffused image. I step-by-step guide would be really appreciated.
> Thanks in advance.
> --
> You received this message because you are subscribed to the Google Groups
> "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
Ramiro, I'm not an expert but here is what I've been happy with. I shoot 3 bracketed images per tile and I tend to have 10-12 tiles total (360 spherical pano). I load the images into hugin, then I create the stacks in the images tab. For each stack I run align-image-stack to find control points (lower-left pane of images tab), I use the following arguments to align_image_stack: -f %v -e -v -p %o -g 1 -i -c 1 -g 4 %i. I then select the best image of each stack and run cpfind to create control points across the tiles.
In one of the preview windows I ensure the EV is set to that of the brightest image so I don't get clipping. To stitch, I select "exposure fused from any arrangement" and jpeg (or tiff). This results in a 24-bit image that is automatically HDR-blended. It works well for me for sunset type of shots where the dynamic range needs to be compressed but isn't huge.
I have a question which I hope does not come across as a criticism, and that is: I notice there are two uses of the "-g" parameter in your command line: g=1 and g=4. Was this intentional?
I meant to use -g 4, but you can adjust. -g 4 reduces the image by 2^4, i.e.16x, to do the alignment.Perhaps -g 2 would be more accurate and not too slow.
However, something I realized when trying to process a handheld pano is that by default all the images in a stack are linked, so the optimizer doesn't actually align them. You have to select all images in the images tab and then uncheck the "Link" box in the lower-left. This allows the images in a stack to be adjusted relative to one another, which you need unless they have a 100% identical field of view.
Good luck and let me know if this works for you! Hugin has so many options that it's difficult to figure out how to do something efficiently... (Not a complaint, just a statement of fact...)
On Saturday, November 17, 2012 12:53:15 PM UTC-8, tbransco wrote:
> Thanks for your helpful post, TvE.
> I have a question which I hope does not come across as a criticism, and > that is: I notice there are two uses of the "-g" parameter in your command > line: g=1 and g=4. Was this intentional?
Here's a recap of my workflow. I need to test it some more, but so far it seems to work:
- shoot ~10 tiles for a spherical pano, total of ~30 images with 3x bracketing (10.5mm, full-frame fisheye, 6 tiles around, 2x-3x up, 2x down) - pre-process to increase sharpness and local contrast (wide unsharp-mask) - load all images into hugin - select each bracket group in images tab, make new stack, run align-image-stack -f %v -e -v -p %o -i -c 1 -g 2 %i - select all images in images tab, unlink positions - select "best" image in each stack and run cpfind+celeste to get the tiles to align - run optimizer in incremental from anchor mode - check control points table for worst fit and fiddle with control points, re-run optimizer with "everything without translation", repeat... - I often take a nadir shot from a slightly moved position so I don't have shadows in the same spot, to align those images I set them to use a different lens, which offers a few more degrees of freedom and I make sure control points are only set in the small area I need from those shots - mask tripod/feet out of shots in the mask tab, use "exclude region from stack" - run exposure optimization using HDR, var white bal, fixed exposure - fiddle with view in the fast preview - calculate optimal FOV in stitching tab - stitch using exposure fused from any arrangement to jpeg Q-90 - adjust final histogram and colors in regular photo editor - phew!
If you have suggestions or corrections, I'd love to hear. Getting this far has taken many hours of fiddling with hugin. One thing I don't know is whether setting the EV in hugin makes a difference when using the exposure fusing, I believe not.
Hi, I am also not an expert, but I do a different approach. I usually do 3
to 5 auto bracketing with the camera using a tripod or a pole. When I use
the tripod I don't need to align the images. Using the pole, as the
structure sometimes has some instability, mainly when it is windy, I align
images.
The different approach I meant is that I usually don't do this in hugin. I
align and fuse images before making the pano and it gives me good results.
My align command is really simple:
align_image_stack -a file1- IMG01.JPG IMG02.JPG IMG03.JPG
and it gives me the aligned files file1-0000.tif file1-0001.tif
file1-0002.tif, which then I fuse with enfuse:
enfuse -o file1.jpg --compression=95 file1-*
I usually make little scripts for the whole job. I make this scripts each
time in vi (a unix text editor), which makes the job relatively easy, so I
didn't take the time to make a generic script yet.
Then I use the fused images into hugin to make the panos. I usually use 10
to 20 images, depending on the lens I have used.
> Here's a recap of my workflow. I need to test it some more, but so far it
> seems to work:
> - shoot ~10 tiles for a spherical pano, total of ~30 images with 3x
> bracketing (10.5mm, full-frame fisheye, 6 tiles around, 2x-3x up, 2x down)
> - pre-process to increase sharpness and local contrast (wide
> unsharp-mask)
> - load all images into hugin
> - select each bracket group in images tab, make new stack, run
> align-image-stack -f %v -e -v -p %o -i -c 1 -g 2 %i
> - select all images in images tab, unlink positions
> - select "best" image in each stack and run cpfind+celeste to get the
> tiles to align
> - run optimizer in incremental from anchor mode
> - check control points table for worst fit and fiddle with control
> points, re-run optimizer with "everything without translation",
> repeat...
> - I often take a nadir shot from a slightly moved position so I don't
> have shadows in the same spot, to align those images I set them to use a
> different lens, which offers a few more degrees of freedom and I make sure
> control points are only set in the small area I need from those shots
> - mask tripod/feet out of shots in the mask tab, use "exclude region
> from stack"
> - run exposure optimization using HDR, var white bal, fixed exposure
> - fiddle with view in the fast preview
> - calculate optimal FOV in stitching tab
> - stitch using exposure fused from any arrangement to jpeg Q-90
> - adjust final histogram and colors in regular photo editor
> - phew!
> If you have suggestions or corrections, I'd love to hear. Getting this far
> has taken many hours of fiddling with hugin. One thing I don't know is
> whether setting the EV in hugin makes a difference when using the exposure
> fusing, I believe not.
> --
> You received this message because you are subscribed to the Google Groups
> "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
Carlos, thanks for posting your steps. Running align_image_stack from the command line sounds like a nice idea. You could also output the result into the .pto file, I believe. I don't know about pre-fusing each stack into a 24-bit jpg. I would be concerned that you could end up with images that have very different dynamic ranges and that don't blend well into the final pano. E.g. if one stack has sunset-to-dark and the other is all-dark. But maybe enfuse deals with that properly or maybe those scenarios don't fuse well either way... If I have the time I may give the two approaches a spin. Another advantage of not pre-fusing is that align_image_stack sometimes has difficulties, specially when large areas are very dark or blown out in one of the images of the bracket and it's nice to be able to adjust the control points in hugin. Ah. maybe we can collect some more wisdom and then turn this thread into a wiki page.
just to clarify, I don't work with 24-bit jpg. I usually shoot in JPG and
work with it in 8 bits. But alit_image_stack can deal with tif and you can
work with tif all the time. I just put JPG in my example because I use it :)
I sometimes have some ghosts in the final result of the enfusion, but I
doubt if it would solve using a larger image. I think they happen because
of parallax differences. I can clearly see that part of the image is good
and another is not, so I think align_image_stack has done it's job. The
solution (maybe) would be distort the image before fuse them and maybe
hugin does that, I don't know. In fact I have never tried to make the
exposure stacks directly into hugin. Maybe I should also give it a try :)
> Carlos, thanks for posting your steps. Running align_image_stack from the
> command line sounds like a nice idea. You could also output the result into
> the .pto file, I believe. I don't know about pre-fusing each stack into a
> 24-bit jpg. I would be concerned that you could end up with images that
> have very different dynamic ranges and that don't blend well into the final
> pano. E.g. if one stack has sunset-to-dark and the other is all-dark. But
> maybe enfuse deals with that properly or maybe those scenarios don't fuse
> well either way... If I have the time I may give the two approaches a spin.
> Another advantage of not pre-fusing is that align_image_stack sometimes has
> difficulties, specially when large areas are very dark or blown out in one
> of the images of the bracket and it's nice to be able to adjust the control
> points in hugin. Ah. maybe we can collect some more wisdom and then turn
> this thread into a wiki page.
> --
> You received this message because you are subscribed to the Google Groups
> "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
when you say "24 bit jpeg" almost everybody thinks of this as "full
color (RGB), 8 bits per channel".
What is needed for HDR work, is either a floating point format (about
12 bits per channel, would be sufficient, but 32 bits per channel are
normally used in hugin) or a high-bit-count fixed-point
format. Something like 16 might get close, but 24 bits per channel.
may be more appropriate.
JPEG format is not appropriate for non-8-bit-per-channel-data. So
Carlos in the workflow that you describe you're truncating a lot of
information when you output your intermediate files into the 8-bit
jpeg format.
So... Carlos, I would suggest that you try saving your intermediate
files as tiff, and then find out what options you have to create a
32-bit-per-channel-floating-point intermediate file. Then Hugin can,
while stitching, apply proper exposure corrections and things like
that. (or are you fixing the exposure bracket for the whole panorama? In that case Hugin's exposure correction should be unneccessary.)
Roger.
On Mon, Nov 19, 2012 at 08:35:41AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote:
> just to clarify, I don't work with 24-bit jpg. I usually shoot in JPG and
> work with it in 8 bits. But alit_image_stack can deal with tif and you can
> work with tif all the time. I just put JPG in my example because I use it :)
> I sometimes have some ghosts in the final result of the enfusion, but I
> doubt if it would solve using a larger image. I think they happen because
> of parallax differences. I can clearly see that part of the image is good
> and another is not, so I think align_image_stack has done it's job. The
> solution (maybe) would be distort the image before fuse them and maybe
> hugin does that, I don't know. In fact I have never tried to make the
> exposure stacks directly into hugin. Maybe I should also give it a try :)
> > Carlos, thanks for posting your steps. Running align_image_stack from the
> > command line sounds like a nice idea. You could also output the result into
> > the .pto file, I believe. I don't know about pre-fusing each stack into a
> > 24-bit jpg. I would be concerned that you could end up with images that
> > have very different dynamic ranges and that don't blend well into the final
> > pano. E.g. if one stack has sunset-to-dark and the other is all-dark. But
> > maybe enfuse deals with that properly or maybe those scenarios don't fuse
> > well either way... If I have the time I may give the two approaches a spin.
> > Another advantage of not pre-fusing is that align_image_stack sometimes has
> > difficulties, specially when large areas are very dark or blown out in one
> > of the images of the bracket and it's nice to be able to adjust the control
> > points in hugin. Ah. maybe we can collect some more wisdom and then turn
> > this thread into a wiki page.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Hugin and other free panoramic software" group.
> > A list of frequently asked questions is available at:
> > http://wiki.panotools.org/Hugin_FAQ > > To post to this group, send email to hugin-ptx@googlegroups.com
> > To unsubscribe from this group, send email to
> > hugin-ptx+unsubscribe@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/hugin-ptx
> -- > You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx
-- ** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
Thanks Rogier, I think I must study more those details of image formats.
These information you told us have clarified my mind a little more. Do you
recommend a good general reference about it?
And you are right, I fix the exposure bracketing for the whole panorama and
as I use a manual workflow in hugin I just don't do exposure optimization.
To tell more details of my usual exposition workflow, I use Magic Lantern
firmware on my canons, so I have a more flexible control of auto
bracketing. I usually do expositions with 2EV of difference between
pictures and choose, experimenting on the scene, if I need 3, 4 or 5
different expositions. Magic Lantern allow me to use up to 9 auto
bracketing pics.
I also define the order. I usually set it to make the darker one first,
then it goes increasing the exposition time, giving me more clear pics. Due
to that I first measure the light on the most clear area of the scene. This
setup will make the first picture, the darker one. Then I test the pictures
in the most dark area and take a fast look at the pictures to decide how
many brackets are ok. I never needed more than 5 until now, using 2EV
between them. I usually think using less than 2EV this is useless. Have
already tried, for example, 3 pics with 1EV between them and it really
didn't expand the dynamic range. Maybe I should try something like 9 pics
with 1EV dif and compare with 5 pics with 2EV dif.
Anyway, with this I do the workflow I mentioned before, in which, again, I
don't make any exposure correction in hugin and I think I get some good
results, which can be seen in my blog.
Here is one example where I have used 4 auto bracketing pics with 3EV
between them - total of 12EV of difference from the first to the last:
http://wp.me/p1AGa0-hp
> when you say "24 bit jpeg" almost everybody thinks of this as "full
> color (RGB), 8 bits per channel".
> What is needed for HDR work, is either a floating point format (about
> 12 bits per channel, would be sufficient, but 32 bits per channel are
> normally used in hugin) or a high-bit-count fixed-point
> format. Something like 16 might get close, but 24 bits per channel.
> may be more appropriate.
> JPEG format is not appropriate for non-8-bit-per-channel-data. So
> Carlos in the workflow that you describe you're truncating a lot of
> information when you output your intermediate files into the 8-bit
> jpeg format.
> So... Carlos, I would suggest that you try saving your intermediate
> files as tiff, and then find out what options you have to create a
> 32-bit-per-channel-floating-point intermediate file. Then Hugin can,
> while stitching, apply proper exposure corrections and things like
> that. (or are you fixing the exposure bracket for the whole panorama?
> In that case Hugin's exposure correction should be unneccessary.)
> Roger.
> On Mon, Nov 19, 2012 at 08:35:41AM -0200, Carlos Eduardo G. Carvalho
> (Cartola) wrote:
> > Hi,
> > just to clarify, I don't work with 24-bit jpg. I usually shoot in JPG and
> > work with it in 8 bits. But alit_image_stack can deal with tif and you
> can
> > work with tif all the time. I just put JPG in my example because I use
> it :)
> > I sometimes have some ghosts in the final result of the enfusion, but I
> > doubt if it would solve using a larger image. I think they happen because
> > of parallax differences. I can clearly see that part of the image is good
> > and another is not, so I think align_image_stack has done it's job. The
> > solution (maybe) would be distort the image before fuse them and maybe
> > hugin does that, I don't know. In fact I have never tried to make the
> > exposure stacks directly into hugin. Maybe I should also give it a try :)
> > And surely the best option of all is to stabilize the camera to shoot,
> but
> > sometimes it is a little hard to do:
> > > Carlos, thanks for posting your steps. Running align_image_stack from
> the
> > > command line sounds like a nice idea. You could also output the result
> into
> > > the .pto file, I believe. I don't know about pre-fusing each stack
> into a
> > > 24-bit jpg. I would be concerned that you could end up with images that
> > > have very different dynamic ranges and that don't blend well into the
> final
> > > pano. E.g. if one stack has sunset-to-dark and the other is all-dark.
> But
> > > maybe enfuse deals with that properly or maybe those scenarios don't
> fuse
> > > well either way... If I have the time I may give the two approaches a
> spin.
> > > Another advantage of not pre-fusing is that align_image_stack
> sometimes has
> > > difficulties, specially when large areas are very dark or blown out in
> one
> > > of the images of the bracket and it's nice to be able to adjust the
> control
> > > points in hugin. Ah. maybe we can collect some more wisdom and then
> turn
> > > this thread into a wiki page.
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Hugin and other free panoramic software" group.
> > > A list of frequently asked questions is available at:
> > > http://wiki.panotools.org/Hugin_FAQ > > > To post to this group, send email to hugin-ptx@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > hugin-ptx+unsubscribe@googlegroups.com
> > > For more options, visit this group at
> > > http://groups.google.com/group/hugin-ptx
> > --
> > You received this message because you are subscribed to the Google
> Groups "Hugin and other free panoramic software" group.
> > A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ > > To post to this group, send email to hugin-ptx@googlegroups.com
> > To unsubscribe from this group, send email to
> hugin-ptx+unsubscribe@googlegroups.com
> > For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
> --
> ** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
> ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> The plan was simple, like my brother-in-law Phil. But unlike
> Phil, this plan just might work.
> --
> You received this message because you are subscribed to the Google Groups
> "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
Roger, I'm not sure things are as drastic as you make them when you say "What is needed for HDR work, is either a floating point format (about 12 bits per channel, would be sufficient, but 32 bits per channel are normally used in hugin) or a high-bit-count fixed-point format." Yes, to get the best possible results, you are correct. However, as far as I can tell, when Carlos runs enfuse on a stack, enfuse compresses the dynamic range into the available 24 RGB bits. So if the stack has a large dynamic range, he's loosing some color subtlety and some sensor noise, but he's not loosing highlights or shadows per-se. If he's then putting everything together into one 24-bit RGB image at the end without manual tone mapping, I'm not sure there is much quality to be gained by going through 48-bit or 96-bit intermediate images. Maybe you or someone has some examples where it does make a difference?
On Monday, November 19, 2012 3:06:02 AM UTC-8, rew wrote:
> Guys,
> when you say "24 bit jpeg" almost everybody thinks of this as "full > color (RGB), 8 bits per channel".
> What is needed for HDR work, is either a floating point format (about > 12 bits per channel, would be sufficient, but 32 bits per channel are > normally used in hugin) or a high-bit-count fixed-point > format. Something like 16 might get close, but 24 bits per channel. > may be more appropriate.
> JPEG format is not appropriate for non-8-bit-per-channel-data. So > Carlos in the workflow that you describe you're truncating a lot of > information when you output your intermediate files into the 8-bit > jpeg format.
> So... Carlos, I would suggest that you try saving your intermediate > files as tiff, and then find out what options you have to create a > 32-bit-per-channel-floating-point intermediate file. Then Hugin can, > while stitching, apply proper exposure corrections and things like > that. (or are you fixing the exposure bracket for the whole panorama? > In that case Hugin's exposure correction should be unneccessary.)
> Roger.
> On Mon, Nov 19, 2012 at 08:35:41AM -0200, Carlos Eduardo G. Carvalho > (Cartola) wrote: > > Hi,
> > just to clarify, I don't work with 24-bit jpg. I usually shoot in JPG > and > > work with it in 8 bits. But alit_image_stack can deal with tif and you > can > > work with tif all the time. I just put JPG in my example because I use > it :)
> > I sometimes have some ghosts in the final result of the enfusion, but I > > doubt if it would solve using a larger image. I think they happen > because > > of parallax differences. I can clearly see that part of the image is > good > > and another is not, so I think align_image_stack has done it's job. The > > solution (maybe) would be distort the image before fuse them and maybe > > hugin does that, I don't know. In fact I have never tried to make the > > exposure stacks directly into hugin. Maybe I should also give it a try > :)
> > And surely the best option of all is to stabilize the camera to shoot, > but > > sometimes it is a little hard to do:
> > > Carlos, thanks for posting your steps. Running align_image_stack from > the > > > command line sounds like a nice idea. You could also output the result > into > > > the .pto file, I believe. I don't know about pre-fusing each stack > into a > > > 24-bit jpg. I would be concerned that you could end up with images > that > > > have very different dynamic ranges and that don't blend well into the > final > > > pano. E.g. if one stack has sunset-to-dark and the other is all-dark. > But > > > maybe enfuse deals with that properly or maybe those scenarios don't > fuse > > > well either way... If I have the time I may give the two approaches a > spin. > > > Another advantage of not pre-fusing is that align_image_stack > sometimes has > > > difficulties, specially when large areas are very dark or blown out in > one > > > of the images of the bracket and it's nice to be able to adjust the > control > > > points in hugin. Ah. maybe we can collect some more wisdom and then > turn > > > this thread into a wiki page.
> > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Hugin and other free panoramic software" group. > > > A list of frequently asked questions is available at: > > > http://wiki.panotools.org/Hugin_FAQ > > > To post to this group, send email to hugi...@googlegroups.com<javascript:> > > > To unsubscribe from this group, send email to > > > hugin-ptx+...@googlegroups.com <javascript:> > > > For more options, visit this group at > > > http://groups.google.com/group/hugin-ptx
> > -- > > You received this message because you are subscribed to the Google > Groups "Hugin and other free panoramic software" group. > > A list of frequently asked questions is available at: > http://wiki.panotools.org/Hugin_FAQ > > To post to this group, send email to hugi...@googlegroups.com<javascript:> > > To unsubscribe from this group, send email to > hugin-ptx+...@googlegroups.com <javascript:> > > For more options, visit this group at > http://groups.google.com/group/hugin-ptx
> -- > ** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 > ** > ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > The plan was simple, like my brother-in-law Phil. But unlike > Phil, this plan just might work.
I do mine in 48-bit TIF, which is 16-bit per channel RGB. 48-bit color is my DSLR's native depth.
Real HDR is done using multiple frames, shot at various exposure ranges so the darkest exposure gives you no clipping at the dark end, and the highest exposure gives you no clipping at the bright end, with enough intermediate frames to give you good exposures through the midranges. Enfusing with the full 48-bit color range gives you better results. When Hugin finishes an image for image, it's a 48-bit color TIFF, not a 24-bit TIF.
I don't think enfuse reduces the dynamic range to 24-bit color.
> Roger, I'm not sure things are as drastic as you make them when you say
> "What is needed for HDR work, is either a floating point format
> (about 12 bits per channel, would be sufficient, but 32 bits per channel
> are normally used in hugin) or a high-bit-count fixed-point format."
> Yes, to get the best possible results, you are correct. However, as far
> as I can tell, when Carlos runs enfuse on a stack, enfuse compresses the
> dynamic range into the available 24 RGB bits. So if the stack has a
> large dynamic range, he's loosing some color subtlety and some sensor
> noise, but he's not loosing highlights or shadows per-se. If he's then
> putting everything together into one 24-bit RGB image at the end without
> manual tone mapping, I'm not sure there is much quality to be gained by
> going through 48-bit or 96-bit intermediate images. Maybe you or someone
> has some examples where it does make a difference?
> On Monday, November 19, 2012 3:06:02 AM UTC-8, rew wrote:
> Guys,
> when you say "24 bit jpeg" almost everybody thinks of this as "full
> color (RGB), 8 bits per channel".
> What is needed for HDR work, is either a floating point format (about
> 12 bits per channel, would be sufficient, but 32 bits per channel are
> normally used in hugin) or a high-bit-count fixed-point
> format. Something like 16 might get close, but 24 bits per channel.
> may be more appropriate.
> JPEG format is not appropriate for non-8-bit-per-channel-data. So
> Carlos in the workflow that you describe you're truncating a lot of
> information when you output your intermediate files into the 8-bit
> jpeg format.
> So... Carlos, I would suggest that you try saving your intermediate
> files as tiff, and then find out what options you have to create a
> 32-bit-per-channel-floating-point intermediate file. Then Hugin can,
> while stitching, apply proper exposure corrections and things like
> that. (or are you fixing the exposure bracket for the whole panorama?
> In that case Hugin's exposure correction should be unneccessary.)
> Roger.
> On Mon, Nov 19, 2012 at 08:35:41AM -0200, Carlos Eduardo G. Carvalho
> (Cartola) wrote:
> > Hi,
> > just to clarify, I don't work with 24-bit jpg. I usually shoot in
> JPG and
> > work with it in 8 bits. But alit_image_stack can deal with tif
> and you can
> > work with tif all the time. I just put JPG in my example because
> I use it :)
> > I sometimes have some ghosts in the final result of the enfusion,
> but I
> > doubt if it would solve using a larger image. I think they happen
> because
> > of parallax differences. I can clearly see that part of the image
> is good
> > and another is not, so I think align_image_stack has done it's
> job. The
> > solution (maybe) would be distort the image before fuse them and
> maybe
> > hugin does that, I don't know. In fact I have never tried to make
> the
> > exposure stacks directly into hugin. Maybe I should also give it
> a try :)
> > And surely the best option of all is to stabilize the camera to
> shoot, but
> > sometimes it is a little hard to do:
> > > Carlos, thanks for posting your steps. Running
> align_image_stack from the
> > > command line sounds like a nice idea. You could also output the
> result into
> > > the .pto file, I believe. I don't know about pre-fusing each
> stack into a
> > > 24-bit jpg. I would be concerned that you could end up with
> images that
> > > have very different dynamic ranges and that don't blend well
> into the final
> > > pano. E.g. if one stack has sunset-to-dark and the other is
> all-dark. But
> > > maybe enfuse deals with that properly or maybe those scenarios
> don't fuse
> > > well either way... If I have the time I may give the two
> approaches a spin.
> > > Another advantage of not pre-fusing is that align_image_stack
> sometimes has
> > > difficulties, specially when large areas are very dark or blown
> out in one
> > > of the images of the bracket and it's nice to be able to adjust
> the control
> > > points in hugin. Ah. maybe we can collect some more wisdom and
> then turn
> > > this thread into a wiki page.
> --
> ** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ **
> +31-15-2600998 **
> ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233
> **
> *-- BitWizard writes Linux device drivers for any device you may
> have! --*
> The plan was simple, like my brother-in-law Phil. But unlike
> Phil, this plan just might work.
> I don't think enfuse reduces the dynamic range to 24-bit color.
Well, at least I make enfuse do this as I make the output from it in a
24-bit RGB JPG.
Surely more information is capable of giving more quality and maybe in some
situations I would see some better results, mainly if I use it in the
intermediate steps. As far as I've experienced until now I don't even see
much need to use raw shooting. I've already tested it some times and when I
am shooting a hard scene I shoot raw, but in 90% of the cases I am pretty
much satisfied with shooting and working with 24-bit RGB JPGs.
I usually only publish on the web. I have already printed some pictures in
fine quality and thought that there it could make more visual difference
for me, but at the computer screen my poor eyes are satisfied till now :)
> I don't think enfuse reduces the dynamic range to 24-bit color.
> Well, at least I make enfuse do this as I make the output from it in a
> 24-bit RGB JPG.
Yes, you can do that. I prefer to end with 16-bit TIF.
> Surely more information is capable of giving more quality and maybe in
> some situations I would see some better results, mainly if I use it in
> the intermediate steps. As far as I've experienced until now I don't
> even see much need to use raw shooting. I've already tested it some
> times and when I am shooting a hard scene I shoot raw, but in 90% of the
> cases I am pretty much satisfied with shooting and working with 24-bit
> RGB JPGs.
On some images now, I finish by pulling the 16-bit TIF in Luminance HDR and tonemap the image.
> I usually only publish on the web. I have already printed some pictures
> in fine quality and thought that there it could make more visual
> difference for me, but at the computer screen my poor eyes are satisfied
> till now :)
You can't really see HDR on display screens or prints, because high-dynamic range means wider dynamic range than display or print technologies can reproduce. HDR is for all of the processing up to the final output. I prefer TIF for that, too, or PNG, just because even at 100% quality, JPG loses color information. But I'm weird about that ...
