I've noticed two odd issues with Hugin 2024.0.1

[David W. Jones]

Good afternoon!

I use self-compiled 2024.01 on Debian Bookworm.

Images get left out of generated EXR files

When I make a panorama, I usually use the Autocrop option (not HDR Autocrop or Autocrop Outside) and have Hugin output both a TIF and an EXR version. Quite often now, the TIF has the full panorama, but the EXR version is missing the first image when only part of the first image is included in the crop. I would think that Hugin would include all parts of images that are included in the crop area in both formats.

Ideas?

Hugin PTO Generator misreads focal length information

I often output a series of TIF images using RawTherapee, select those images and use the Send To Hugin PTO Generator, then open the resulting PTO file. When I checked the focal length settings in the generated PTO file, the focal lengths will be noticeably off. I just checked now; images with focal lengths of 28mm were read by the PTO Generator as 46mm focal length.

This throws off subsequent alignment, barrel distortion, and other corrections.

If I start a new PTO file, then drag and drop the same images into the Hugin Photos tab, Hugin reads the focal length correctly. Why is the PTO Generator misreading it while Hugin gets it right?

Ideas?

Thanks for a delightful program I use almost daily!

-- 
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

[T. Modes]

GnomeNomad schrieb am Donnerstag, 23. Januar 2025 um 06:40:03 UTC+1:

I use self-compiled 2024.01 on Debian Bookworm.

Images get left out of generated EXR files

When I make a panorama, I usually use the Autocrop option (not HDR Autocrop or Autocrop Outside) and have Hugin output both a TIF and an EXR version. Quite often now, the TIF has the full panorama, but the EXR version is missing the first image when only part of the first image is included in the crop. I would think that Hugin would include all parts of images that are included in the crop area in both formats.

Ideas?

No. Essential informations are missing. You are outputting a HDR pano, right? One time type set the EXR and then to TIF?

Which images are affected? The remapped single images, the stacked images or the blended images? If the latter, which blender used: enblend or the internal? When enblend which version?

Hugin PTO Generator misreads focal length information

I often output a series of TIF images using RawTherapee, select those images and use the Send To Hugin PTO Generator, then open the resulting PTO file. When I checked the focal length settings in the generated PTO file, the focal lengths will be noticeably off. I just checked now; images with focal lengths of 28mm were read by the PTO Generator as 46mm focal length.

This throws off subsequent alignment, barrel distortion, and other corrections.

If I start a new PTO file, then drag and drop the same images into the Hugin Photos tab, Hugin reads the focal length correctly. Why is the PTO Generator misreading it while Hugin gets it right?

Ideas?

Both program use the some code. Maybe you set the field of view in your call of pto_gen (- -fov switch)?

Check of progress messages from pto_gen. Or run pto_gen from the terminal and check the output in the terminal.

If it is still wrong, provide a sample image for checking.

Thomas

[David W. Jones]

Thanks, Thomas!

On 1/23/25 06:17, 'T. Modes' via hugin and other free panoramic software wrote:

GnomeNomad schrieb am Donnerstag, 23. Januar 2025 um 06:40:03 UTC+1:

I use self-compiled 2024.01 on Debian Bookworm.

Images get left out of generated EXR files

When I make a panorama, I usually use the Autocrop option (not HDR Autocrop or Autocrop Outside) and have Hugin output both a TIF and an EXR version. Quite often now, the TIF has the full panorama, but the EXR version is missing the first image when only part of the first image is included in the crop. I would think that Hugin would include all parts of images that are included in the crop area in both formats.

Ideas?

No. Essential informations are missing. You are outputting a HDR pano, right?

Sorry. Yes. The TIFF is 16-bit, the EXR is its usual color depth. 32-bit floating point, I think.

One time type set the EXR and then to TIF?

I usually select both the TIF and EXR formats for output at the same time. They're using the same crop.

Which images are affected?

Usually the first image in the panorama. Sometimes the last image. Very rarely, I'll spot a black notch at top or bottom somewhere in the panorama. The TIFF version shows no notches

Manually adjusting the crop to exclude it eliminates the notch, but I wonder if they appear because Hugin left out an image in the EXR panorama that covered that notch, but didn't leave it out when producing the TIF version of the panorama.

The remapped single images, the stacked images or the blended images?

The blended panorama image. Although I suppose I can check to see if it's actually outputting the missing single images or if they're coming out wrong. In the blended panorama image, the missing images just show as black.

If the latter, which blender used: enblend or the internal? When enblend which version?

Thanks. I only use enblend, v4.2, which comes with Debian Bookworm.

Hugin PTO Generator misreads focal length information

I often output a series of TIF images using RawTherapee, select those images and use the Send To Hugin PTO Generator, then open the resulting PTO file. When I checked the focal length settings in the generated PTO file, the focal lengths will be noticeably off. I just checked now; images with focal lengths of 28mm were read by the PTO Generator as 46mm focal length.

This throws off subsequent alignment, barrel distortion, and other corrections.

If I start a new PTO file, then drag and drop the same images into the Hugin Photos tab, Hugin reads the focal length correctly. Why is the PTO Generator misreading it while Hugin gets it right?

Ideas?

Both program use the some code. Maybe you set the field of view in your call of pto_gen (- -fov switch)?

Check of progress messages from pto_gen. Or run pto_gen from the terminal and check the output in the terminal.

I did that. Running pto_gen *.tif without any other command line options produced a PTO file that shows image focal lengths of 57mm when opened in Hugin, for images that were shot at 35mm. My camera's crop factor is 1. It's a Sony A7R IVA, 61-mpix full-frame.

I've never used any command line options with pto_gen. I just select files, right click, and pick Open With > Hugin PTO Generator. Is there some place where such options might be set?

If it is still wrong, provide a sample image for checking.

At 270-280MB per image, they're a bit large. Here's a link to one:

https://drive.google.com/file/d/109neMWTMHWKZjOCobESej7raZ5EM7Ivu/view?usp=sharing

Note that Hugin reports the correct focal length when that image is dropped into the Photos tab.

Thanks again!

[David W. Jones]

On 1/23/25 12:44, David W. Jones wrote:

Thanks, Thomas!

On 1/23/25 06:17, 'T. Modes' via hugin and other free panoramic software wrote:

GnomeNomad schrieb am Donnerstag, 23. Januar 2025 um 06:40:03 UTC+1:

I use self-compiled 2024.01 on Debian Bookworm.

Images get left out of generated EXR files

When I make a panorama, I usually use the Autocrop option (not HDR Autocrop or Autocrop Outside) and have Hugin output both a TIF and an EXR version. Quite often now, the TIF has the full panorama, but the EXR version is missing the first image when only part of the first image is included in the crop. I would think that Hugin would include all parts of images that are included in the crop area in both formats.

Ideas?

No. Essential informations are missing. You are outputting a HDR pano, right?

Sorry. Yes. The TIFF is 16-bit, the EXR is its usual color depth. 32-bit floating point, I think.

One time type set the EXR and then to TIF?

I usually select both the TIF and EXR formats for output at the same time. They're using the same crop.

Which images are affected?

Usually the first image in the panorama. Sometimes the last image. Very rarely, I'll spot a black notch at top or bottom somewhere in the panorama. The TIFF version shows no notches

Manually adjusting the crop to exclude it eliminates the notch, but I wonder if they appear because Hugin left out an image in the EXR panorama that covered that notch, but didn't leave it out when producing the TIF version of the panorama.

The remapped single images, the stacked images or the blended images?

The blended panorama image. Although I suppose I can check to see if it's actually outputting the missing single images or if they're coming out wrong. In the blended panorama image, the missing images just show as black.

If the latter, which blender used: enblend or the internal? When enblend which version?

Thanks. I only use enblend, v4.2, which comes with Debian Bookworm.

I just did a test of a 3-frame panorama, enblend vs internal blender. Results:

Enblend: Last image on the right end of the panorama is missing. That part of the panorama shows as black.

Internal: No image is missing, but the image colors are all wrong and there's a noticeable straight seam between the middle frame and the last frame.

[T. Modes]

Sorry, but the problem is that you mixes up different things.

GnomeNomad schrieb am Donnerstag, 23. Januar 2025 um 23:44:10 UTC+1:

No. Essential informations are missing. You are outputting a HDR pano, right?

Sorry. Yes. The TIFF is 16-bit, the EXR is its usual color depth. 32-bit floating point, I think.

One time type set the EXR and then to TIF?

I usually select both the TIF and EXR formats for output at the same time. They're using the same crop.

When you output TIF and EXR at the same time that there is much more difference than the file format:

The TIF output is LDR type: normal, blended fused or fused blended.

The EXR output is the HDR type.

The file format is not the difference these are completely different workflows.

So you are comparing ..._fused.tif with ..._hdr.exr, right?

 

The remapped single images, the stacked images or the blended images?

The blended panorama image. Although I suppose I can check to see if it's actually outputting the missing single images or if they're coming out wrong. In the blended panorama image, the missing images just show as black.

You should check the intermediate images. Not the input images. Mark the corresponding images type in the stitcher type and check then the output.

I did that. Running pto_gen *.tif without any other command line options produced a PTO file that shows image focal lengths of 57mm when opened in Hugin, for images that were shot at 35mm. My camera's crop factor is 1. It's a Sony A7R IVA, 61-mpix full-frame.

I can't reproduce here. The provided images get from pto_gen a HFOV of 54.5 deg corresponding to a focal length of 35 mm (full frame, crop factor 1) . The same as when I open in Hugin direct.

I've never used any command line options with pto_gen. I just select files, right click, and pick Open With > Hugin PTO Generator. Is there some place where such options might be set?

I can't help here. You need to check where these right click options are stored in your program.

[T. Modes]

There is no need to keep the complete mail in front. Please remove all not necessary parts of last mail in the new answer. This makes it better readable.

GnomeNomad schrieb am Freitag, 24. Januar 2025 um 00:09:33 UTC+1:

Internal: No image is missing, but the image colors are all wrong and there's a noticeable straight seam between the middle frame and the last frame.

The color issue is unknown. There are no reports with reproducer for this issue. For me the internal blender works fine.

The internal blender has two mode: the standard mode is faster, but may left seams. Under options you can choose the seam blend mode which should blend away these seams.

Thomas

[T. Modes]

GnomeNomad schrieb am Donnerstag, 23. Januar 2025 um 23:44:10 UTC+1:

I did that. Running pto_gen *.tif without any other command line options produced a PTO file that shows image focal lengths of 57mm when opened in Hugin, for images that were shot at 35mm. My camera's crop factor is 1. It's a Sony A7R IVA, 61-mpix full-frame.

I had another look on this issue. The cause is probably a wrong entry in your lens database. Pto_gen reads the fov from the lens database.

You can do one! of the following things:

1.) Fix the entry in the database. (Store information from a good pano in the lens database)

2.) Remove the database file. It will recreate an empty database after the next start.

3.) Add --ignore-fov-rectilinear to the pto_gen command line

[David W. Jones]

Where is the database file?

3.) Add --ignore-fov-rectilinear to the pto_gen command line

Thanks for the info. I've used hugin for a number of years, over three camera changes, it's possible old or corrupt values have accumulated.

[T. Modes]

GnomeNomad schrieb am Dienstag, 28. Januar 2025 um 04:33:34 UTC+1:

Where is the database file?

Filename can be found on Help>About, On system tab.

[David W. Jones]

Thanks. I renamed it to something else with Hugin closed. I selected a bunch of TIF files, each with focal length 35mm, opened them with Hugin PTO Generator, got a PTO file, opened it in Hugin, and Hugin reports the focal length as 141.635.

Running pto_gen from the command line generates a PTO that also reports the 35mm focal length as 141.635mm.

Drag-and-dropping the TIFs into a new PTO in Hugin reports the correct 35mm focal length.

As far as I can tell, there are no command line options being set for pto_gen or Hugin anywhere, and I didn't find any option in Hugin about setting anything for pto_gen.

Interesting. I use the Expert interface. If I switch from the Display > General option to Display > EXIF Data, it displays the correct focal length. So maybe there's a glitch in the Display > General option where it *displays* the incorrect value?

Oh, well.

[T. Modes]

GnomeNomad schrieb am Donnerstag, 30. Januar 2025 um 22:58:50 UTC+1:

Running pto_gen from the command line generates a PTO that also reports the 35mm focal length as 141.635mm.

Drag-and-dropping the TIFs into a new PTO in Hugin reports the correct 35mm focal length.

This does not makes sense. Both program use the same code and both read the fov from the lens database. And this works fine with your test image on my system.

Maybe you have 2 versions installed: one which called from the command line and the second one when you call Hugin (I don't know how you start it.).

Some time ago the path to the lens database changed (from ~/.hugindata to $XDG_DATA_HOME/hugin).

Check that only one version is installed.

[David W. Jones]

Of those two, I have only ~/.hugindata. It contains only camlens.db and expressions.ini.

Then I ran find in my ~ folder and it found two camlens.db files. One in .hugindata, the other in .local/share/hugin. That's probably the one from when I compiled 2024.0.1.

I renamed the .hugindata directory and the camlens.db file in .local/share/hugin, ran pto_gen, and Hugin now reports the proper focal length.

Possible causes?

At various times, this system has had Hugin 2022 (installed from the Debian Bookworm repository), 2023 and 2024 (locally compiled from git source). Maybe during the process, Hugin found calens.db in an existing directory (.hugindata/camlens.db), created a new camlens.db file in the new ~/hugin directory, then got confused by having the two copies around? Or something in Hugin preferences was pointing to one (maybe the older location)?

I thought of another possible source of confusion. Over the years, I've changed DSLRs (Minolta Maxxum 7D, Sony SLT-A58, now Sony A7R-IVA) but have been using the same lenses. That's one reason I moved from Minolta to Sony. I like my lenses and have a good collection of them. I use Sony's Minolta-Sony E mount adapter to use them on the A7R. I don't have any E-mount lenses to test with.

I don't know how lenses are stored in the database, but is it possible the lens is stored by name, along with attributes derived from the camera it's on? So the lens was first added to the database (on the Minolta), maybe its attributes were set based on that camera. Then Hugin finds the same lens on a different camera (the A58 or the A7R). Does it update the lens attributes in the database based on the new camera or reuse what's already there? If it updates, does it do a complete update or does it only change parts of the attributes (maybe leaving data that's no longer valid)? If it just reuses existing information, would those existing attributes still be valid when moving from a 6Mpx Minolta to a 20Mpx A58 to a 61Mpx A7R?

Check that only one version is installed.

I ran a sudo find -name 'pto_gen' from the / folder. It found this, ./usr/local/bin/pto_gen, along with entries in the source trees.

info pto_gen reports it as version 2024.0.1.

So there was only one version of pto_gen installed, but there were two copies of the camlens.db in different locations. Maybe the compile/installation process could warn about that in the future?

I'm migrating to a new system. I'll compile on the new system and see where it puts camlens.db.

Thanks for the guidance!

-- 
David W. Jones
gn...@hawaii.rr.com
authenticity, honesty, community