[Hugin-devs] [Bug 1970518] Re: enfuse creates too large of image with black border on right and bottom
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 -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1970518 Title: enfuse creates too large of image with black border on right and bottom Status in Enblend: Fix Committed Bug description: 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_.tif -- src1\ -\ src3_exposure_layers_.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_.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_.tif src1\ -\ src3_exposure_layers_0001.tif src1\ -\ src3_exposure_layers_0002.tif src1\ -\ src3_exposure_.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_.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 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1970518/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1970518] Re: enfuse creates too large of image with black border on right and bottom
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. ** Changed in: enblend Status: Incomplete => Fix Committed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1970518 Title: enfuse creates too large of image with black border on right and bottom Status in Enblend: Fix Committed Bug description: 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_.tif -- src1\ -\ src3_exposure_layers_.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_.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_.tif src1\ -\ src3_exposure_layers_0001.tif src1\ -\ src3_exposure_layers_0002.tif src1\ -\ src3_exposure_.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_.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 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1970518/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1970518] Re: enfuse creates too large of image with black border on right and bottom
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? -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1970518 Title: enfuse creates too large of image with black border on right and bottom Status in Enblend: Incomplete Bug description: 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_.tif -- src1\ -\ src3_exposure_layers_.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_.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_.tif src1\ -\ src3_exposure_layers_0001.tif src1\ -\ src3_exposure_layers_0002.tif src1\ -\ src3_exposure_.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_.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 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1970518/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1970518] Re: enfuse creates too large of image with black border on right and bottom
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 ** Project changed: hugin => enblend ** Changed in: enblend Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1970518 Title: enfuse creates too large of image with black border on right and bottom Status in Enblend: Incomplete Bug description: 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_.tif -- src1\ -\ src3_exposure_layers_.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_.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_.tif src1\ -\ src3_exposure_layers_0001.tif src1\ -\ src3_exposure_layers_0002.tif src1\ -\ src3_exposure_.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_.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 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1970518/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
