enfuse creates too large of image with black border on right and bottom

[Andrew Nitschke]

BLOT:
enfuse is creating too large of an image with black borders on the left and right. Looking into the size of the resulting image I can see that the image is the expected with + an additional amount that is the same as the "left" value specified in the crop UI of enpass.

DETAILS:

"repro.zip/src1 - src3_blended_fused.jpg" is the output image that is created from stitching the "repro.zip/repro.pto" file. Notice that the size of the image is 2000x1700 but it should be 1800x1500 based on the crop settings of that .pto file.

If I do a dryrun with hugin_executor I can see that enfuse is being passed all the right options in terms of the size of the image:

[anitschk@RedWingBlackBird hdrRepro]$ hugin_executor --dry-run --stitching repro.pto
/usr/bin/nona -v -z LZW -r ldr -m TIFF_m --ignore-exposure -o src1\ -\ src3_exposure_layers_ /srv/media/photos/Margot\ Aven\ PCT\ 2022/TODO\ AndyAndMaryVisit/src/hdrRepro/repro.pto
enblend -f1800x1500+200+200 --compression=LZW -o src1\ -\ src3_exposure_0000.tif -- src1\ -\ src3_exposure_layers_0000.tif
enblend -f1800x1500+200+200 --compression=LZW -o src1\ -\ src3_exposure_0001.tif -- src1\ -\ src3_exposure_layers_0001.tif
enblend -f1800x1500+200+200 --compression=LZW -o src1\ -\ src3_exposure_0002.tif -- src1\ -\ src3_exposure_layers_0002.tif
enfuse -f1800x1500+200+200 --compression=90 -o src1\ -\ src3_blended_fused.jpg -- src1\ -\ src3_exposure_0000.tif src1\ -\ src3_exposure_0001.tif src1\ -\ src3_exposure_0002.tif
exiftool -overwrite_original -TagsFromFile /srv/media/photos/Margot\ Aven\ PCT\ 2022/TODO\ AndyAndMaryVisit/src/hdrRepro/src1.JPG -WhitePoint -ColorSpace -@ /usr/share/hugin/data/hugin_exiftool_copy.arg -@ /tmp/hedLAtKd src1\ -\ src3_blended_fused.jpg
rm /tmp/hedLAtKd src1\ -\ src3_exposure_layers_0000.tif src1\ -\ src3_exposure_layers_0001.tif src1\ -\ src3_exposure_layers_0002.tif src1\ -\ src3_exposure_0000.tif src1\ -\ src3_exposure_0001.tif src1\ -\ src3_exposure_0002.tif

Additionally if I tweek the enfuse command to take this bug into account then I can "fix" the bug:

enfuse -f1600x1300+200+200 --compression=90 -o src1\ -\ src3_blended_fused_HACK_FIXED.jpg -- src1\ -\ src3_exposure_0000.tif src1\ -\ src3_exposure_0001.tif src1\ -\ src3_exposure_0002.tif

See the attached repro.zip/src3_blended_fused_HACK_FIXED.jpg and you can see that the image size is now correct.

This feels like it is probably some sort of recent regression where enfuse isn't parsing the size it is passed correctly. I am just not sure the right place to start looking for this issue. Anyone have any pointers?

SYSTEM INFO:

System info from Help Menu -> About -> System:

Operating System: Linux 5.17.1-arch1-1 x86_64
Architecture: 64 bit
Free memory: 417004 kiB

Hugin
Version: 2021.0.0.52df0f76c700
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/anitschk/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0.5
wxWidgets Library (wxGTK port)
Version 3.0.5 (Unicode: wchar_t, debug level: 1),
compiled at Jan 5 2022 10:10:46

Runtime version of toolkit used is 3.24.
Compile-time GTK+ version is 3.24.31.

libpano13: 2.9.21
Boost: 1.78.0
Exiv2: 0.27.5
SQLite3: 3.38.2
Vigra: 1.11.1
LittleCMS2: 2.13

[tmodes (tmodes)]

Moving to enblend/enfuse bug tracker - it is not a Hugin bug, the parameters are correctly transferred to enfuse/enblend.

I tested your repro test case on 2 different system. On all system the output is correctly created without black borders. It works fine with the released version 4.2 and also with current head of default branch (version 4.3-8243911d8684).
The used enblend version is from the development branch, but is nearly 3 years old (enblend 4.3-f3e6c6c88e6e).
Please test again with current head.
If this version shows the same bug, please post the results of "enblend --version --verbose" and "enblend --show-software-components". Thanks

[Andrew Nitschke (andrew-b-nitschke)]

Thanks for the quick response.

Someone already setup building enblend/enfuse from source for Arch AUR so it was pretty easy to build the latest branch and try it out. (for anyone else on arch that may also be facing this issue https://aur.archlinux.org/packages/enblend-hg )

As you reported, When I ran the repro steps with the default branch (4.3-8243911d8684) I am also seeing that this bug is fixed.

I am not sure what the next step is here, mark the bug as fixed and report the issue to the Arch package maintainer so Arch can update to the latest version?

[tmodes (tmodes)]

Thanks for the response.
So I'm setting the bug to fixed.
So the next step would be to inform the package manager so that they update their package.

[Andrew Nitschke (andrew-b-nitschke)]

Just to close the loop for anyone else that stumbles across this, I have created a the following bug in the Arch Linux bug tracker to track this issue in Arch:

https://bugs.archlinux.org/task/74575