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: > > > http://cartola.org/fotos/_cache/Diversas/Engenhocas/_screen/20111004-mastro.jpg > > > > > Cheers, > > > > Carlos E G Carvalho (Cartola) > > http://cartola.org/360 > > http://www.panoforum.com.br/ > > > > > > > > 2012/11/18 TvE <[email protected] <javascript:>> > > > > > 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 > > > [email protected]<javascript:> > > > To unsubscribe from this group, send email to > > > [email protected] <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 [email protected]<javascript:> > > To unsubscribe from this group, send email to > [email protected] <javascript:> > > For more options, visit this group at > http://groups.google.com/group/hugin-ptx > > -- > ** [email protected] ** 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
