[Hugin-devs] [Bug 2000019] [NEW] Take into account digital zoom ratio EXIF tag in the computation of the HFOV

2022-12-18 Thread Jean-Daniel Bancal
Public bug reported:

The horizontal field of view (HFOV) property of a picture is critical to
allow proper stitching. Inadequate values forbid automatic detection of
control points, which is a central piece (and major added value) in
Hugin's, and hence breaks the automated stitching workflow. Thankfully,
Hugin automatically computes the HFOV value for pictures with valid EXIF
data. Again, this is a great benefit which avoids manual computation for
each lense and lengthy entry of manual data.

In traditional cameras, the HFOV is mainly a function of the lense's
focal length: adjusting the zoom between two shots with the same camera
results in different focal lengths for each shot. This information is
correctly read and interpreted into distinct HFOV by Hugin. In contrast,
modern digital cameras, such as samsung cell phones to cite just one
widely-spread example, typically feature fixed lenses with a unique
focal length. Yet, it is still possible to take shots with different
zoom factors (or, say, to be given pictures to stitch that were taken
with such a device and with different zoom factors...). In this case,
the focal length information is identical for all shots and the zoom
information is encoded in a distinct EXIF tag, called the 'Digital Zoom
Ratio'. Currently, it seems that Hugin doesn't take advantage of this
tag, hence wrongly assuming that all pictures taken with the same
'digital camera' have an identical HFOV. This causes Hugin to be unable
to stitch the pictures, because it typically fails to find control
points.

This might be relatively straightforward to fix given that:
  - The digital zoom ratio affects the HFOV in a simple manner, so it should be 
possible to compute the HFOV by taking into account both the lense's focal 
length and the digital zoom ratio (when available)
  - Hugin seems to rely on Exiv2 to acquire EXIF data from files, which 
supports the 'Digital Zoom Ratio' tag, so it should be possible to access this 
tag with the existing infrastructure. I checked that the command `exiv2 -pt 
image.jpg` on my images return the tag `Exif.Photo.DigitalZoomRatio` with the 
correct value. The same values are also read by Exiftool (checked with command 
`exiftool image.jpg`).

I'm using Hugin 2021.0.0.52df0f76c700 (built with Exiv2 0.27.5) on
Ubuntu 22.04.1. The version of Exiv2 that I used in the command line is
also 0.27.5.

** Affects: hugin
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/219

Title:
  Take into account digital zoom ratio EXIF tag in the computation of
  the HFOV

Status in Hugin:
  New

Bug description:
  The horizontal field of view (HFOV) property of a picture is critical
  to allow proper stitching. Inadequate values forbid automatic
  detection of control points, which is a central piece (and major added
  value) in Hugin's, and hence breaks the automated stitching workflow.
  Thankfully, Hugin automatically computes the HFOV value for pictures
  with valid EXIF data. Again, this is a great benefit which avoids
  manual computation for each lense and lengthy entry of manual data.

  In traditional cameras, the HFOV is mainly a function of the lense's
  focal length: adjusting the zoom between two shots with the same
  camera results in different focal lengths for each shot. This
  information is correctly read and interpreted into distinct HFOV by
  Hugin. In contrast, modern digital cameras, such as samsung cell
  phones to cite just one widely-spread example, typically feature fixed
  lenses with a unique focal length. Yet, it is still possible to take
  shots with different zoom factors (or, say, to be given pictures to
  stitch that were taken with such a device and with different zoom
  factors...). In this case, the focal length information is identical
  for all shots and the zoom information is encoded in a distinct EXIF
  tag, called the 'Digital Zoom Ratio'. Currently, it seems that Hugin
  doesn't take advantage of this tag, hence wrongly assuming that all
  pictures taken with the same 'digital camera' have an identical HFOV.
  This causes Hugin to be unable to stitch the pictures, because it
  typically fails to find control points.

  This might be relatively straightforward to fix given that:
- The digital zoom ratio affects the HFOV in a simple manner, so it should 
be possible to compute the HFOV by taking into account both the lense's focal 
length and the digital zoom ratio (when available)
- Hugin seems to rely on Exiv2 to acquire EXIF data from files, which 
supports the 'Digital Zoom Ratio' tag, so it should be possible to access this 
tag with the existing infrastructure. I checked that the command `exiv2 -pt 
image.jpg` on my images return the tag `Exif.Photo.DigitalZoomRatio` with the 
correct value. The same values are also read by Exiftool (checked with command 
`exiftool image.j

[Hugin-devs] [Bug 1998020] Re: Hugin Calibrate Lens asserts on start

2022-12-18 Thread tmodes
** Changed in: hugin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1998020

Title:
  Hugin Calibrate Lens asserts on start

Status in Hugin:
  Fix Released

Bug description:
  When I start "Hugin Calibrate Lens" from my Debian Testing Cinnamon
  Start Menu, a popup labelled "calibrate_lens_gui" pops up saying "An
  assertion failed!"

  Hugin version: 2021.0.0+dfsg-3

  
  ASSERT INFO:
  ./src/gtk/bitmap.cpp(541): assert ""width > 0 && height > 0"" failed in 
Create(): invalid bitmap size

  BACKTRACE:
  [1] wxBitmap::Create(int, int, int)
  [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
  [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
  [4] wxEvtHandler::TryHereOnly(wxEvent&)
  [5] wxEvtHandler::ProcessEventLocally(wxEvent&)
  [6] wxEvtHandler::ProcessEvent(wxEvent&)
  [7] wxEvtHandler::SafelyProcessEvent(wxEvent&)
  [8] wxWindow::DoSetSize(int, int, int, int, int)
  [9] wxBoxSizer::RepositionChildren(wxSize const&)
  [10] wxStaticBoxSizer::RepositionChildren(wxSize const&)
  [11] wxSizer::Layout()
  [12] wxSizerItem::SetDimension(wxPoint const&, wxSize const&)
  [13] wxBoxSizer::RepositionChildren(wxSize const&)
  [14] wxSizer::Layout()
  [15] wxWindowBase::Layout()
  [16] wxWindowBase::InternalOnSize(wxSizeEvent&)
  [17] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
  [18] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
  [19] wxEvtHandler::TryHereOnly(wxEvent&)
  [20] wxEvtHandler::ProcessEventLocally(wxEvent&)
  [21] wxEvtHandler::ProcessEvent(wxEvent&)
  [22] wxEvtHandler::SafelyProcessEvent(wxEvent&)
  [23] wxWindow::DoSetSize(int, int, int, int, int)
  [24] wxWindowBase::WXSetInitialFittingClientSize(int, wxSizer*)
  [25] wxSizer::Fit(wxWindow*)
  [26] wxSizerXmlHandler::Handle_sizer()
  [27] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, 
wxObject*)
  [28] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool)
  [29] wxPanelXmlHandler::DoCreateResource()
  [30] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, 
wxObject*)
  [31] wxSizerXmlHandler::Handle_sizeritem()
  [32] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, 
wxObject*)
  [33] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool)
  [34] wxSizerXmlHandler::Handle_sizer()
  [35] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, 
wxObject*)
  [36] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool)
  [37] wxFrameXmlHandler::DoCreateResource()
  [38] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, 
wxObject*)
  [39] wxXmlResource::LoadFrame(wxFrame*, wxWindow*, wxString const&)
  [40] wxEntry(int&, wchar_t**)
  [41] __libc_start_main

  Clicking "Continue" brings the same popup again. Clicking "Stop"
  closes the program. So Calibrate lens is not usable.

  This reminds me of an earlier bug #1909484 (2020.0.0
  calibrate_lens_gui - multiple assertions at startup) with the previous
  version. This one has been fixed by the wx-widgets team (issue 18520)
  - they said, they would check width/height instead bmpData. Seems,
  Hugin still calls wxBitmap:Create with an invalid bitmap.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1998020/+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 1999961] Re: arm64 build for macOS

2022-12-18 Thread tmodes
We are only doing a source code release.
The corresponding binaries are contributed by the community. So it needs 
volunteer to do the build.


** Changed in: hugin
   Status: New => Opinion

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/161

Title:
  arm64 build for macOS

Status in Hugin:
  Opinion

Bug description:
  Could you guys please release a binary for macOS users on the new
  Apple Silicon hardware?

  Apple won't be supporting x86_64 forever and it'd be great to have
  native builds for arm64 on macOS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/161/+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