hugin-devs team mailing list archive

[Andrew Nitschke <1970518@xxxxxxxxxxxxxxxxxx>]

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_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

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1970518/+subscriptions