Okay, now I understand, thanks for the clarification. Lux combines the remapping and HDR merging 'under the same roof', so the overexposedness can be detected in the pixel pipeline and does not need to be stored to an intermediate file. I had hoped to suggest hugin_hdrmerge as an alternative to lux users who found lux too 'automatic' for HDR merging, but I misunderstood what it does. So it's probably better to suggest software like align_image_stack to them, as an alternative to the use of "lux --hdr_merge=yes my.pto" which hdr-merges the images in a pto in one (automatic) go. On Thursday, July 1, 2021 at 5:31:11 PM UTC+2 T. Modes wrote:
> kfj schrieb am Mittwoch, 30. Juni 2021 um 23:05:13 UTC+2: > >> I saw hugin produce such pgm files, and I could never figure out why they >> would be needed: the exr should have all the nececssary information, >> because it holds linear RGBA. What's the pgm good for? >> > > In Hugins HDR workflow all input images are remapped to the output > projection. In the same time they are converted into the same linear > colorspace - it corrects the exposure, vignetting (and also white balance). > But then the information about under- and over exposed pixels is lost. This > information is transferred to hugin_hdrmerge with the _gray.pgm files and > helps to merge the individual images. > > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/dce16931-f0cb-4265-a87d-6f24c58c9576n%40googlegroups.com.
