Re: [hugin-ptx] Re: What are the keypoints to create 360 panorama ?

[Bruno Postle]

I would remove the '--linearmatch' parameter, as this prevents the last
image being matched with the first image.

(You could try '--multirow' instead, but this shouldn't be necessary)

Possibly also removing the 'cpclean' command would help in this case, but I
can't test from here.

-- 
Bruno

On Mon, 27 May 2024, 11:39 'Wade Wang' wrote:

> Could anyone tell me how to convert following workflow into a series of
> commands?
>
> Currently I have tested following commands:
>
> ```
>
> pto_gen -p 0 -f 46 -o project.pto *.jpg # -p 0 : rectlinear
> projection type
>
> cpfind -o project.pto --linearmatch --celeste project.pto
> cpclean -o project.pto project.pto
> linefind -o project.pto project.pto
> autooptimiser -a -p -l -s -o project.pto project.pto
> pano_modify --projection=1 --center --straighten --canvas=AUTO --crop=AUTO
> -o project.pto project.pto # projection=1:cylindrical
> nona -v -z LZW -r ldr -m TIFF_m -o project project.pto
> enblend -o final-enblend.jpg project.tif project0001.tif
> project0002.tif project0003.tif project0004.tif project0005.tif
> project0006.tif project0007.tif project0008.tif project0009.tif
> project0010.tif project0011.tif project0012.tif project0013.tif
> project0014.tif project0015.tif
>
> ```
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zi7hY-dQQKt-aP%2Bt05UdU6yYe4QjuZfh6oE4%2BH6cpCD9Q%40mail.gmail.com.

Re: [hugin-ptx] How line CPs really work (to level a panorama)

[Bruno Postle]

On Wed, 22 May 2024, 17:01 'ChameleonScales' wrote:

> Please correct me where I'm wrong or confirm if I'm right.
>
> To my experience and reasoning, horizontal or vertical line CPs never
> affect the relative positions of photos when optimizing. Only the
> orientation of the panoramic sphere as a whole.
>

You can use line control points to align images with each other. This can
be useful when the only features are linear and have no identifiable
'points'.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjnUEdgtykyEkm9zQw4ZydXzxCLD2LMqnEd-44idbxUuA%40mail.gmail.com.

Re: [hugin-ptx] Re: What are the keypoints to create 360 panorama ?

[Bruno Postle]

On Tue, 21 May 2024, 13:49 Wade Wang wrote:

> >  'multirow' is what you want, it tries to match all the ends of
> whatever chains are created after running a 'linearmatch'.


Inspired by this, I find I can achieve my goal (matching only feature
> points between adjacent images and the last image matching the first image)
> by two steps, the first step is run all images with linearmatch, the second
> step is select only the last image and the first image, then run
> linearmatch again or run multirow. But I don't know how to convert the
> second step into command line.
>

'multirow' does all these things automatically, there is no need to run
'linearmatch' first.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgfbXHVo5n-u_mfiEy157ERLysSSfc8xJ2Sd9kDkx0Ycw%40mail.gmail.com.

Re: [hugin-ptx] Re: What are the keypoints to create 360 panorama ?

[Bruno Postle]

On Tue, 21 May 2024, 10:10 Wade Wang wrote:

> 1.I find we can not use --multirow and --linearmatch simultaneously
> because they are mutually exclusive, then can I achieve my goal (matching
> only feature points between adjacent images and the last image matching the
> first image) ?
>

'multirow' is what you want, it tries to match all the ends of whatever
chains are created after running a 'linearmatch'.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiLsbkQqaJU7GnTGbfyvtd5xbCSKtkYKg2u7zGA6nrwdg%40mail.gmail.com.

Re: [hugin-ptx] I am not a member, but I cannot quit receiving mail from the group

[Bruno Postle]

Done, you shouldn't get any more posts from the group - Bruno

On Tue, 7 May 2024, 12:23 Bernard Lang,  wrote:

> Help please
> I try to stop being sent email by the Google Groups "hugin and other free
> panoramic software" group.
> The only answer I received is that the group will not do anything because
> I am
> not a member.
> Can someone help me.
> I think the address used to send me these mails is  bea...@datcha.net
> an address I used many years ago.
> Thanks
> Bernard
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhXvEtKPK5DZ7JWyey%3DpcgKUWLB8%2BssMRyKgbHRbwZ8Fg%40mail.gmail.com.

Re: [hugin-ptx] Re: Xpano

[Bruno Postle]

On Thu, 2 May 2024, 16:54 'T. Modes' wrote:

>
> This is "only" a GUI for the panorama functions in the OpenCV. library It
> does not implement own panorama stitching algorithms.
> In my simple tests the results were good for some projects, but for other
> projects it works not so good.
> There are no possibilities to manually improve/change the result. So it is
> a hit or miss.
>

Multiple tools can be good thing. It would be interesting if any of the
opencv stuff, like feature matching, was dramatically better than the Hugin
equivalent.

It is a shame if it takes a "one shot" approach and doesn't allow any
adjustments, this is the problem with the free Microsoft stitching tool.
Maybe if it had a PTO export it would be more useful.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj8vtR9eG3Dx6EoOmJyD3gbfLkJb3Xuu9EutB%3DX%2BfeTPw%40mail.gmail.com.

Re: [hugin-ptx] Re: Stereo image alignment

[Bruno Postle]

On Wed, 17 Apr 2024, 20:33 Chris wrote:

> OK. It wouldn't have occurred to me do this because there could be ten
> files in the "glob". Would it just take the first 2, and assume that the
> first one was the right-hand image and the second the left-hand?


align_image_stack will align as many images as you like. It was originally
devised for creating HDR images from bracketed exposure stacks, which
typically have five or more photos.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zghj1WfLc5h3_DjqZqBLMfBrEJwKTKmyk5%3DGON45NgO3Q%40mail.gmail.com.

Re: [hugin-ptx] Re: Stereo image alignment

[Bruno Postle]

On Wed, 17 Apr 2024, 07:13 Chris wrote:

> T modes:"*No, you can also use placeholder like ? or *. "*
>

This is undocumented so far as I can see.
>

This is normal filename globbing. The ? and * characters are usually
expanded into a list of files by the operating system. align_image_stack
only sees the list of files.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhOWpGra%3DKbBvqH_VOUWTVzCM4hUb5AfsHKqPbS5e7THw%40mail.gmail.com.

Re: [hugin-ptx] Disappearing posts

[Bruno Postle]

First posts from users stay in the moderation queue until they get approved
(I'm a bit slow today as am at a theme park) - Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhvjLJN4%2BHxfF5DW3-nwkDEgCMoLW3A_GT3ArHL2n08rQ%40mail.gmail.com.

Re: [hugin-ptx] What free software to stitch photos that exactly adjoin?

[Bruno Postle]

You could do this in Hugin, but it would be easier to use something like
ImageMagick which has an 'append' function to do this - Bruno

On Sun, 10 Mar 2024, 14:24 Joseph Elfelt wrote:

> I wrote software that can take a series of screenshots that exactly
> adjoin.  Each screenshot is part of a map.  Currently I am using an older
> version of photoshop to stitch the screenshots together into a large JPG.
> While this works fine, I am looking for recommendations for free software
> that will work on a windows 10 PC.
>
> Again, the screenshots exactly adjoin.  There is no overlap to match up.
>
> A typical finished image will consist of 25 screenshots.  5 across and 5
> down.
>
> Is Hugin a good choice for this or should I look elsewhere?
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhLsu5KH%3Dii%2BextPkdmftddD2QgKrVCx3g44iHT39MZAw%40mail.gmail.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

[Bruno Postle]

On Fri, 23 Feb 2024, 08:30 'kfj' via hugin and other free panoramic
software wrote:

> Okay, here goes: the code is online
> 
> hugin developers, I can offer a patch against hugin master if you're
> interested in trying it out.


This looks like something that could be #ifdef'd so it can be a Hugin build
option. Though the UI would need some changes to allow heic files in the
file picker etc..

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhD3AvM%3DK8-hEW48QE8Jwp3VRpao1t%3DhdqkufbubH9PcQ%40mail.gmail.com.

Re: [hugin-ptx] dark gradients and sharp edges in landscape panoramas

[Bruno Postle]

Hi Harald, this is a bug in enblend (which is used to join the individual
remapped images). The workaround is to either use the built-in Hugin
blender instead of enblend, or rearrange the order of photos in the project
(drag them up and down in the photos tab) - Bruno

On Tue, 16 Jan 2024, 12:42 Harald Linden wrote:

> Hi list,
>
> I am a bit stumped. I've taken a few pictures of a snowy landscape with
> enough overlap and from a single point in space. The control point
> generation works well, everything is in focus, but the output contains
> single images that, for lack of a better description seem to contain a
> newly added gradient towards dark and then a sharp edge where they end.
>
> I have assembled an example here. It contains the raw input and the
> output. You can see what I mean in "village.jpg" in the second and fourth
> quarter from the left.
>
> https://owncloud.7183.org/index.php/s/RGC6oyWarr7xDej
>
> I don't even have an idea where to start with this. Any help would be
> appreciated.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgaM0qyOmCcY8yhSv8j%2BaH%2Bgu78jz4-zf5vZEa5_0Pa%2Bg%40mail.gmail.com.

Re: [hugin-ptx] Control points improvement proposal

[Bruno Postle]

I can't check the exact usage from here, but look for the 'multirow' option.

This does a linear match (matching consecutive images), then matches the
ends of each resulting disconnected chain together, then finally does a
'prearranged' match (with the hope that the previous steps have put
everything in an approximate position).

On Fri, 5 Jan 2024, 13:14 E Kow wrote:

> Hi,
>
> I am normally stitching around 500 (25horizontal x 20vertical) microscope
> images into one overview image. Hugin is doing a great job, but creating
> the controlpoints is not optimal.
> My images are named "image_1_1", "image_1_2" etc, all the way up to
> "image_25_20".
> If I run Hugin CPFind with default settings, it will compare all 500
> images to each other, which takes several hours. What I normally do is that
> I add the argument "--linearmatch" to CPFind, which then finds all the
> necessary control points for images that are horizontally next to each
> other. However, I also need controlpoints for vertical images, and I have
> not been able to find a good workflow for this. What I currently do is to
> manually select all the images that end with "_1" and run CPFind, manually
> select "_2" and run CPFind etc. It takes a lot of time to select images on
> every 25th row in the photos list, and repeat this at least for every
> second vertical column to have a good result.
> I guess what I am looking for is something like --linearmatch, but it
> should compare every 25th image.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhnJG_cBuuEpR1c_uK8VvqZP5SX2%3Dv4bHGoUK0QWsrHSw%40mail.gmail.com.

Re: [hugin-ptx] Stitching existing files together via Hugin

[Bruno Postle]

There is an old tutorial for 'flat scanned images'.

Basically set the lens type and panorama type to 'rectilinear', use any
number you like for photo angle of view (eg. 10), zero out any roll, pitch
and yaw parameters, and optimise x, y and z for all images except the
anchor.

-- 
Bruno

On Sat, 23 Dec 2023, 20:41 Ron Sipherd wrote:

> I'm unclear on the Hugin settings I need to stitch screen snips that are
> sections of a large web page. I can't get past "Enter lens type", focal
> length etc. which does not apply to this.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zg87JbUkuB4c65RZKoSU3vGU0gwi69FDDHq_%3DvCzZ4dxA%40mail.gmail.com.

Re: [hugin-ptx] Combining small X-rays of circuit boards to make one complete image

[Bruno Postle]

Hi James, a multi-row stitch with 45 images shouldn't be a problem, this
isn't a big project relatively.

It isn't a 'normal' panorama where the camera has a fixed position and the
photos only vary by rotation. Probably the rotation doesn't vary and the
only thing that varies is the camera position - this is much more similar
to joining scans or microscope slides, or assembling a mosaic of a
wall/mural, all of which can be done in Hugin.

Do you have any sample images? With an example it will be easier to say
what approach needs to be taken.

-- 
Bruno

On Thu, 21 Dec 2023, 15:17 James C. Williams wrote:

> My current project is learning to use Hugin to create complete pictures of
> circuit boards from  x-rays to be used for troubleshooting/repairs. I have
> obstacles.
>
> The first obstacle has to do with the fact that I have the latest version
> of Hugin for Windows, but the tutorials are over 10 years old. Is anybody
> working to update the tutorials? If so, I might be able to help.
>
> The second obstacle is that the x-ray image files have no EXIF data, so
> control points must be hand selected for every image.
>
> The third obstacle is that my circuit board is approximately 3" x 17", and
> the x-ray captures an area 1 1/4" x 7/8", so the whole thing takes about 45
> images, (three rows of 15) allowing for overlap. I had to stitch segments
> made up of no more than 5 images at a time, hand-generating control points
> and using Advanced - Fast Panorama Preview for Move/Drag, Straighten to
> remove distortion.
>
> The fourth and current obstacle has to do with stitching together my
> stitched segments.
> The workflow is horizontally oriented, thus prompting my first question:
> 1) Does the tutorial give any relevant details on stitching vertically?
>
> Another current issue is that I tried stitching the first two segments,
> and my first segment image appears in the field about 1/3 the size of the
> 2nd segment. They are the same length, but different heights.
> 2) Why is one image appearing smaller than the other?
>
> The main concern is that this job may be too big for Hugin. I have spent a
> lot of time on this and need it to work. If it does, I need to fine-tune my
> work-flow to be able to do the same on other circuit boards. If I need to
> be using something else, please let me know (gently!).
>
> Any help towards these obstacles would be very much appreciated.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgXLvocR%2BRSqJ4bUGWpaUHNZOBmrbW3JjXHriZPxqf0FA%40mail.gmail.com.

Re: [hugin-ptx] Hugin 2022.0 Black blotches on final stitches

[Bruno Postle]

The black shadows are an enblend bug, they don't appear if you use the
built-in Hugin blender (which is not as sophisticated as enblend, but is
more stable) - Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjsAjMTdykxcMAAp61y5HS_9E3HS5jv3LZsA4y0CpWrUg%40mail.gmail.com.

Re: [hugin-ptx] Hugin 2023.0.0 released

[Bruno Postle]

Thanks Thomas!

As usual there are preview fedora packages in the 'panorama' copr
repository: https://copr.fedorainfracloud.org/coprs/bpostle/panorama/

Otherwise, users of the default hugin package in fedora 39 will get
upgraded in a few days.

-- 
Bruno

On Sat, 11 Nov 2023 at 08:58, T. Modes wrote:
>
> Hi all,
>
> today we are releasing Hugin 2023.0.0

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgGE%3DsQh6iJB5C14Of_fzkdUtaGR%3Dp0wDhzo8UzZCQW%2BQ%40mail.gmail.com.

Re: [hugin-ptx] Hugin 2023.0 beta 1 released

[Bruno Postle]

I see this on fedora, this look a bit messed-up:

$ pkg-config flann --libs
-L/usr/lib64\;-llz4 -lflann -lflann_cpp

On Sun, 24 Sept 2023 at 14:11, T. Modes wrote:

>
> it works here. lz4 is added to FLANN_LIBRARIES automatically by pgkconfig:
>
> from the Cache:
> FLANN_LIBRARIES:INTERNAL=lz4;flann;flann_cpp;lz4
>
> bruno...@gmail.com schrieb am Sonntag, 24. September 2023 um 13:23:16
> UTC+2:
>
> I'm not quite sure where to fix this, but flann-1.9.2 now has a dependency
> on lz4. So I needed to add "-llz4" to get hugin to build with this version
> of flann.
>
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjLuvj74ucvSsDJ4ya0OoHLadK751wxcijm2pHBFvy_kQ%40mail.gmail.com.

Re: [hugin-ptx] Hugin 2023.0 beta 1 released

[Bruno Postle]

I'm not quite sure where to fix this, but flann-1.9.2 now has a dependency
on lz4. So I needed to add "-llz4" to get hugin to build with this version
of flann.

-- 
Bruno

On Sat, 23 Sept 2023 at 08:36, T. Modes wrote:

>
> today we are releasing beta 1 of Hugin 2023.0.0
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgoHtG%3DEUvMBrF%2BD0oM3%3D7HX1YJzaFOT3%3Duf%3DOer9cO0w%40mail.gmail.com.

[hugin-ptx] libpano13-2.9.22 released

[Bruno Postle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

libpano13 is the PanoTools library for panoramic imaging.

A libpano13-2.9.22 tarball has been uploaded to sourceforge, this is
a final release, identical to release candidate rc2:

https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.22/

This release should be binary compatible with previous versions - This means
that prebuilt Hugin executables should just work with this libpano13.

There have been some changes since 2.9.21:

* Fix some insecure data handling in command-line tools, this doesn't affect
Hugin usage. In particular the ShowScript and LaunchAndSendScript functions
have been replaced with non-functional stubs. These functions are not used by
libpano13 itself and have security issues.

* Clean-up some older deprecated C code, minor build improvements

* Fixes big endian check for Mac OS

* Write TIFFTAG_EXTRASAMPLE tag for files with alpha channel

SHA256SUM: affc6830cdbe71c28d2731dcbf8dea2acda6d9ffd4609c6dbf3ba0c68440a8e3 
libpano13-2.9.22.tar.gz

This release is equivalent to HG 923:61865cbe74ba and 2.9.22_rc2

Here is the full ChangeLog since 2.9.21 for more details:

2023-07-31 17:21 +0200  tmodes(61865cbe74ba [tip] 
)

 * file.c, sys_ansi.c:
 Replaced ShowScript and LauncAndSendScript functions with non-
 functional stub

 These function are not used by libpano itself and have security
 issues. Provide for now a stub with a message to stdout to keep the
 ABI constant.

 They will be removed completety in the next version.

2023-06-29 17:38 +0200  tmodes(3005eda747af [tip])

 * adjust.c, file.c, filter.h, parser.c, ptpicker.c, ptutils.h,
 sys_X11.c, sys_ansi.c, sys_mac.c, sys_win.c, tools/PTAInterpolate.c,
 tools/PToptimizer.c:
 Removed ShowScript and LaunchAndSendScript function

 They are not used by libpano itself. For external callers both
 functions are only a thin wrapper around system calls

2023-06-22 21:03 +0200  tmodes(ad7616ee8c26)

 * ColourBrightness.c:
 Correctly initialize variable

 Only needed when we exit with an error in between without running
 the whole algorithm

2023-06-22 20:45 +0200  tmodes(271b8ab4bd66)

 * ColourBrightness.c:
 Use PrintError own formating instead of using a temporary string

2023-06-22 17:54 +0200  tmodes(18ed65577fbc)

 * sys_ansi.c:
 ShowScript: Check if file exists before opening vi

2023-01-21 16:23 +  Bruno Postle(778a20784e24)

 * man/Makefile, version.h:
 Bump version to 2.9.22

2023-01-21 16:11 +  Bruno Postle(da06997f4c2f)

 * ColourBrightness.c:
 Include  if it is available, for the htons
 function/macro (Florian Weimer)

2022-08-03 18:56 +0200  tmodes(4074ee48e255)

 * panorama.h:
 Fixes big endian check for Mac OS Patch by lacard

2022-05-13 17:10 +0200  tmodes(b15a90eb756b)

 * tools/PTuncrop.c:
 Ptuncrop: Fixes usage screen

2022-05-13 17:09 +0200  tmodes(bc7577ea6020)

 * tiff.c:
 Write TIFFTAG_EXTRASAMPLE tag for files with alpha channel (patch by
 Kevin Mehall)

2022-03-31 17:16 +0200  tmodes(ecac1adc7bb6)

 * tests/simpleStitch/simple.pto: deleted file.
 * tests/simpleStitch/simple.pto:
 Removed unused simple.pto

 It is unused and were written by a very early Hugin version

2022-03-13 09:24 +0100  tmodes(4f255f7c9c49)

 * pt_stdint.h: deleted file.
 * CMakeLists.txt, ColourBrightness.c, PTcommon.h, panorama.h,
 panotypes.h, pt_stdint.h:
 Get rid of now obosolete wrapper pt_stdint.h

2022-03-13 09:23 +0100  tmodes(4d676676de11)

 * rgbe.c, rgbe.h:
 Fixes inline for newer compiler versions

2022-03-13 08:48 +0100  tmodes(99edb0ca8a2b)

 * queryfeature.c:
 Fixes assert

 typeof is a gcc extension and not supported by MSVC

2022-03-12 09:01 +0100  tmodes(8c72869bd9f7)

 * ColourBrightness.c, file.c, ptstitch.c:
 Fix some more deprecated uint16/uint32 types

2022-03-06 13:49 +0100  tmodes(f56143ee0588)

 * ColourBrightness.c, tiff.c:
 Use uint16/32_t instead of depreacated uint16/32 types

2022-03-06 13:48 +0100  tmodes(c887e1348df6)

 * CMakeLists.txt:
 Added new lzma.dll name (Windows only)

2021-12-16 22:14 +  Bruno Postle(2d4aeb9ca433)

 * ChangeLog.hg:
 update ChangeLog.hg
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTmHdtnm+YlZTYl3RMWo6HAKPIIugUCZP9xtAAKCRAWo6HAKPII
uiAiAJ9LumStkxPuZ/VL/BKuHwo/iBzoAQCgy0FClQ2bdJ2SYLCFpNCcect1cQg=
=SgfL
-END PGP SIGNATURE-

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and 

Re: [hugin-ptx] Re: libpano13-2.9.22 release candidate rc2

[Bruno Postle]

Thanks Jeff, these look good to me but I'll defer to Thomas.

Unless anyone has any objections, I'll release rc2 as libpano-2.9.22.

-- 
Bruno

On Wed, 16 Aug 2023 at 18:29, Jeff Welty wrote:

> I didn't see any tags for rc2 in mercurial, so I made this patch which
> gives changes I made against rc2 -- which I think will allow you better see
> the incremental changes I made.
> I am using gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
> ---
> Changes of note:
> - I added more warnings for UNIX in CMakeLists.txt, you may or may not
> want to leave those in, or put them in a more appropriate place in the file.
> - bmp.c -- I made some minor structural changes to handle the case where
> height in the bmp header is negative and not properly handled by the
> unsigned integers.  I didn't test it on a bmp image file.
> - PTcommon.c -- here the call to nextWord at about line 874 was throwing a
> warning, to eliminate the warning I chose to pass a flag to the nextWord
> function itself in parser.c   It seems like overkill to me to eliminate the
> warning, but I didn't want to change the basic nextWord function in other
> ways.  Personally I think I'd keep the original nextWord logic and just
> live with the warning, knowing there is no logical bug.  If that's what you
> would like let me know and I'll restore it.
>
> Other than that it's mostly initializing some variables, handling a few
> signed/unsigned conflicts, and simple reformatting of "if" statements to
> keep the compiler happy and make the code a bit more intuitive as you see
> it displayed.
>
> I like to use #ifdef's to "comment out" large blocks of code that may have
> a use in the future.   You might prefer to just delete those sections of
> code...
>
> Hope this is helpful,
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjJgXPdAFVhiFaACd9Td%3D9fc0eRx5twcigevBYvH10GEg%40mail.gmail.com.

Re: [hugin-ptx] Drone Pano Scripting - Cannot get rid of the Black Hole Sky

[Bruno Postle]

On Tue, 22 Aug 2023, 04:34 PanoSeek wrote:

>
> The closest I found was Bruno talking about the l-29 setting for enblend -
> https://groups.google.com/g/hugin-ptx/c/aghpJeyIvQo/m/k6iOJVImjskJ - I
> did attempt Bruno's solution, but got an error about couldn't do 29, could
> only do 9 and some errors that said 10.  So I tweaked the setting to 9
> (#hugin_enblendOptions -l 9) and ran it.  No errors, but no change to the
> image that I could tell...still have big black hole sky.
>

This technique is basically to create a new fake blue photo, add it to the
set at yaw=90, and hope that enblend will smooth out the transition. You
need as many enblend levels as possible for maximum smoothing (the
parameter should be -l 27, my mistake), the patch photo needs a big enough
angle of view to cover the whole black area, but all skys are different so
you won't be able to use the same shade of blue on all panoramas.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zhj2JUejEvzj3ojfArBxHABFThQeZB0ASQPZ8JU5wtGtw%40mail.gmail.com.

Re: [hugin-ptx] Scripted Hugin Panos from Drone - Fighting the curvature of the earth?

[Bruno Postle]

On Tue, 22 Aug 2023, 03:58 PanoSeek wrote:

>
> After reading the latest thread about multi-row pano's, I have been
> inspired to refine my hugin script I use to build 360 spheres from my DJI
> Mini 2.  I ran into an interesting artifact that I cannot get rid of - A
> jagged line in the horizon.
>

Curvature of the earth shouldn't be a problem, it would just result in a
slightly lower horizon line. More likely this is a more mundane problem:
too much fixity (none of your images should have roll or pitch fixed);
wrong camera angle of view (360° panoramas are very sensitive to this, you
should always optimise angle of view); or bad control points (look for
problems near where there are high control point distances).

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zh6-zD-XpYp0xhrtRytDRyy120OqR3ksZ8ZL6zR4Q3ZzA%40mail.gmail.com.

Re: [hugin-ptx] Re: libpano13-2.9.22 release candidate rc2

[Bruno Postle]

Thanks everyone for testing.

Yes ideally fixes should be a mercurial merge request on sourceforge, but a
diff/patch is nearly as good. A tarball is ok, but the first thing we would
do is extract it to generate a diff - a diff has the advantage that you can
see exactly what you are proposing to change, and not including debug cruft
or unrelated formatting changes.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj8ovrASTxhEVBtdE5fo%3DcYq2%2Bt1gKnGNAXQomvDy%3DV1A%40mail.gmail.com.

[hugin-ptx] libpano13-2.9.22 release candidate rc2

[Bruno Postle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

libpano13 is the PanoTools library for panoramic imaging.

A libpano13-2.9.22 rc2 tarball has been uploaded to sourceforge, this is
a release candidate for testing that may become the final release:

https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.22/

This release should be binary compatible with previous versions - This means
that prebuilt Hugin executables should just work with this libpano13.

There have been some changes since rc1:

Replaced ShowScript and LaunchAndSendScript functions with non-functional
stubs. These functions are not used by libpano13 itself and have security
issues. Provide for now a stub with a message to STDOUT to keep the ABI
constant. They will be removed completely in the next version.

affc6830cdbe71c28d2731dcbf8dea2acda6d9ffd4609c6dbf3ba0c68440a8e3  
libpano13-2.9.22_rc2.tar.gz

This rc2 release is equivalent to HG 923:61865cbe74ba

Here is the full ChangeLog since rc1 for more details:

2023-07-31 17:21 +0200  tmodes(61865cbe74ba [tip] 
)

 * file.c, sys_ansi.c:
 Replaced ShowScript and LauncAndSendScript functions with non-
 functional stub

 These function are not used by libpano itself and have security
 issues. Provide for now a stub with a message to stdout to keep the
 ABI constant.

 They will be removed completety in the next version.
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTmHdtnm+YlZTYl3RMWo6HAKPIIugUCZNXfUwAKCRAWo6HAKPII
ut6iAKCVk4BbiWIZkZW+lV6vAsTbsTBkSQCeOby0sLpyK1MJha8coe665gWfjQ8=
=HIHw
-END PGP SIGNATURE-

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/ZNXfVlbjgK7rGslL%40postle.net.

Re: [hugin-ptx] Re: libpano13-2.9.22 release candidate rc1

[Bruno Postle]

On Mon, 31 Jul 2023, 17:33 T. Modes wrote:

>
> I found a possibility to keep the ABI constant. All public functions keep
> their signature and exist furthermore. But the critical functions have been
> replace with a stub which prints only a message to stdout and does nothing
> else.  So the security issue should be fixed.
> The complete removal of these function will be postponed to the next
> version.
>

Thanks, I'll do another release candidate next week - Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgfmZRo94g8ZN%3D80dxr84hjqUMJ%2BPaFQbOreCPcJth0JA%40mail.gmail.com.

Re: [hugin-ptx] Re: libpano13-2.9.22 release candidate rc1

[Bruno Postle]

The immediate need is to put out a bugfix release. If we bump the soname
then it won't be a drop-in replacement, and Hugin will need to be rebuilt
for all platforms etc..

These bugs are not relevant to Hugin users, but they are still security
issues, so Linux distros will be looking to update their pano13 packages as
soon as we do a release. It would be nice to have this be a minimal change
without bumping the soname.

I'm not confident I can do this change that keeps the ABI intact, so
looking for help here.

-- 
Bruno

On Sun, 30 Jul 2023, 13:13 Andreas Metzler wrote:

> On 2023-07-22 Andreas Metzler wrote:
> [...]
> > I am not in favour of that, you'd still break the functional (but
> > unused, yeah) interface. Also WriteScript/WriteResults changes would
> > need to be reverted to keep the ABI unchanged.
>
> > Imho there is a simple way to do this cleanly and no need to try to be
> > clever about it.
>
> Hello,
>
> Would it be possible to find/list the externally "useful" functions?
> If that were the case we could change the buildsystem to only export
> these in the library ABI and would not have ABI breakage on further
> internal cleanups like this one.
>
> cu Andreas
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhOLe7a8njBViqQ656HCS1CDyWb4p0sNLRHXos5TWDTjw%40mail.gmail.com.

Re: [hugin-ptx] Re: libpano13-2.9.22 release candidate rc1

[Bruno Postle]

On Sat, 22 Jul 2023, 17:38 Robert Clausecker wrote:

>
> Failing that, bump the soname and make this a major or at least a minor
> release so it's clear that this release has an ABI break.  ABI breaks
> in patch-level releases are not a good move.
>

I agree, if we are changing the ABI and soname, this release should be
2.10.0, but it seems like a shame to have maintained the ABI for all these
years and break it for such a minor thing.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgYnwpsLYkoaoTrNRswYbQ%2BAKh9C01VNNDDJizTknR9ag%40mail.gmail.com.

Re: [hugin-ptx] Re: libpano13-2.9.22 release candidate rc1

[Bruno Postle]

Thanks, and I am a little ignorant about these details: since no known
tools actually use these functions, will leaving the soname unchanged be a
problem for tools that use other parts of the library eg. Hugin, nona
etc..? My testing seems to be ok.

We could bump the soname, or we could replace these functions with no-op
stubs to quieten the abi checkers. What do you think?

-- 
Bruno

On Sat, 22 Jul 2023, 13:36 Andreas Metzler, wrote:

> On 2023-07-18 Bruno Postle wrote:
> > libpano13 is the PanoTools library for panoramic imaging.
>
> > A libpano13-2.9.22 rc1 tarball has been uploaded to sourceforge, this is
> > a release candidate for testing that may become the final release:
>
> Hello,
>
> This breaks the ABI:
>
> a)Removed ShowScript and LaunchAndSendScript function
> b)
> -PANO13_IMPEX int   WriteScript ( char* res,
> fullPath* scriptFile, int launch );
> +PANO13_IMPEX int   WriteScript ( char* res,
> fullPath* scriptFile );
>
> -PANO13_IMPEX void  WriteResults( char* script, fullPath
> *sfile, AlignInfo *g, double ds( int i) , int launch);
> +PANO13_IMPEX void  WriteResults( char* script, fullPath
> *sfile, AlignInfo *g, double ds( int i) );
>
>
> I have not found any users on codesearch.debian.net but still a soname
> bump is required. This should do the trick:
> --- libpano13-2.9.22~rc1+dfsg.orig/CMakeLists.txt
> +++ libpano13-2.9.22~rc1+dfsg/CMakeLists.txt
> @@ -286,7 +286,7 @@ if(NOT WIN32)
># Create and install shared library on non-windows
>add_library(pano13 SHARED ${pano13_hdr} ${pano13_src})
>target_link_libraries(pano13 ${_common_libs})
> -  set_target_properties(pano13 PROPERTIES VERSION "3.0.0" SOVERSION "3")
> +  set_target_properties(pano13 PROPERTIES VERSION "4.0.0" SOVERSION "4")
>install(TARGETS pano13 LIBRARY COMPONENT libraries)
>set(_pano_target pano13)
>#create and install static library
> @@ -299,7 +299,7 @@ else()
>  ADD_DEFINITIONS(-DPANO13_DLL)
>  add_library(pano13 SHARED ${pano13_hdr} ${pano13_res} ${pano13_src})
>  target_link_libraries(pano13 ${_common_libs})
> -set_target_properties(pano13 PROPERTIES VERSION "3.0.0" SOVERSION "3")
> +set_target_properties(pano13 PROPERTIES VERSION "4.0.0" SOVERSION "4")
>  IF(MINGW)
>set_target_properties(pano13 PROPERTIES PREFIX "")
>  ENDIF()
>
> cu Andreas
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjU4jCd_fbvQC7qY%3DdgXc8pUm311HQ6iw%2BVNidrx%3D1FXQ%40mail.gmail.com.

[hugin-ptx] libpano13-2.9.22 release candidate rc1

[Bruno Postle]

libpano13 is the PanoTools library for panoramic imaging.

A libpano13-2.9.22 rc1 tarball has been uploaded to sourceforge, this is
a release candidate for testing that may become the final release:

https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.22/

This release should be binary compatible with previous versions - This means
that prebuilt Hugin executables should just work with this libpano13.

There have been some changes since 2.9.21:

* Fix some insecure data handling in command-line tools, this doesn't affect 
Hugin usage

* Clean-up some older deprecated C code, minor build improvements

* Fixes big endian check for Mac OS

* Write TIFFTAG_EXTRASAMPLE tag for files with alpha channel

SHA256SUM: b7a3c43c8bb6ec144b3694e59de7b43872162ee64cb39b9e162100ca2575337e 
libpano13-2.9.22_rc1.tar.gz

This rc1 release is equivalent to HG 922:3005eda747af

Here is the full ChangeLog since 2.9.21 for more details:

2023-06-29 17:38 +0200  tmodes(3005eda747af [tip])

* adjust.c, file.c, filter.h, parser.c, ptpicker.c, ptutils.h,
sys_X11.c, sys_ansi.c, sys_mac.c, sys_win.c, tools/PTAInterpolate.c,
tools/PToptimizer.c:
Removed ShowScript and LaunchAndSendScript function

They are not used by libpano itself. For external callers both
functions are only a thin wrapper around system calls

2023-06-22 21:03 +0200  tmodes(ad7616ee8c26)

* ColourBrightness.c:
Correctly initialize variable

Only needed when we exit with an error in between without running
the whole algorithm

2023-06-22 20:45 +0200  tmodes(271b8ab4bd66)

* ColourBrightness.c:
Use PrintError own formating instead of using a temporary string

2023-06-22 17:54 +0200  tmodes(18ed65577fbc)

* sys_ansi.c:
ShowScript: Check if file exists before opening vi

2023-01-21 16:23 +  Bruno Postle(778a20784e24)

* man/Makefile, version.h:
Bump version to 2.9.22

2023-01-21 16:11 +  Bruno Postle(da06997f4c2f)

* ColourBrightness.c:
Include  if it is available, for the htons
function/macro (Florian Weimer)

2022-08-03 18:56 +0200  tmodes(4074ee48e255)

* panorama.h:
Fixes big endian check for Mac OS Patch by lacard

2022-05-13 17:10 +0200  tmodes(b15a90eb756b)

* tools/PTuncrop.c:
Ptuncrop: Fixes usage screen

2022-05-13 17:09 +0200  tmodes(bc7577ea6020)

* tiff.c:
Write TIFFTAG_EXTRASAMPLE tag for files with alpha channel (patch by
Kevin Mehall)

2022-03-31 17:16 +0200  tmodes(ecac1adc7bb6)

* tests/simpleStitch/simple.pto: deleted file.
* tests/simpleStitch/simple.pto:
Removed unused simple.pto

It is unused and were written by a very early Hugin version

2022-03-13 09:24 +0100  tmodes(4f255f7c9c49)

* pt_stdint.h: deleted file.
* CMakeLists.txt, ColourBrightness.c, PTcommon.h, panorama.h,
panotypes.h, pt_stdint.h:
Get rid of now obosolete wrapper pt_stdint.h

2022-03-13 09:23 +0100  tmodes(4d676676de11)

* rgbe.c, rgbe.h:
Fixes inline for newer compiler versions

2022-03-13 08:48 +0100  tmodes(99edb0ca8a2b)

* queryfeature.c:
Fixes assert

typeof is a gcc extension and not supported by MSVC

2022-03-12 09:01 +0100  tmodes(8c72869bd9f7)

* ColourBrightness.c, file.c, ptstitch.c:
Fix some more deprecated uint16/uint32 types

2022-03-06 13:49 +0100  tmodes(f56143ee0588)

* ColourBrightness.c, tiff.c:
Use uint16/32_t instead of depreacated uint16/32 types

2022-03-06 13:48 +0100  tmodes(c887e1348df6)

* CMakeLists.txt:
Added new lzma.dll name (Windows only)

2021-12-16 22:14 +  Bruno Postle(2d4aeb9ca433)

* ChangeLog.hg:
update ChangeLog.hg

--
Bruno

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/ZLbzI/6BRIqqslNM%40postle.net.


signature.asc
Description: PGP signature

Re: [hugin-ptx] Re: automatically solving vignetting at sunrise and down in a series of panoramas

[Bruno Postle]

The man page isn't very clear, enblend looks at the overlap size and sets
the number of levels to mostly sample from the overlap area. If you set it
to a large number of levels it will sample from much further beyond the
overlap area - which is useful for smoothing out a sky.

-- 
Bruno

On Fri, 7 Jul 2023, 06:52 Maarten Verberne wrote:

> i also had a bit of trouble finding the documentation of this, but it's
> the pyramid levels...or how many triangles should enblend use.
> as i found it appears that enblend by default takes the highest possible
> setting for this.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zh19JBzScu1nk_WvC8mCbNESLd7d_11G3u7L9juhpBJPw%40mail.gmail.com.

Re: [hugin-ptx] Re: automatically solving vignetting at sunrise and down in a series of panoramas

[Bruno Postle]

Enblend will adjust areas that are outside the overlap, -l 27 just tells it
to use the maximum number of levels possible.

Hugin can correct 'normal' radial vignetting, but these shots are not ideal
for calibration. You would need to shoot a simple scene with about 50%
overlap, get Hugin to optimise photometric and vignetting and save these
parameters to apply to your sky shots.

-- 
Bruno

On Thu, 6 Jul 2023, 12:00 Maarten Verberne wrote:

>
> Sorry, but i didn't explain properly.
> the seam on the image is bright and nice, the dark vignetting is the
> part that isn't blended on the original image.
> since enblend already takes highest level of pyramids as default, adding
> -l 27 only gave me that it was too much and that it would lower to 10
>
> to make it work for my purpose it needs to remove the vignetting next to
> the seam or remove the vignetting on the original image before enblend
> has a go at it.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhStLiEPGuoL8ZYEjurzcBEsHm5xj8kpYUWa1GNyS-vxQ%40mail.gmail.com.

Re: [hugin-ptx] Re: automatically solving vignetting at sunrise and down in a series of panoramas

[Bruno Postle]

Yes, something like this (all on one line, Google will mangle this email):

  enblend -o project.tif -l 27 project.tif project0001.tif

-- 
Bruno

On Wed, 5 Jul 2023, 21:51 Maarten Verberne wrote:

> yes, they are taken at the same time, but i have a series of these, so
> the dark part changes over time and gets clouds a few minutes later.
>
> can i test that in command line and if so how should i add this to the
> example?
> enblend -o project.tif project.tif project0001.tif
>
> Op 05-Jul-23 om 22:27 schreef Bruno Postle:
> > Are both photos taken at the same time? I'm trying to figure-out the
> intent.
> >
> > If you just want an even blend across the sky, then you can increase the
> > number of levels in the blend pyramid to the maximum. In the Stitcher
> > tab, set enblend options to -l 27
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zh-dLZLPtXzkAruoPzCTFkVo14_6%2B2LBbwumPV0wB495Q%40mail.gmail.com.

Re: [hugin-ptx] Re: automatically solving vignetting at sunrise and down in a series of panoramas

[Bruno Postle]

Are both photos taken at the same time? I'm trying to figure-out the intent.

If you just want an even blend across the sky, then you can increase the
number of levels in the blend pyramid to the maximum. In the Stitcher tab,
set enblend options to -l 27

-- 
Bruno

On Wed, 5 Jul 2023, 21:05 Maarten Verberne wrote:

> i forgot to add an example :)
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zg-tWykkwEHSzXJ6rYO30Gg04a8tRSVy1vUYAUQwFLb_A%40mail.gmail.com.

Re: [hugin-ptx] Automatic train photography and stitching

[Bruno Postle]

Nice, see also Masakazu Matsumoto's work:

https://github.com/vitroid/TrainScanner

https://www.flickr.com/photos/vitroids/

On Wed, 3 May 2023, 09:05 Paul Womack,  wrote:

> This isn't hugin, but stitching more generally. And yet not generally, but
> monumentally specific.
>
> And very cool.
>
> The camera script automatically takes multiple frames of passing trains,
> and then a script stiches them into a
> low, wide pano!
>
> https://github.com/jo-m/trainbot
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhZHPfBj5B%2Bi2LN6pNC9GX6yT5Tz0P9uip9M20X4apOrg%40mail.gmail.com.

Re: [hugin-ptx] Re: Vuze Camera 3D 360° VR. Parameters for import and stitching photo

[Bruno Postle]

So the camera takes two full panoramas that need to be stitched separately
(though for stereo viewing they will need to be aligned with each other
somehow). ie. all the left hand images (1, 3, 5 & 7) are stitched together,
then all the right hand images (2, 4, 6 & 8) - Bruno

On Fri, 3 Mar 2023, 07:38 Francesco Sorrentino, wrote:

> I confirm. The camera creates stereo images (referred to as "Anaglyph 3D"
> in the software)
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zg0-G8nvF_%3DGzDtPd795i5A505%3D4xqgaZZ_TGt6Wb68Lg%40mail.gmail.com.

Re: [hugin-ptx] Re: Vuze Camera 3D 360° VR. Parameters for import and stitching photo

[Bruno Postle]

Is this a stereo camera? It seems to be taking two sets of images - Bruno

On Fri, 3 Mar 2023, 06:46 Francesco Sorrentino wrote:

> The lenses are positioned to the sides (see attachment). I should try your
> advice: take two shots, one of which is rotated 45 degrees, to give hugin
> some reference points. Thank you for the tip.
>
> Unfortunately this product hasn't been updated for about three years by
> the manufacturer and it's a great disappointment, because the camera is not
> bad but the app has become unstable with the latest versions of Android.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgrRTE7NabzmVHe3NEfNM85ayRh_vpKQdw77UHtXonqmw%40mail.gmail.com.

Re: [hugin-ptx] is "downscale final pano = 70% of max width" overriden by "calculate optimal size"?

[Bruno Postle]

On Sun, 22 Jan 2023, 18:38 T. Modes, wrote:

>
> The calculate optimal size button is using by default no additional
> scaling factor.  (So it ignores this setting. Except you hold the control
> button.)
> The downscale factor of 70 % is on the assistant tab in the preferences.
> This indicates that this setting is only used by the assistant.
>

Thanks, my memory must be failing me ;) I thought this option predates the
assistant.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhyZGop%3DFyPq1ci81F3RcpZmkjKaHkfzHdKenYvYR0QGg%40mail.gmail.com.

Re: [hugin-ptx] is "downscale final pano = 70% of max width" overriden by "calculate optimal size"?

[Bruno Postle]

On Sun, 22 Jan 2023, 14:16 Fotis K wrote:

> thank you Bruno, interesting information! i’m reading that the green
> channel has more resolution - i wonder how this translates in my case: for
> my workflow i’m batch developing the raw files of my camera into 16bit
> tiffs that i then use as input for hugin.


The green channel has 70% resolution, the red and blue have 50% (with the
standard Bayer pattern). Everything else is interpolated by the RAW
software.

But this 70% is just a good default that is appropriate for most users, you
should check with your own pictures, and set it to 100% if you have any
concerns.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiLkzTALHfuu5E%3DQBg2SXN2zE8nd60DUTcSXQVFxP5aHQ%40mail.gmail.com.

Re: [hugin-ptx] is "downscale final pano = 70% of max width" overriden by "calculate optimal size"?

[Bruno Postle]

On Sun, 22 Jan 2023, 10:30 Fotis K, wrote:

> After all these years of using hugin I discovered that I never set the
> option *downscale final pano* from 70% to 100% in the preferenecs.
>
> However I always click *calculate optimal size *right before the final
> stitching.
>

This 'calculate optimal size' function uses the 70% default. The rationale
is that digital cameras produce redundant pixels due to Bayes sampling in
the CCD, so for most users there is no loss (and the files are half the
size).

If you are sourcing images from another source: scanning, or the output
from another Hugin project, it might be worth setting it to 100%

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgvQdB4Js9CY6EsZVZ-ScJPQswpTuhZTn5atLGRxeFc9w%40mail.gmail.com.

Re: [hugin-ptx] Hugin 2022.0.0 released

[Bruno Postle]

On Thu, 22 Dec 2022, 09:11 T. Modes wrote:

> Thanks Bruno
>
>>
>> - Fedora wxwidgets 3.2 still doesn't have Wayland support, so it is
>> necessary to build Hugin with `-DUSE_GDKBACKEND_X11=ON` otherwise
>> Hugin crashes on startup.
>>
> I'm a bit surprised on this. I was under the impression that this issue is
> fixed in wxWidgets 3.2.
> Maybe Fedoras wxWidgets 3.2 is built without EGL support (default is on)
> and has still the issue as older version?
> (wxWidgets 3.2 and GLEW needs to build in the same configuration regarding
> EGL. Mentioned in the release notes and in the INSTALL_cmake file. see also
> bug https://bugs.launchpad.net/hugin/+bug/1989723 )
>

The fedora wx maintainer says: "However, several packages that use
wxWidgets are not yet compatible with wxGLCanvas build with EGL support",
so they reverted it. As a result the Hugin package in f37 was core dumping
for the last month..

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiY6%3D1JCT6EODvAD7LrmA7WXtRWTyJQ5hdCvf1eB3maHA%40mail.gmail.com.

Re: [hugin-ptx] Hugin 2022.0.0 released

[Bruno Postle]

Thanks Thomas.

2022.0.0 will be in the next fedora 38 release. It is also available
in the fedora panorama copr repository for all current fedora
versions, enable this like so: `sudo dnf copr enable bpostle/panorama`

A couple of notes:

- Fedora wxwidgets 3.2 still doesn't have Wayland support, so it is
necessary to build Hugin with `-DUSE_GDKBACKEND_X11=ON` otherwise
Hugin crashes on startup.

- I'm building the python bindings (though who knows if this still
works). python 3.12 has dropped `distutils`, this has been split out
into a separate module called `setuptools`, so you will need to
install this before building Hugin with `-DBUILD_HSI=1`

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiMrS3x2bTVoUL0ZTECLVnbTK9%2BOcqYkyC8LL8kGBy%2BTA%40mail.gmail.com.

Re: [hugin-ptx] Hugin to correct Iphone panorama fisheye distortion

[Bruno Postle]

This looks like a cylindrical panorama, ie. Set the projection of the input
photo to cylindrical and the output panorama to rectilinear - Bruno

On Mon, 21 Nov 2022, 06:10 Tony Denzer, wrote:

> Hello,
> Amateur-level question.
> Can Hugin be used to correct (to make 'orthogonal') a single iphone
> panorama image (such as this
> ) where there is
> great fisheye/barrel distortion?
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiKJLGLCmgny%2BVnWmTH2zioQffoDcb%2BhzNJSu3JPny-4Q%40mail.gmail.com.

Re: [hugin-ptx] Re: Adjusting the yaw, pitch and roll of two equirectangular panorama in one view

[Bruno Postle]

Have you set the projection of both input images and the output panorama to
equirectangular?

On Thu, 17 Nov 2022, 13:34 DerekS, wrote:

> Hi dkloi
>
> Interesting idea, that I been playing with at your suggestion.
>
> I loaded in the two panorama, and added control points, and the selected
> optimise.  Various Yaw, Pitch, and Roll values were applied to both images,
> the yaw -135 which made it difficult to compare to the originals.
>
> So I tried again, anchoring the position of image zero, added the control
> points and selected optimise again.  On the preview image zero is badly
> distorted.  It's hard to tell if image 1 is changed. In the advanced user
> tab, image zero has 0 Yaw, 18.5 pitch, 64.1 roll, far to much, hence the
> distortion, whilst image 1 has 0 yaw, 0 pitch, roll 0.
>
> I'm assuming you had something else in mind when you made the suggestion,
> what might I being doing wrong?
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhSDL0NJLnr5POSfUtL0Wmjn2-rsBrfqB3%2BieD%2BkAd8pA%40mail.gmail.com.

Re: [hugin-ptx] Unable to 'pip install hsi' (Hugin Scripting Interface)

[Bruno Postle]

I didn't know you could install hsi this way, but the error is because you
don't have opencv2 header files on your system. On fedora these would be in
the opencv-devel package.

-- 
Bruno

On Sun, 30 Oct 2022, 10:38 Thomas B., wrote:

> Hello all,
>
> I have some Python scripts for automated panorama creation. Those are
> relying on HSI (Hugin Scripting Interface). But since I installed a new
> machine, I was not able to make passing "pip install hsi": no matter what I
> tried (installing opencv, building it from source, ...) installation always
> fails with :
> src/classifiedhsimage.h:7:10: fatal error: opencv2/core.hpp: No such file
> or directory
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjOcrk1CSBKLVFXJzXOVhZjxKf%3Dn4poeN_btFAz2rsoxQ%40mail.gmail.com.

Re: [hugin-ptx] Calculate Optimal Size Shifting Control Point Distance

[Bruno Postle]

The control point error is reported in terms of pixels in the output
panorama. So if 'calculate optimal size' changed your 3000x1500 panorama
into a 3x15000 panorama then all the control point distances will be
ten times bigger. The output will look the same but with higher resolution.

You have a single row of images, so the canvas size (in pixels) of your
panorama should be about the same height as your input images. Rather than
clicking on 'calculate optimal size' (which isn't working for you), I would
directly enter a canvas size that is a bit more reasonable.

I suspect the problem is that very wide rectilinear panoramas are not ideal
for this automatic calculation.

-- 
Bruno


On Wed, 12 Oct 2022, 23:55 Alexander Drecun, 
wrote:

> So what's curious is that the pano doesn't look like tiles in Hugin. That
> comes only once I've stitched it and opened it in another application like
> Photoshop. The pano at 3000x1500 canvas and at the optimal size canvas look
> identical except that the control points have gone from great to terrible.
> This is what it looks like in the Preview window before and after I
> calculate optimal size. It's bizarre.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhLO6GLFsSjmFrybpm4te2NKTcT-nMwRqOV7mqXotMZKg%40mail.gmail.com.

Re: [hugin-ptx] Re: Stabilising/deshaking webcam timelapse footage

[Bruno Postle]

I just did a test and you don't need to modify nona-deshake to use
TIFF input files.

I created a set of images called: temp0001.tif, temp0002.tif etc...

I created a Hugin project using just one of these images, set the crop
and output projection, saved as template.pto

Ran nona-deshake:

  nona-deshake -o out template.pto temp*.tif

Note that this produces JPEG intermediate files called
out0001.jpg, out0002.jpg, etc.. If you don't want JPEG here
then you *do* need to modify nona-deshake.

ffmpeg needs an input file:

  for FILE in out*.jpg; do echo "file '$FILE'" >> frames.txt; done

This produces a frames.txt file that looks like this:

  file 'out0001.jpg'
  file 'out0002.jpg'
  file 'out0003.jpg'
  [etc..]

Then I joined these JPEGs into a video like so:

  ffmpeg -f concat -i frames.txt output.mp4

-- 
Bruno

On Sat, 8 Oct 2022 at 09:17, Tommy Hughes wrote:
>
> Hi Bruno, I already have tiffs, and I have tried altering every line with jpg 
> and changing it to tiff, but the script doesn't run. Do the tiff filenames 
> need to be in a specific format to work? Is that the webcam%08d?  Mine are 
> name LRT_1.tif, currently

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zjn7iKr9jdd195XGm_OyK2M%2B67LA9odhQCPaQtD_N_8zA%40mail.gmail.com.

Re: [hugin-ptx] Re: Stabilising/deshaking webcam timelapse footage

[Bruno Postle]

ffmpeg can split a video into TIFF frames, just change the output
format to webcam%08d.tif or similar.

If you want nona-deshake to render to TIFF instead of JPEG, then you
should change "$prefix%08d.jpg" on line 51 to "$prefix%08d.tif" and
'JPEG' on line 88 to 'TIFF'.

-- 
Bruno

On Thu, 6 Oct 2022 at 11:33, Tommy Hughes wrote:
>
> Is it possible to convert this to using tif rather than jpg? I did try 
> modifying it myself, but, so far, it doesn't run.
> Thanks.
> On Monday, July 5, 2021 at 5:08:00 PM UTC+1 bruno...@gmail.com wrote:
>>
>> This should be possible with some extra steps.
>>
>> The nona-deshake.pl script uses align_image_stack to align the photos.
>> This is more robust with sequences taken during different lighting
>> conditions, but I don't expect it to work with 360 degree images. So
>> you would need to extract a rectilinear image for each frame, align
>> these rectilinear frames, but modify the script to assemble the
>> aligned sequence from the original 360 degree images.
>>
>> Just offsetting 360 degree images sideways is equivalent to a yaw
>> transform, this would be ok as long as there is no roll and pitch
>> variation. If so you only need to modify the script to print the yaw
>> angle for each source photo, and calculate the pixel offset from that.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZieKbFGtS7Nc7RktK_%2B-qxTD-wQOUN19OEBccXr2S5qkA%40mail.gmail.com.

Re: [hugin-ptx] enblend: encountered degenerate image/mask geometry; too high risk of defective seam line

[Bruno Postle]

You could try the internal Hugin blender. This doesn't have as many
features as enblend, but it should be more stable with this sort of thing.

Also, rearranging the order of photos in the Hugin Photos tab may help.
enblend processes images in this order, so the seams will take a different
shape.

-- 
Bruno

On Wed, 14 Sep 2022, 09:08 黄禄轩, wrote:

> related files:
> https://drive.google.com/drive/folders/1gINX1jCQL8wbljy0BeOn7IE1UhbXKhWl?usp=sharing
> tried may switch like --no-optimize but still failed.
> logs: 202209141455.txt
> what should I do
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zhzh2xJrRqm53rQMZZmOLn26U3QmPWySC7LiDcdbN1QBw%40mail.gmail.com.

Re: [hugin-ptx] Shooting Panoramas in Tight Spaces

[Bruno Postle]

Some notes I wrote on this eleven!! years ago:
https://www.flickr.com/photos/brunopostle/5830006193/

Shooting from the same distance is useful, as is shooting perpendicular to
the surface/wall. Though shooting from an oblique angle where necessary is
ok, probably this would be better if this is consistent, i.e. turn to the
left at the left end of a row, straight forward towards the middle and turn
to the right towards the right end.

Most important is to catch openings in one shot, or if the
opening/road/alley is too wide then the multiple shots need to be from a
single location (like a 'normal' panorama). The same for any features that
are out of plane such as roofscapes above or trees in the foreground.

Control points need to be entirely in the same physical plane, you will
need to manually delete any that are not. This whole technique only works
where the buildings closely follow the road edge.

You need to assign the centre photo as the 'anchor', Hugin doesn't
automatically do this for the mosaic XYZ parameters, so you will need to
use the Optimiser tab and select parameters to optimise rather than using
the Assistant tab.

Use Rectilinear format for the output.

Optimise XYZ for all photos except the anchor, optimise rpy for all photos.
Though unless you have vertical/horizontal control points you will need to
fix roll for the anchor.

Optimisation of XYZ mosaic parameters is not as stable as a 'normal'
panorama, if you have problems, work your way out from the middle anchor
photo, adding photos one at a time to the optimisation and adding/deleting
control points as necessary.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj2Smy73Y5Xn0CcdhpJbNA44DM58O8uroP8RUp2iEs5zQ%40mail.gmail.com.

Re: [hugin-ptx] developed view of a cylindrical surface (timber carver)

[Bruno Postle]

This isn't a typical use for Hugin. But you might be able to produce a
result by cropping out a narrow vertical strip from each photo and
stitching these together.

You can crop the photos by processing them in an image editor, or by adding
masks in Hugin.

I wouldn't expect the automatic control point generation to work very well.
You will probably have to add manual control points.

To keep all the strips the same size in the Hugin output I would set the
output panorama format to 'cylindrical', and optimise only yaw and angle of
view for your input photos.

If you do this you may only need one control point between each photo (not
forgetting to connect the first and last photo).

-- 
Bruno

On Tue, 6 Sep 2022, 14:12 OERTLI Werkzeuge AG, wrote:

> Dear all
>
> we are trying to stitch the 95 photos (each 3-4°) taken around a
> cylintrical tool for timbercarving. The surface has a DNA-helixlike optic.
> All the single pics look ok and klicking one each other you will see a
> nice stop-motion animation.
> But we cannot find the right settings to stitch the photos.
>
> Here is a wetransfer with the pics.
>
>
> https://wetransfer.com/downloads/305e756055d3b34c35e8476a52b40b1720220906075159/46e69647959b7c9359a1b5c473e1424320220906075213/9f4b5a
>
> Any help + clues are very welcome.
>
> Best,
> Markus
>
>
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgoP%3D11F7LixQGXaZMbW03mY5eenzizxChNS0Bt3vkQmw%40mail.gmail.com.

Re: [hugin-ptx] Re: In Pano13 the tilt parameters TiX, TiY, TiZ and TiS?

[Bruno Postle]

On Wed, 10 Aug 2022, 23:58 johnfi...@gmail.com, 
wrote:

>
>
> On Wednesday, August 10, 2022 at 5:15:33 PM UTC-4 bruno...@gmail.com
> wrote:
>
>> On Wed, 10 Aug 2022, 22:07 johnfi...@gmail.com, <> wrote:
>>
>> These other parameters allow different planes. The basic use is for
>> stitching a spherical panorama where the ground surface is a horizontal
>> plane, but there is parallax movement that needs to be corrected using the
>> usual mosaic functionality.
>>
>
> An example would really help, especially a runable example.  I can't
> relate what I see in the source code to what you are saying.
>
> I also can't distinguish what you are saying from the Tpy and Tpp
> parameters (though it does seem like a third component should be needed to
> use them that way).
>

Ah my mistake, I was describing the Tpy and Tpp parameters.

I think these other parameters are from an earlier attempt at the mosaic
functionality. I vaguely remember that there was a system with four
parameters, that was replaced by a three parameter system. If this is what
it is then it is junk code.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zg8dHDT2cFQD7QwC5fHrZrCi7KVGMZkPrtFPRUeeawTGg%40mail.gmail.com.

Re: [hugin-ptx] Re: In Pano13 the tilt parameters TiX, TiY, TiZ and TiS?

[Bruno Postle]

On Wed, 10 Aug 2022, 22:07 johnfi...@gmail.com, <> wrote:

>
> I still hope this question gets a reply from someone who does know what
> those parameters are intended for and what other tools might be using them.
>

'Mosaic' XYZ control points are mapped onto a vertical plane that is
directly in front of the 'camera'.

These other parameters allow different planes. The basic use is for
stitching a spherical panorama where the ground surface is a horizontal
plane, but there is parallax movement that needs to be corrected using the
usual mosaic functionality.

In principle you can have multiple planes in a single scene.

I have in the past wondered if (with a modified GUI) this functionality
could be used to build a hybrid photogrammetry application, where you match
control points, but also indicate which points are coplanar - this would be
very useful for architectural surveying where you are only really
interested in placing planes and the intersections between them.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjwOHZp%2BFGU2VGEg-NTpXtiCBz7D2E6HPFK6j6JTxt4bg%40mail.gmail.com.

Re: [hugin-ptx] Trapezoidal distorsion when stitching scanned images

[Bruno Postle]

Hi Pierre, I would first check that both the pitch and yaw of all your
input photos is set to zero and that the output projection is set to
rectilinear (not equirectangular).

Some scanners can produce quite strong 'shear' distortion, like a
parallelogram, if the head is not exactly perpendicular to the tracks.
Panotools/Hugin has g & t lens optimisation parameters that will correct
this. You only need one or the other depending if your shear is horizontal
or vertical.

I *think* g & t optimisation is hidden under a Hugin 'expert user' setting,
I'm not at a computer at the moment so can't verify.

-- 
Bruno

On Fri, 5 Aug 2022, 19:42 Pierre Pierre, wrote:

> Hi all,
>
> First, some background, I'm currently trying to digitize all my father's
> paintings and drawings; For artworks somewhat larger than my scanner I
> needed stitching, and have been using hugin for that purpose for a few
> months now.
> Using a script heavily inspired by the one referenced in the "stiching
> scanned image" tutorial, or the script from Matthew Petroff (
> https://github.com/mpetroff/stitch-scanned-images) usually gives good
> results.
> The main issue I'm often facing is that the output image has some kind of
> trapezoidal distortion, from mild to pronounced: usually the left end is
> taller than the right end.
> I don't know why this happens, images overlap correctly and I can stitch
> the same images manually without too much effort (it's just a lot slower).
> My current hypothesis is that output uses a rectilinear projection, but
> I'd need a projection that's both rectilinear and conformal. I there a way
> to request such optimization, or to postprocess control points mapping to
> convert it to a conformal mapping?
> Thank you for your attention,
>
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zhn2iQNZ3wx-A0evZLpkqOirEwuB%3D_QTX%3DanVrYxnKDWQ%40mail.gmail.com.

Re: [hugin-ptx] Hugin Assistant tab changes

[Bruno Postle]

On Sat, 30 Jul 2022, 01:46 David W. Jones, wrote:
>
> Hey, Thomas and Bruno!
>
> On 7/29/22 09:17, Bruno Postle wrote:
>
> > The first lets you declare the lens type of your photos (if it can't be
> > detected):
>
> Hmm. It seems complicated for the Assistant, which I think of as the
> "beginners" tool. Would a beginner even know what the different lens
> types mean?

The previous Assistant tab had a drop down for lens type, plus focal
length and crop factor, all in the space next to the first button.
This was exposing deep photo techno stuff to first-time users that in
reality would be auto-detected (if the focal length can't be detected
in the EXIF metadata, you still get a pop-up asking for it as before).

With the split button, the lens type options appear only if you click
on the pull down arrow - and the first item is labelled as default, so
I *hope* anyone exploring these will be gently made aware only that
there are other possibilities.

> > The second lets you run different alignment strategies.
>
> I like the wording of the options on the dropdown. They make functional
> sense - user knows they have scanned images or have a dual-lens camera.
> Although why are there two "Scanned images" entries - one plain, one
> with TrXYZ? Would a beginner know what the difference is?

The problem is that: although using the XYZ mosaic parameters to
stitch scans is conceptually the right way to do it (because sometimes
your 'scans' are from a mounted camera or microscope and need lens
correction); the simple way of doing it that abuses the lens d
parameters is more stable and works perfectly for flat-bed scanners.

You can read the labels as 'scanned images' and 'scanned images using
cryptic other stuff', which is about right.

What I like about this new framework is you can try it, undo, try
something else etc... Before, these assistant scripts were difficult
to find.

> > The third split menu gives various ways of stitching the final panorama.
>
> This dropdown list definitely drops out of the beginner category!
>
> What does the "Zero-noise output" do?

It is a photo technique where you shoot bracketed exposures and
reconstruct a normal (non HDR) image that uses the lowest noise data
for the dark areas of the image. It gives spookily high quality
results, especially if you are printing. You need a tripod and a
static scene, so it isn't an everyday technique:
http://www.guillermoluijk.com/article/nonoise/index_en.htm

> Does hovering over a number/button have a tooltip that explains things?

The buttons have the same tooltips as before ("Load a series of
images"), there are no tooltips for the individual menu entries.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zhm5OuKoPExBSFVHcybj4Udadn6X5ZVnXjuR366k4Jwow%40mail.gmail.com.

Re: [hugin-ptx] batch panorama with same params

[Bruno Postle]

Hi Maarten, you can use an existing Hugin PTO project as a template to
stitch further panoramas that have the same arrangement of photos.

On the command-line or in a script you can specify replacement input images:

nona -o temp_ project.pto left/IMG_0001.jpg right/IMG_0001.jpg

..this will create two temporary remapped images, called temp_.tif
and temp_0001.tif, use enblend to blend them into a single image:

enblend -o panorama_0001.jpg temp_.tif temp_0001.tif

-- 
Bruno

On Sun, 3 Jul 2022 at 15:17, Maarten Verberne wrote:
>
> I create interval images and made a project with 2 cams on a fixed position.
>
> as a result i have 2 series of images, one in a folder [left] the other in a 
> folder [right]
> images in both folders are named: IMG_0001.jpg, IMG_0002.jpg etc.
> overlap is only 150px.
>
> as a result i created a few control points by hand and after alingning and 
> adjusting the cutout i have one panorama image.
>
> since lighting, leaves and other things change not all control points will be 
> available on all images.
>
> Is there a way  can batch process all images in those 2 folders with the same 
> set of corrections that hugin used for the first one i corrected by hand?
> if not, is it possible to use the same control point for all other images in 
> the folders?
> or am i thinking all wrong about this?

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj5g6n%3DtWEQvtCrwfY220sLJLTJt52j3O6ShnHLE5x4jw%40mail.gmail.com.

Re: [hugin-ptx] Screenshots: "No or only partial information about field of view"

[Bruno Postle]

Hi Ray, this is an old tutorial, but the technique is the same, basically
you can use whatever field of view you like within reason:
https://hugin.sourceforge.io/tutorials/scans/

Also, there are easier ways to do this, in Firefox I can right-click a web
page and save the entire thing as an image without scrollbars.

-- 
Bruno

On Wed, 25 May 2022, 14:17 raywood,  wrote:

> I am new to Hugin. I run its Panorama editor. In its Simple interface, I
> click Load Images. I add a set of JPGs. These are overlapping screenshots
> of a webpage as I scrolled. Scrollbars and other panorama-unfriendly
> elements have been cropped.
>
> When I add the JPGs, I get a dialog that says this:
>
> > No or only partial information about field of view was found in image
> file [filename]
> > Please enter the horizontal field of view (HFOV) or the focal length and
> crop factor.
>
> I'm not sure what those values would be.
>
> What's the best way to use Hugin with screenshots?
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zjqo4Ffait1sNQSpJoBeG1k8MgW55_StNSdpFXPpm53Wg%40mail.gmail.com.

Re: [hugin-ptx] Precise meaning of control point coordinates?

[Bruno Postle]

On Sun, 15 May 2022, 11:34  wrote:

>
> Imagine each pixel as a square in a very magnified image.  I would expect
> best behavior if that pixel's integer coordinates represented the center of
> that pixel.  But maybe some code would be simpler if the pixel's exact
> coordinates represented the top left corner of that pixel (its coordinates
> plus 0.5,0.5 would be its center).
>

I remember much discussion about this on the old panotools list, the
consensus was that Helmut Dersch got this correct in the libpano library
(and Hugin uses the same conventions).

The way to test is to construct some artificial images with hard edge
patterns and try optimising, stitching, reverse functions etc..

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjUXrtkVdmjExOrfSJ30nF11Ue8%2BWSVTscOsifrV%3DZThw%40mail.gmail.com.

Re: [hugin-ptx] Using align_image_stack for focus stacking

[Bruno Postle]

align_image_stack works by identifying useful features (corners) in one
photo, and then trying to find a similar collection of pixels in the next
photo. It may be that it just isn't very good at catching focus variation.
Also, and I haven't checked this, it may be matching all subsequent images
with the first image - have you tried testing just pairs of consecutive
images to see if you get better results?

cpfind uses a feature classifier approach, it might give get better results
than align_image_stack. Though I haven't checked this either.

-- 
Bruno

On Sat, 30 Apr 2022, 00:21 dgjohnston,  wrote:

> Hi, this is a link to the test subdirectory I’m using to get
> align_image_stack to process a few files for focus stacking. Don’t mind the
> laundry, these were just some quick test shots I made.
> https://ln5.sync.com/dl/1535e65f0/fxrj8uqv-yuw77g77-wf4gv4sy-m4sa6k47
>
> If you look at the jpg images you’ll see that the files are well aligned
> from the start (I had a tripod with a remote trigger); but I’m testing the
> batch file I created (AlignFocusStack.command). After running this command
> the first tif image is not aligned to the other four images at all and you
> can see the ghosting in the output1.tif file that this creates.
>
> In the DGJVine.pto file you’ll see that there are 9 control points between
> image 4 and image 0 but they are all in the lower left.
>
> These are somewhat blurry images in some areas but that is the intent of
> focus stacking.
>
> I did try adding the -x, -y, -z options to align_image_stack and tried
> setting —core down as low as 0.5 and as high as 0.95 with any success.
> I was able to use the Hugin GUI to add control points between image 4 and
> image 0, and between image 0 and image 1 in the blurry areas.
>
> Any suggestions on how I might improve on the ability of align_image_stack
> in this situation?
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhEwjwr%2B1Wq_9PnUj%3DmTvd21ae_4hLqycPcUiXZ3kEVPA%40mail.gmail.com.

Re: [hugin-ptx] Determining lens distortion parameters from multiple panoramas

[Bruno Postle]

On Thu, 28 Apr 2022 at 15:57, Jeff Welty wrote:
> On Thursday, April 28, 2022 at 2:33:53 AM UTC-7 Bruno Postle wrote:
>>
>> Lensfun and panorama tools have a slightly different lens model, so it
>> isn't always possible to transfer parameters (I'm not sure if there is
>> a converter, it wouldn't be difficult to write one if it doesn't
>> exist).
>>
> I thought the "ptlens" distortion model in lensfun was identical to hugin's 
> model.  The lensfun tutorials show the a,b,c parameters from hugin's 
> optimization being directly used in lensfun data.  The equations documented 
> sure looks the same, but you have far, far more experience at it so I will 
> look harder at it.  FWIW here's the web page I referenced documenting the 
> lensfun "ptlens" model:

I may be wrong, it has been a while. The panotools/Hugin lens model
does have a couple of flaws: the a & c parameters have an odd number
power, whereas usually only even number powers are used for lens
models (which is why we generally recommend starting with just the b
parameter); the angle of view parameter is locked to the width of the
image, but the lens correction parameters are scaled to the narrowest
dimension of the image (which is the height for landscape shots and
the width for portrait shots), the result is that you can't reuse the
same parameters for landscape/portrait images. These have never been
fixed because it would break existing PTO projects and they don't
cause any problems in practice.

>> The idea of optimising a merged project to get more accurate lens
>> parameters should work. There is a tool called ptomerge in the
>> Panorama::Script perl module for merging projects, I'm not sure if it
>> merges lenses, but if it doesn't you can reassign the lens in Hugin.
>>
> Oooh, thanks for that.  I'm perl fluent so that's a nice place to start.
> After a little more research, I read where image stabilization could be a 
> cause for the "d,e" parameters to legitimately be different for each image.   
> So I may need to link only the a,b,c parameters and allow d to be optimized 
> for each indvidual image.

To the optimiser, the d & e parameters resemble the TrX and TrY
parameters at the small scale, so sometimes you can get strange
results mixing them.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhNGXN29Owov%2B9TSV-sPDn%2BMH3B1k2cYE1X%2BFGQPtGoug%40mail.gmail.com.

Re: [hugin-ptx] Determining lens distortion parameters from multiple panoramas

[Bruno Postle]

Lensfun and panorama tools have a slightly different lens model, so it
isn't always possible to transfer parameters (I'm not sure if there is
a converter, it wouldn't be difficult to write one if it doesn't
exist).

The idea of optimising a merged project to get more accurate lens
parameters should work. There is a tool called ptomerge in the
Panorama::Script perl module for merging projects, I'm not sure if it
merges lenses, but if it doesn't you can reassign the lens in Hugin.

I like the idea of a 'handheld' mode for limiting translation
parameters, though since these parameters are unitless I'm not sure
how to pick the thresholds reliably.

-- 
Bruno

On Thu, 28 Apr 2022 at 02:34, Jeff Welty wrote:
>
> I have a new camera (Canon G1X mark iii).
>
> The default lens distortion at the widest angle (15mm) in lensfun definitely 
> does not match my particular copy of this camera, so I can't export output 
> Darktable with lens correction.
>
> I have a dozen or so mini-panoramas with 2 to 5 images each, of which I can 
> get very good distortion fits with hugin.  Same projection is used for all 
> panoramas.
>
> One approach is take the average value of each coefficient from each of the 
> separate panoramas, and update the lensfun data with the average value.  I 
> did a quick check and this appears mathematically consistent.
>
> Another approach, which I haven't seen in the FAQ, would be to combine the 
> panoramas algorithmically -- changing the control point numbers and image 
> numbers so they all remain unique.   The panorama view would make no sense, 
> but I don't think hugin would encounter any problems with that.
>
> If I did this, I believe hugin could perform a custom optimization and output 
> a good estimate for distortion coefs based on all the panorama data I have 
> for a given focal length.   Do you think this will work?
>
> On a side note -- I have yet to use a tripod, I am pretty good at rotating 
> the camera around the exit pupil.  But a little translation can make a big 
> difference.  I hacked in the constrained Levenberg Marquardt method so the 
> optimization doesn't get lost looking for large translation parameters.  This 
> seems to be working very well.  Hard coded to not let Tx,Ty or Tz change more 
> than +/- .05 from the starting value found when the optimization begins.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiycjnOC%2Bx1C6kC-peBCrMDUvuQpQG1fYcefMrJUsOAVw%40mail.gmail.com.

Re: [hugin-ptx] Re: Default Settings

[Bruno Postle]

Hi Michael, it has been quite a while since I have done anything this
complex in pto_var ot pano_modify, so I hope somebody else can answer
your detailed questions.

A couple of things I noticed:

You are running cpclean immediately after running cpfind, but cpclean
filters control points based on how well they optimise, so you should
run it after optimisation, or at least after you have set all your
optimisation parameters. Then usually you would run optimisation again
after running cpclean.

Although fixing barrel distortion in an external tool should be fine,
you might want to let Hugin optimise vignetting if you are also
optimising exposure, Hugin uses the exposure distribution caused by
the vignetting to calculate the camera response curve.

I don't think Hugin settings like mosaic drag mode are stored in the
PTO file, in which case it wouldn't be possible to set this on the
command-line.

-- 
Bruno

On Wed, 27 Apr 2022 at 19:30, 'Michael Perry' wrote:

> I am converting my workflow to the command line. I have a problem with 
> pto_var and a question about pano_modify, I wonder if you can advise me.
>
> BACKGROUND
>
> I am stitching a mosaic of images of a painting. The photographs have been 
> shot with a camera mounted on a gimbal that is itself suspended on an X-Y 
> frame. The biggest difference between one image and the next is its X-Y 
> position. In theory they should all have the same pitch and yaw as the camera 
> moves little on its gimbal. There is some slight Z to account for as the 
> frame is not perfectly parallel to the painting. The images have to be 
> rotated some 90 degrees.
>
> The images have been pre-processed for lens distortion and vignetting with 
> Capture One, so I am ignoring lens parameters.
>
> COMMAND LINE
>
> I have been using the following commands to build the .pto file. I have 
> annotated them in case it is useful for other people
>
> pto_gen -p 0 -f 40.7 -o project.pto *.tif
>
> (create the project with all files in folder, rectilinear projection and a 
> 50mm lens (FOV = 40.7)
>
> cpfind --multirow --fullscale -o project_cp.pto project.pto
>
> (find control points in a mosaic, full-scale probably not necessary for me)
>
> cpclean -o project_clean.pto project_cp.pto
>
> (clean control points)
>
> pto_var --set=r=90 --opt=TrX,TrY -o project_XY.pto project_clean.pto
>
> (set X-Y variables of all images EXCEPT anchor, for optimisation)
>
> autooptimiser -n -o project_XY.pto project_XY.pto
>
> (optimise images for X and Y)
>
> pto_var --opt=y,p,TrZ -o project_ypZ.pto project_XY.pto
>
> (set pitch, yaw and Z of all images EXCEPT anchor)
>
> This is where I have the problem, I need to select the yaw and pitch of the 
> anchor image for optimisation with all the rest. I can not see how to do that 
> easily.
>
> POSSIBLE SOLUTION
>
> pto_var --opt=y0,p0,y1,p1,TrZ -o project_ypXYZ.pto project_ypZ.pto
>
> (set pitch, yaw and Z of all images INCLUDING anchor)
>
> It is possible to select the anchor if each image is individually selected. 
> HOWEVER when large mosaics are stitched it makes for clumsy code.
>
> EXTRA QUESTION
>
> pano_modify --projection=0 --fov=AUTO -o finished.pto project_ypXYZ.pto
>
> (Set projection to Rectilinear, fit image to screen)
>
> I finalise the image in Fast Panorama preview having set Projection to 
> Rectilinear and fitted the image to the screen. It would be helpful if I 
> could also set the Drag Mode to Mosaic in the Move/Drag tab and the Overview 
> Mode to Mosaic Plane. Is there some code that might effect this?
>
> Hoping you will find these interesting problems.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj%2BCP-%2BGa7yTxFwk_eCMGZZ34CsDOH7Uf9PHgfmf5FzrA%40mail.gmail.com.

Re: [hugin-ptx] Re: Default Settings

[Bruno Postle]

Generating templates like this is a good approach, and it works well in the
GUI and on the command-line.

Though I wasn't referring to the python API, the 'Executor' system is used
by Hugin when aligning and stitching using the Assistant. It is
configurable by editing these INI files.

-- 
Bruno

On Fri, 15 Apr 2022, 13:54 'Michael Perry' via hugin and other free
panoramic software, wrote:

> Bruno, thank you - However, I suspect that the Python Plugin Interface
> (which I believe is what I would need to do that) does not work with the
> OSX version of Hugin. I can not find it in my Preferences menus nor an
> angle of view threshold. I think instead that I will create a library of
> .pto files (1 x 2 frames , 2 x 2 frames, 2 x 3 frames, 3 x 3 frames and so
> on) where I would just need to substitute the filenames of my
> images, preset an XY optimisation, and then find control points, and then
> optimise pitch, yaw and Z.
>
>
> On Thursday, 14 April 2022 at 14:39:21 UTC+1 bruno...@gmail.com wrote:
>
>> I'm not at a computer, so I can't point directly to functionality, but I
>> seem to remember that the default Hugin Assistant has an angle of view
>> threshold, below which it chooses rectilinear, and above which it chooses
>> equirectangular.
>>
>> Regarding custom workflows that don't use these default Assistant
>> settings (again, I can't point to this off the top of my head), there are a
>> series of Hugin 'executor' configurations that you can use instead. These
>> are in an easy-to-edit INI format, so you are encouraged to modify, create
>> and share. I haven't played with them since they were first introduced, it
>> would be really useful if you could try this method and describe your
>> success or failure here, as they are an underused resource that more people
>> would use if they were aware.
>>
>> On Thu, 14 Apr 2022, 11:58 'Michael Perry' via hugin and other free
>> panoramic software, wrote:
>>
>>> Is there a way to get the Hugin 2019.2.0 to use Rectilinear Projection
>>> as its default projection rather than Equirectangular?
>>>
>>> On Thursday, 25 February 2021 at 13:00:58 UTC Michael Perry wrote:
>>>
 I wonder if there is anyone in the forum who has a view about this?

 On Saturday, 22 August 2020 at 15:31:54 UTC+1 Michael Perry wrote:

> Can anyone advise me how to change the default settings for y, p, r,
> X, Y, projection (to and move/drag (to mosaic)
> Also, is there some way that I can restrict the clustering of control
> points - reducing the number of points created in similar locations - I'd
> rather have 5 well-spaced control points per overlap than 25 control 
> points
>
> thank you
>
> On Sunday, 18 November 2018 at 09:46:51 UTC Michael Perry wrote:
>
>> I use Hugin to stitch mosaics. I find the best procedure is to
>> optimise for X and Y before y, p and r. I have to select Custom 
>> parameters
>> to be able to do this, then after de-selecting yaw, pitch and roll in the
>> Optimiser tab, I select the X and Y variables columns in their place.
>>
>> Is there a way to change the default settings for Hugin so that, on
>> opening the application:
>> a) Custom parameters is always selected in Photos tab and X and Y
>> columns are selected in the Custom tab?
>> b) Similarly, is there a way to change the default projection from
>> Equirectangular to Rectilinear?
>>
>> Thank you for your thoughts
>>
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgLyarHaNkWwhyA_%2BDMf1K4hv7hb9Q5iFn1UQ0fV7J4ew%40mail.gmail.com.

Re: [hugin-ptx] Re: Default Settings

[Bruno Postle]

I'm not at a computer, so I can't point directly to functionality, but I
seem to remember that the default Hugin Assistant has an angle of view
threshold, below which it chooses rectilinear, and above which it chooses
equirectangular.

Regarding custom workflows that don't use these default Assistant settings
(again, I can't point to this off the top of my head), there are a series
of Hugin 'executor' configurations that you can use instead. These are in
an easy-to-edit INI format, so you are encouraged to modify, create and
share. I haven't played with them since they were first introduced, it
would be really useful if you could try this method and describe your
success or failure here, as they are an underused resource that more people
would use if they were aware.

--
Bruno

On Thu, 14 Apr 2022, 11:58 'Michael Perry' via hugin and other free
panoramic software, wrote:

> Is there a way to get the Hugin 2019.2.0 to use Rectilinear Projection as
> its default projection rather than Equirectangular?
>
> On Thursday, 25 February 2021 at 13:00:58 UTC Michael Perry wrote:
>
>> I wonder if there is anyone in the forum who has a view about this?
>>
>> On Saturday, 22 August 2020 at 15:31:54 UTC+1 Michael Perry wrote:
>>
>>> Can anyone advise me how to change the default settings for y, p, r, X,
>>> Y, projection (to and move/drag (to mosaic)
>>> Also, is there some way that I can restrict the clustering of control
>>> points - reducing the number of points created in similar locations - I'd
>>> rather have 5 well-spaced control points per overlap than 25 control points
>>>
>>> thank you
>>>
>>> On Sunday, 18 November 2018 at 09:46:51 UTC Michael Perry wrote:
>>>
 I use Hugin to stitch mosaics. I find the best procedure is to optimise
 for X and Y before y, p and r. I have to select Custom parameters to be
 able to do this, then after de-selecting yaw, pitch and roll in the
 Optimiser tab, I select the X and Y variables columns in their place.

 Is there a way to change the default settings for Hugin so that, on
 opening the application:
 a) Custom parameters is always selected in Photos tab and X and Y
 columns are selected in the Custom tab?
 b) Similarly, is there a way to change the default projection from
 Equirectangular to Rectilinear?

 Thank you for your thoughts

>>>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zhx8gJSBgOjs%3DS5f87v%3Diwo%2BTUsRf%3DbfKVWy_jPoJdX_Q%40mail.gmail.com.

Re: [hugin-ptx] How to delete masks using command line ?

[Bruno Postle]

Masks in a Hugin PTO project are stored in lines of text that begin with
the letter 'k'. So, make a copy of the file without any lines beginning
with 'k' like this:


  grep -v '^k' project.pto > new_project.pto

-- 
Bruno

On Thu, 14 Apr 2022, 07:13 Noveguy, wrote:

> Hi all,
>
> I need to mask some regions to prevent cpfind from getting CPs in that
> regions but I still want those masked regions to appear in the final
> panorama.
>
> I suspect that I might need to "enable" those masked regions before
> running cpfind then "disable"/delete them after cpfind. This action is
> easily done with GUI but I have no idea how to do that with command line. I
> already looked at Hugin's Help and found "pto_mask " but that does not
> support deleting masks in pto project.
>
> Did I overlook something ? Please help.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjmtUKfN1-%3D7OS9vKjBorn3CTjgx6CemPtqL%2B3QFSRKRw%40mail.gmail.com.

Re: [hugin-ptx] Create control points button in Photos tab

[Bruno Postle]

On Mon, 7 Mar 2022, 12:59 johnfine wrote:

>
> *1)* If you have only one image selected and the Settings is Vertical
> lines, then you get the expected behavior (lines within just that
> image).  But if the Settings is not Vertical lines, you get the
> surprising behavior that your selection of one image is ignored and you get
> more CPs connecting everything to everything.
>

I can't check right now, and I've only ever used this button to create
control points for all images, but I seem to remember that you can select
more than one photo and it will generate points just for that set.

Also it is worth checking to see if the equivalent button in the fast
preview does something more like what you are expecting.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zi6V0xEJt0eC1YM8sYq4fjnOoH7URY6vH-jy%2B34DrxyBg%40mail.gmail.com.

Re: [hugin-ptx] where make install puts things

[Bruno Postle]

On Thu, 3 Mar 2022, 17:36 johnfine wrote:

>
> Are there options I should have used with CMake to get things to go to the
> right place?  Or is the place they went "right" and I should have done
> something different with the other CMake to find things in that place.
>
> When I did a *make install* on the fork of libpano13, it put files in
> /usr/local/lib64
> But the Fedora package for libpano13-devel puts those files in /usr/lib64
> The build for the fork of hugin finds the files where libpano13-devel put
> them.
>

It is normal for software that you have compiled yourself to be installed
into /usr/local. This way you don't overwrite files installed by the
distribution package manager in /usr - i.e. installing into /usr can make a
big mess that isn't easy to clear up.

The libpano13-devel rpm package only exists for you to compile and link to
the libpano13 rpm package in /usr. Just uninstall it and your Hugin build
will pick up your forked libpano13 headers in /usr/local/include

You may also need to set LD_LIBRARY_PATH for your forked Hugin to use this
library at runtime.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjMk7ss5zj-35piP%2BOwyq-OKVWnt_BvzwxGgD0XE-c3MQ%40mail.gmail.com.

Re: [hugin-ptx] Re: Vertical Hugin Panorama of Building has Discontinuity on sides

[Bruno Postle]

On Mon, 21 Feb 2022 at 11:46, johnfi...@gmail.com 
wrote:

> On Monday, February 21, 2022 at 5:52:13 AM UTC-5 bruno...@gmail.com wrote:
>
>>
>> The XYZ Translation parameters are initially hidden as they are not
>> needed for normal usage, they are made available by selecting Menu ->
>> Interface -> Expert.
>>
>> That is one of the reasons I think only the "Expert" interface is usable.
>
> I understand the concept that the alignment doesn't need to be great:  The
> blending tools can cover up for poor alignment.  But I've never seen that
> work for any of my panoramas.  I have sometimes used detailed masks to
> cover up for poor alignment.  But otherwise, poor alignment gives a
> terrible result.
>

The reason why it is hidden is that although it accounts for 3D movement of
the camera, it is only really useful for assembling an image of a flat
surface (like the facade of a building), it isn't generally useful for
assembling a 'normal' panorama.

With a normal panorama you might find that occasionally adding the X, Y, Z
parameters to the optimisation helps get a better fit, but really you are
just substituting for the lack of morph to fit functionality, rather than
calculating the 'actual' values for these parameters.


> As for the lens, I noticed the slight barrel shape of the parallel
> vertical lines in the original two photos of this thread.  I don't know
> whether to consider that a lens characteristic different from the default
> "rectilinear":  The part of such parallel lines that are perpendicular to
> the point of view are wider apart in viewing angle, and the viewing angle
> between the lines goes down with the distance from that perpendicular.  But
> those two photos both had the camera pointing up relative to the face of
> the building.  The perpendicular point is at the bottom of the lower
> picture.  So the visible slight bulge in parallel vertical lines looks to
> me like it is closer to the vertical center of the image, which would
> definitely be a lens characteristic, as opposed to representing the actual
> point of widest viewing angle between the lines (which I don't know whether
> that would also be a lens characteristic different from "rectilinear").
>

The barrel distortion is normal with any lens, and is accounted-for in the
a,b & c (and d & e) lens parameters. Though in general you should only need
to use the 'b' parameter for a rectilinear lens.

-- 
Bruno


-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj85y6Q%3DotvpVH%3Drov2tW-bBvjsqScqddoEMq0fSa%3DU_w%40mail.gmail.com.

Re: [hugin-ptx] Re: Vertical Hugin Panorama of Building has Discontinuity on sides

[Bruno Postle]

On Mon, 21 Feb 2022 at 02:31, scott092707 wrote:

>
> I actually did bring up the Optimizer Tab as before (since it solved the
> last issue), but the only optimizations presented to me this time were
> yaw/pitch/roll.
> I'll try again tomorrow (?) and see where one can ADD parameters, and do
> the 'translation y'.
> I'll also look at the lens section (didn't do so before), and look to
> selecting the 'lens b'.
>

The XYZ Translation parameters are initially hidden as they are not needed
for normal usage, they are made available by selecting Menu -> Interface ->
Expert.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Ziw1%3DAq7wF%3DqRJXi_%2BgBoFN_BSEQU8jUcckjXdhD2bC_Q%40mail.gmail.com.

Re: [hugin-ptx] Problem with Hugin Panorama

[Bruno Postle]

Hi Scott, firstly this is primarily a mailing list, so anything you attach
gets sent to 2000 mailboxes.

Anyway it looks like your problem is that the two photos were not taken
from the same position. Hugin assumes that you are stitching a panorama and
maps the images as best as it can to a spherical scene.

However Hugin does have a 'mosaic' mode, that can account for camera
movement where the scene is a flat surface like this.

You need to set the output projection to 'rectilinear' and optimise
'translation' parameters in the geometric optimiser.

-- 
Bruno

On Sun, 13 Feb 2022, 07:31 scott092707, wrote:

> Hugin usually does a great job, with minimal/no effort.
>
> Once in a while, nothing will get it to do what I want...
>
> The enclosed pics and .pto files are my effort to join two parts of a
> German bus station sign, the left side with the schedule and part of the
> right, the right with a map and some of the right end of the schedule.  I
> should have overlapped more, of course, but there SHOULD be enough to
> connect them. (There are 13 CPs, plus the  line, between them)
> I even indicated several lines CPs in the base of the sign, to help line
> things up, but as the resultant pic shows, they don't line up, and are not
> a line.
>
> Am I doing something wrong, or is this a bug (and if so, how to describe?)
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiWrgv_N2xRvcddUpJu2%2B5iaeJsaLL19WUt2ZwwrB5oSg%40mail.gmail.com.

Re: [hugin-ptx] Mask dialog, can't select just one when close together

[Bruno Postle]

On Thu, 10 Feb 2022 at 00:01, johnfi...@gmail.com
 wrote:
>
> When points are very close together in a mask, you can't select just one to 
> move.
>
> I understand having the points so close is not typical.  But the code seems 
> to have been written anticipating points being that close together and 
> intending that a single click should select all the nearby points.  
> Separately, there is a different way to select a group of points, so it seems 
> like a strange feature.
>
> Can someone tell me why the current behavior would be desired?

I experience this as trying to drag one node, but Hugin insists on
dragging the previous (highlighted) nodes instead, which would make
sense, but somehow the highlighted nodes seem to be more likely to get
moved than the unselected node that is exactly where I clicked.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhB%2B1NH5qcTygZuswgpExfmhF9-fgDeTNbTfH%3DNMoN4yg%40mail.gmail.com.

Re: [hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp

[Bruno Postle]

On Thu, 3 Feb 2022 at 18:42, T. Modes wrote:
>
> Okay, this is now reproducible here. It is also a side effect of moving the 
> selection code from the mouse down to the mouse up handler.
> I had to revert this change. I found no way to fix all these issue.
> I tried the fix the issue with selecting and moving cp in another way in 
> changeset 577d2a6299ff.
> Please test it. Hopefully it works now better and does not break something 
> other.

Thanks, seems to work ok.
Single-clicking a control point selects, centres it, and shows the
magnifier (unless already zoomed to 200%)
Click-dragging shows the magnifier, and only centres the point after
dragging. This is fine, though for myself I could do without the
centering after dragging, as I get a little bit lost with the jump
(the point I just moved isn't where I left it) - I'm not sure what
others think about this?

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zjo4AyyA2JP7MgLZaBpWSHDau35DekZCdXZX3D1iVgTgw%40mail.gmail.com.

Re: [hugin-ptx] Where is the choice to disable the fast preview window documented?

[Bruno Postle]

On Sun, 6 Feb 2022 at 23:24, johnfine2017 wrote:
>
> I eventually found out the method (hold ctrl while starting hugin) and then 
> found the place that is documented for re enabling fast preview window (it 
> brings up a dialog that lets you choose).  But I didn't find any 
> documentation of using that to avoid the crash on hugin statup that might 
> require it.

It is mentioned in the FAQ, but only for undisabling the Fast Preview
window: 
https://wiki.panotools.org/Hugin_FAQ#Simple_user_interface_can_not_selected_.2F_OpenGL_fast_preview_window_button_is_disabled

I thought this startup crash had been resolved by automatically
disabling the Fast Preview window in this situation (it has been a
long time since it was last reported). If the Ctrl trick is definitely
still required, the FAQ is a wiki page and can be edited.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhHD6NxMfgQodUXOGvQdXKi1gfjqDpgpXAjNEtxOxW90w%40mail.gmail.com.

Re: [hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp

[Bruno Postle]

On Wed, 2 Feb 2022 at 16:38, T. Modes  wrote:
>
> bruno...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 23:20:14 UTC+1:
>>
>> On investigation, it looks like the magnifier doesn't appear when you click 
>> down on a control point, it only appears once you have dragged it away from 
>> the original location, then when you let go it vanishes after a couple of 
>> seconds.
>
> This is not reproducible here. The magnifier appears when only clicking on 
> the cp.  (and also when dragging)


It could be a platform issue. If I click (mousedown and mouseup) on a
control point, the magnifier appears. If I click (mousedown) the
magnifier doesn't appear until I start dragging the control point, or
I mouseup.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhrsivLwXHtspxz4vTyae1YnxVmxtK7ycJO-jM_a7tw1Q%40mail.gmail.com.

Re: [hugin-ptx] Re: Removing magnifier hiding timer etc. from CPImageCtrl.cpp

[Bruno Postle]

On Tue, 1 Feb 2022, 17:53 johnfine wrote:

>
> I hope Bruno and others will answer your question, because I'm pretty sure
> Bruno disliked the current magnifier hiding and would be more competent to
> explain why and/or have more mainstream reasons.
>

I never really considered the possibility that the magnifier was on a
timer, it just seemed to disappear, and it wasn't clear how to make it
reappear.

On investigation, it looks like the magnifier doesn't appear when you click
down on a control point, it only appears once you have dragged it away from
the original location, then when you let go it vanishes after a couple of
seconds.

It seems to me that it would be useful to see the magnifier straight away
on clicking, so you can decide *not* to move the point.

It is there while you are moving the point with the arrow keys, which seems
good to me, and frankly this is the only time when the magnifier is any
real use anyway.

It makes sense that it disappears when not being moved, since it obscures a
lot, though maybe two seconds is a bit quick.

When click-dragging a point, the other viewpoint actually shows a magnifier
for the previous control point, not the point you are actually moving, only
on mouse-up is the current point selected and the correct magnifier shown.
It only works correctly if you first click on the point, then click again
to drag - this is surely a bug.

When hovering/switching the mouse between viewports, the magnifier appears,
but only in the other viewport, I'm not sure what benefit this has.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjWMbo_1ygRqQaCTRBH_FMCv%2BWeZBzgi8Qu0tr%3Detz2wg%40mail.gmail.com.

Re: [hugin-ptx] Opinions on warping to fine tune the results of control point optimization?

[Bruno Postle]

On Tue, 1 Feb 2022 at 12:53, johnfine2017 wrote:

> On Tuesday, February 1, 2022 at 6:56:17 AM UTC-5 bruno...@gmail.com wrote:
>
>> The remapping and stitching is performed as usual by the Hugin toolchain,
>> ptomorph just manipulates the input images a bit to make them stitch better.
>>
>
> By "input" do you mean original?  I can't imagine how that data flow would
> work.  Maybe I'm also confused by the terminology, but I think I understand
> what the "remapping" and "stitching" steps are.  In that context, I saw
> "fine tuning" as an adjustment* logically* after remapping and before
> stitching.  I would not want that *actually* after remapping, because I
> think the interpolation of moving pixels non-integer distance is best done
> all at once.  So I would want the morphing to occur during the remapping
> (digging into that code is the biggest obstacle to my actually doing this
> whole thing).
>

ptomorph was a proof of concept, so it mapped the coordinates of both sides
of each control-point to the output panorama, mapped the half-way point
back to each source photo, and used this as the distortion destination. The
source photos were distorted into temporary files and a new PTO project
created that used the temporary images as input.

As I remember, the conclusions were that:

1. Squashing triangles as implemented in panotools looks terrible, it
doesn't work, the 'Shepards' stretching/morphing as implemented in
ImageMagick is much better. They both force an exact alignment, the pixel
ends up exactly where you tell it to go, but Shepards does it right.

2. High-order polynomials work ok for correcting parallax. Though with a
polynomial you get a smooth transition, so the pixels don't end up exactly
where you tell them to go. The problem with a high-order polynomial
distortion is you need a huge number of control points over the whole image
or optimisation goes a bit mad.

3. Low-order polynomials are more stable, but less useful for correcting
parallax errors which are often only visible in small-scale features.

4. The Shepards distortion is not an easy fit with the panotools lens
model, so it would need to be implemented as a pre-processor (like
ptomorph) or as a post-processor, either way it could be rolled-into nona.

5. Shepards distortion (and squashing triangles) won't work so well when
three or more images overlap. Either: you accept that there is no perfect
solution, you implement multiple-image control points (ew), or you only
allow control points that are very close to the seam boundary (forcing a
two image solution everywhere).

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhW7e25To6i5gyYfaexu%2BSAFOmcfwB%3DF2eZ5601J86X0Q%40mail.gmail.com.

Re: [hugin-ptx] Opinions on warping to fine tune the results of control point optimization?

[Bruno Postle]

On Mon, 31 Jan 2022 at 22:42, johnfi...@gmail.com 
wrote:

> On Monday, January 31, 2022 at 5:06:20 PM UTC-5 bruno...@gmail.com wrote:
>
>> See the ptomorph proof of concept from ten(!) years ago here:
>> https://groups.google.com/g/hugin-ptx/c/UripOuuYXCQ?pli=1
>>
>> This works incredibly well, with no need for low-priority control
>> points, but I never pursued it, and it needs some thought regarding
>> getting it to work with more than two photos.
>>
>

> Looking at the full stitched version  vs. the full morphed version, the
> stitching error in the full morphed version (where the silver pole crosses
> the boundary between the top and second to top window of the glass windowed
> cabinet) is surprising for the described method, though I expect a few
> control points could fix it.
>

Probably I hadn't noticed this error and didn't put in any points to fix it.


> The overall shape differences are more concerning.  That specific scene is
> one in which broad shape differences are hard to visually parse.  So I
> can't validate my guess that in other examples the shape change of that
> method would be too big.
>

This is a more standard scene I did at the same time, though not correcting
parallax, the machine moved between shots:
https://www.flickr.com/photos/brunopostle/7103560665/


> Both the big shape change and the issues of chaining the methodt across
> more photos are reasons that I was thinking of the morph as a fine tune on
> top of existing methods, rather than as a replacement.
>

The remapping and stitching is performed as usual by the Hugin toolchain,
ptomorph just manipulates the input images a bit to make them stitch better.

The question was always: should this morphing be added as an overall
polynomial distortion in the panotools lens model so that it became another
part of the optimisation step, or is it just a stitch-time fix (as in the
ptomorph examples). The problem for me is that doing it in the lens model
is more elegant, and the problem of three or more images doesn't exist
because you wouldn't be forcing an exact alignment; but on the other hand I
was getting *really good* results using the ptomorph approach with the
'Shepards' stretch to fit distortion between two images.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhW8tKLGVMAoWCByFRdXowcHHUkF_TFeZGtmrNfEUV9bw%40mail.gmail.com.

Re: [hugin-ptx] malfunction in CPImageCtrl when the magnified image has over 2**27 pixels

[Bruno Postle]

Hi John, I'm just catching up on my email, do you have access to the
Hugin repository yet?

If not, then send me your sourceforge username. Note that sourceforge
supports a fork/pull-request workflow (similar to github), so you can
work on a separate personal repository just as easily as the main
repository. If you do choose to work on the main repository, then
typically features get developed in temporary branches and merged into
'default' when ready for user testing. The default branch will become
the next release. The numbered branches are for specific releases, so
the 2021.0 branch is kept open in case a severe bug is found that
would require a hotfix release (never been needed so far).

-- 
Bruno

On Sun, 30 Jan 2022 at 22:38, johnfi...@gmail.com
 wrote:
>
> It now appears to me that the limitation may be in the device driver 
> (Nvidia).  There is quite a lot to this malfunction that seems to me to be 
> almost impossible to fit into the theory that the malfunction is in the 
> driver.  But I've stepped through the code down to the point that the image 
> is passed to the driver (XShmPutImage) and it gets there with a valid looking 
> image (and all related values) in the failure case, and it apparently passes 
> the whole (giant) image to the driver along with clipping info, rather than 
> clipping it before passing it.
>
> I still think I can make the change in the way implied by the FIXME comment 
> in CPImageCtrl::OnDraw so that for users who wouldn't see the problem, it 
> would still be a performance boost.
>
> I still don't know the right way to even request the mercurial rights needed 
> to correctly share the changes I want to make.  Failing that, I have a fast 
> enough CPU, if this is for my own use only, I don't care about the small 
> performance cost of fixing this just enough to work vs. the performance 
> increase of a better fix.
>
> So for now, I'll go back to adding the features I want to that dialog, rather 
> than further chase this problem.
>
> Of course, if you think I misunderstood what I saw in stepping through the 
> code (and the failure is actually elsewhere) I'm open to suggestions.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjQed6n949z9NZYLXzY9xVK17Vyda65axT1yDUApGKYCw%40mail.gmail.com.

Re: [hugin-ptx] Opinions on warping to fine tune the results of control point optimization?

[Bruno Postle]

See the ptomorph proof of concept from ten(!) years ago here:
https://groups.google.com/g/hugin-ptx/c/UripOuuYXCQ?pli=1

This works incredibly well, with no need for low-priority control
points, but I never pursued it, and it needs some thought regarding
getting it to work with more than two photos.

-- 
Bruno

On Mon, 31 Jan 2022 at 16:41, johnfine wrote:
>
> The most important use case for this idea would also depend on support for 
> low priority control points, which IIUC is in a fork of Hugin that I haven't 
> had time to look at yet.
>
> Assume that control points are very accurately placed, but still don't 
> optimize very well.  So the remapped images don't align very well.  For high 
> contrast areas, anything worse than a single pixel of misalignment is a very 
> poor alignment.  The usual Hugin answers to that seem to be based on avoiding 
> blending high contrast areas.  Sometimes that is a good solution.  Sometimes 
> it isn't.
>
> One cause of major misalignment is the combination of translation (moving the 
> point of view between images, rather than using a tripod with a perfectly 
> adjusted nodal slide) with subjects of the photo being at significantly 
> varying distance.
>
> The translation optimization necessarily depends on all connections between 
> two images (including indirect connections through other images) being at the 
> same distance from the camera.  For multiple subject distances, there is no 
> correct remapping for translation.
>
> Assume either user action (or maybe some automation I haven't though of) 
> lowers the priority of all control points that connect two images at other 
> than the most important subject distance.  Then the alignment for that 
> distance is great, but other distances are a problem.
>
> If high contrast important features at other than the preferred distance are 
> continuous beyond the width of an image, there is no decent solution:  
> warping would distort the shape, while any other approach would blur the 
> seams.
>
> But more often, the high contrast important features outside the preferred 
> distance are isolated.  If those features are tagged with low priority 
> control points, and the less important areas between them don't contain many 
> control points, then the necessary shape distortion of fine tuning by warp 
> would land in the less important areas.
>
> Some reshaping is fundamentally necessary for that combination of viewpoint 
> shift plus multi-distance.  Blurring across a seam can concentrate the 
> reshaping where it matters least.  But in many cases I think warping would do 
> a better job with less user effort.
>
> In case it wasn't obvious, my idea is to compute all the remapping implied by 
> the optimization results (with prioritized control points) then apply 
> additional remapping by warping to move the control point whatever extra is 
> needed to get from close to perfect.  Then compute the resulting pixels based 
> on the complete movement and blending or original pixels.
>
> I probably won't take on a chunk of work this big.  But I'm thinking about it 
> (for after the easier enhancements I want to make to Hugin).  But I am 
> considering and would appreciate feedback as if I would do it.
>
> Without having tried it, my intuition as a user of Hugin is that it would be 
> enough better that I'm surprised it wasn't designed this way.  Feel free to 
> tell me what I might be misunderstanding.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjG8oE9_731Rh-H7fXibdeTEzEShdpbS46KkCqcq5eLKw%40mail.gmail.com.

Re: [hugin-ptx] Control Point dialog features

[Bruno Postle]

On Sat, 22 Jan 2022 at 11:46, T. Modes wrote:
>>
>> Basically, the fix is to only centre the current control point in the
>> viewports on mouseup, currently it centres on mousedown.
>
> Okay, now I see. I tested with zoom set to fit. There is was not obviously.
> Tried to fix in repository. Hopefully the changes does not affect other 
> things.

> Also done. Middle drag should now work as in the fast preview windows - like 
> a touchscreen.

Thanks! tested, both these fixes seem to work as expected here.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjcYDbW%3D-owfobGzbbGG5SOQFZmJjR5%3DHM3pM1pmV0f0w%40mail.gmail.com.

Re: [hugin-ptx] Vertical panorama exposure issue

[Bruno Postle]

On Sat, 22 Jan 2022 at 18:24, johnfine2017 wrote:

> There isn't actually a lot in the panorama above or below the middle image.  
> The top and bottom images overlap each other a lot in addition to each mostly 
> overlapping the middle.  The original middle image isn't very distorted 
> (vertical lines bulge inward just a very small amount).  So I would expect to 
> be able to get a less distorted panorama.  But I don't know about 
> projections, so I don't know what to try.
> It seems like there must be some metric wrong in the exif and/or some user 
> error to have the whole panorama this distorted compared to the middle image 
> alone, which covers most of the total.

The only projection that renders straight lines as straight is
'rectilinear', the other projections may give you more viewing angle,
but they do this by curving straight lines.

The photos should align seamlessly, if they look to have different
distortions then something is wrong.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiVy%3Dc-mfDaw_qg6TqCtOgnZc8LwrRuZCqGOWKVpL-34w%40mail.gmail.com.

Re: [hugin-ptx] building hugin on fedora

[Bruno Postle]

On Sat, 22 Jan 2022 at 15:39, johnfine2017 wrote:

> I got build instructions both from
> https://wiki.panotools.org/Hugin_Compiling_Fedora
> and from a recent post by Bruno suggesting

> The list of things to install is very different between those two sources.  
> Is that first one obsolete?

The wiki will be out of date, the list of packages I gave is that used
to build the current official fedora Hugin package.

> Then my system crashed.  Seemed to be a display driver crash.  Maybe there is 
> some problem in building hugin with j16, but more likely it is a display 
> driver bug.  In an otherwise new and powerful system, I have an ancient 
> graphics card driving two high res displays.  The nouveau driver crashes 
> constantly for this hardware, so I'm not using it.  I'm using the 340 driver 
> from Nvidia, which doesn't crash much.  But it does crash.

There is definitely something wrong with your graphics setup. The
standard nouveau driver might not have all the top features, but in my
experience it is very stable. You shouldn't expect a problem in Hugin
to crash the whole system like this.

All the warnings about gtk window sizes don't seem to cause any
problems here, though I have often wondered if there was something to
be gained from fixing them.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZiiZgvQBC_aJjOFQxOLXoji5MBccq-yLGaKQmFpVdOh5w%40mail.gmail.com.

Re: [hugin-ptx] Control Point dialog features

[Bruno Postle]

On Sat, 22 Jan 2022 at 01:17, johnfine wrote:
> On Friday, January 21, 2022 at 7:20:51 PM UTC-5 bruno...@gmail.com wrote:
>
> Without a clear statement of the original intent, there is no way I would try 
> to fix the code for removing the magnifier to behave as intended and 
> predictably.

I'm not sure anyone can remember what the original intent of the
magnifier was, all I know is that it disappears just when I want it.

> I didn't take notes as I kludged past issues.  I'd rather be in Fedora than 
> in Ubuntu for this anyway.  So I think my best path on that is to do it over 
> from scratch on Fedora and capture details each time I need to kludge 
> something.  Then I'll put all that in a new thread here.

Hugin builds out of the box on all versions of fedora. First fetch the
build dependencies:

sudo dnf install gcc-c++ libpano13-devel zlib-devel libtiff-devel
libjpeg-devel libpng-devel gettext-devel wxGTK3-devel boost-devel
freeglut-devel cmake desktop-file-utils OpenEXR-devel exiv2-devel
glew-devel python3-devel swig flann-devel perl-Image-ExifTool
mesa-libGLU-devel libXmu-devel sqlite-devel vigra-devel perl-podlators
fftw-devel lcms2-devel

..then in the Hugin source:

mkdir BUILD
cd BUILD
cmake ..
make
sudo make install

This will install it into /usr/local, so (on fedora) you will need to
set LD_LIBRARY_PATH before you run Hugin:

   LD_LIBRARY_PATH=/usr/local/lib64 hugin

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgPLzW95a6%2BkMJRUudFyWdvtN2VCJnnYWoLvHJ02qFnvg%40mail.gmail.com.

Re: [hugin-ptx] Control Point dialog features

[Bruno Postle]

On Sat, 22 Jan 2022 at 08:57, T. Modes wrote:
> bruno...@gmail.com schrieb am Samstag, 22. Januar 2022 um 01:20:51 UTC+1:
>>
>> When zoomed-in, if I go to drag a control point that is not in the
>> centre of the viewport then the view jumps to centre the viewport on
>> this location - but my mouse is still in the corner of the viewport -
>> placing the control point in a location nowhere near the original
>> location. The workaround is to first click on the control point to
>> centre it before trying to drag it, but this isn't obvious.
>
> Can you explain it better? How do you select the cp? When selecting the cp in 
> the list the mouse is over the list and not in the corner. Or do I understand 
> something wrong?

You can select a control point by clicking on it in the control point
lists, or by clicking on it directly in a viewport. Selecting a
control point centres it in the viewports.

However if see a control point and want to move it, the obvious way to
do this is to just click and drag it in one go - this only works
properly if the control point I want to drag is *exactly* in the
centre of the viewport, otherwise the viewport jumps to where the
control point was originally, but the mouse position is still
somewhere else.

Basically, the fix is to only centre the current control point in the
viewports on mouseup, currently it centres on mousedown.

>> When the Hugin Control Points tab was created the most popular
>> panorama viewer was QuickTimeVR, this has a navigation system where
>> you click-dragged on the screen and the view panned in this direction
>> while you kept the mouse button down, so it made some kind of sense to
>> pan around the Control Points tab in the same way. But these days
>> every application uses middle-mouse drag to move the image as if you
>> had grabbed it and placed it in the new position - maybe it is time
>> Hugin did the same.
>
> Middle-mouse drag work in current version… Or do you mean to invert the 
> direction of the middle-mouse drag?

Yes, invert it so it works like a touchscreen. If you want to pan
around quickly there are scrollbars.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhMM3us%3Dy3BJxKh%3DfeCe3Rmkoay9-P8%3DsKPPh%2BQQAnmCw%40mail.gmail.com.

Re: [hugin-ptx] Vertical panorama exposure issue

[Bruno Postle]

On Sat, 22 Jan 2022 at 00:16, johnfine2017 wrote:
>
> I still think that what I want for the main problem is to pre-shift the 
> exposure within each photo based on relative (within each image) vertical 
> position.  I think I know which open source tool will make that fairly easy 
> (once I learn how to use it).  So I'll reread that documentation and 
> experiment a lot (documentation makes it easy to see such effects are 
> supported but hard to see exactly how you ask for them).
> I'll assume you know hugin well enough that your not mentioning anything 
> about doing that inside hugin implies it isn't there.
> I don't mind using multiple tools.  I'd want to learn the purely-in-hugin way 
> if it exists.  But otherwise whatever works.

Yes, just tell Hugin to ignore the Exposure EXIF information and use
the images as-is - your camera has already decided how best to expose
the different parts of the scene, so you can use the images as
provided instead of letting Hugin adjust the exposure - this does what
you want entirely within Hugin.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zjs_b2SZ5dMwa9Mz-h-6iOHQp5kEOty%3DZCwFDWpNCAH_Q%40mail.gmail.com.

Re: [hugin-ptx] Control Point dialog features

[Bruno Postle]

On Fri, 21 Jan 2022 at 18:34, johnfine2017 wrote:
>
> I want to make a bunch of changes to the control point dialog.

> 1) Max resolution.  200% really isn't enough for me to place control points 
> easily.  I don't know what puts me or my photos or my large high res displays 
> outside the usual range, but adding 400% and 800% choices is a trivial code 
> change that will make the program easier for me to use.

This might be useful, though the arrow keys do shift the control
points a tenth of a pixel at a time which is usually accurate enough,
note also that the fine-tune function also moves control-points to
sub-pixel accuracy.

> 2) Losing the magnifier.  It always goes away at 200%, even though it 
> magnifies enough to be helpful at 200% and can be made to usefully magnify 
> even more.  I found/understand the code that removes it for 200%.  It also 
> sometimes gets a timer and goes away by timer.  I found but don't understand 
> that code.  I don't understand the intent of it going away by timer, nor the 
> actual behavior (as a user, I can't predict which actions do or don't make 
> the magnifier go away on a timer).  I'm slow.  I never want a timer taking 
> the magnifier away.  I do want to be able to actively get rid of the 
> magnifier, see item 3.

I never quite understood what made the magnifier come and go, so
anything you can do to make this more predictable.

Other annoyances with the Control Point tab:

When zoomed-in, if I go to drag a control point that is not in the
centre of the viewport then the view jumps to centre the viewport on
this location - but my mouse is still in the corner of the viewport -
placing the control point in a location nowhere near the original
location. The workaround is to first click on the control point to
centre it before trying to drag it, but this isn't obvious.

When the Hugin Control Points tab was created the most popular
panorama viewer was QuickTimeVR, this has a navigation system where
you click-dragged on the screen and the view panned in this direction
while you kept the mouse button down, so it made some kind of sense to
pan around the Control Points tab in the same way. But these days
every application uses middle-mouse drag to move the image as if you
had grabbed it and placed it in the new position - maybe it is time
Hugin did the same.

The Mask tab can show the location of include masks in other images as
an overlay on the current image. In the Control Points tab it would be
nice to do something similar and show the outline of the right image
on the left image and vice-versa, maybe by greying-out areas of the
images that don't overlap. This would be useful because ultimately the
stitcher places a seam down the middle of this overlap and control
points near the seam are more important for alignment than those at
the edge.

> 3) More keyboard control.  I don't have the dexterity to do as much with the 
> mouse in that dialog as I assume others do.  I have a lot of accidents, such 
> as create a point when I intended to move one, then try to delete the new 
> one, randomly deleting a distant one instead, then they renumber (see item 5) 
> and I'm totally lost.  Using the keyboard to move a point, I can never 
> predict nor control which of the two will move (see item 4).  I want keys to 
> control which side is selected.  Code exists that given a user provided 
> position for one side of a control point will try to find the other side.  I 
> don't yet know where that code is, but I want to define a key to activate it 
> (user places or moves a point then presses the key to switch sides, then the 
> key to auto place the corresponding point).
> 4) Visible indicator of which side is selected.  No clue what it should look 
> like nor how to code it.  Suggestions appreciated, but I'll figure it out 
> myself if necessary.

This would be useful.

> 5) Global stable numbering of points (as an option if this gets shared with 
> others).  I'm sick of losing track as points renumber.  I want a gap left 
> when I delete a point, that may be reused for a new point but won't be 
> reassigned to a different point.

This might be difficult given the underlying data structure, but I
don't know for sure.

>  I want the ability to place a control point on more than two images in 
> multi-way overlap.  So I should be able to switch the active list of points 
> for a pair of images from their intersection to their union (and have some 
> visible indicator of left vs. right vs. both) then select a point that is in 
> just one of the two sides and right click selection and/or key to have the 
> software guess where it goes in the other side.  (I have enhancement ideas 
> elsewhere that depend on points identified this way, but even without those 
> enhancements, this would be a convenience feature for me).  Advanced version 
> of this would have the option to use the most recent optimize results to 
> exclude point that are outside the geometry of the other side.

Re: [hugin-ptx] Vertical panorama exposure issue

[Bruno Postle]

On Fri, 21 Jan 2022 at 21:47, johnfine2017 wrote:
>
> I'm trying to assemble a specific vertical panorama, but also trying to learn 
> methods for assembling a vertical panorama.
>
> One major issue (that I'm furthest from figuring out on my own) is the 
> exposure issue:
> Taken on a cell phone (fixed F 1.9, Focal length 2.91, aperture 1.85, not 
> sure those even have the same meaning as on big camera) with auto varying 
> time:

They have the same meaning except all the dimensions are smaller for a
small sensor, Hugin should interpret them ok.

> Bottom photo is 0.025 sec exposing the street well and including some totally 
> blown out sky.
> Middle photo is 0.0083 sec exposing buildings well with sky blown out and 
> street too dark.
> Top photo is 0.0073 sec exposing the sky well.
>
> I definitely don't want to compress the range.  I'd rather be dishonest than 
> correct for that.
>
> If the alignment were perfect, then doing no exposure correction would work 
> with the blending from one image to the next smoothing the exposure 
> transition.  But I haven't gotten the alignment near that good and would like 
> to learn how to live with poor alignment.  That involves narrower transition 
> zones in controlled places, which would then generate ugly exposure jumps.
>
> What I think I want is a height based exposure shift in each photo (rather 
> than the usual exposure to exposure nonlinear mapping to compress the range 
> without losing much detail).  In each photo I think I want a smooth 
> transition from making the bottom a little brighter to making the top a 
> little darker.  Then the same final pitch of each photo would match in 
> brightness.

Hugin will by default map the exposure of the photos to the scene,
meaning that it will brighten your sky image and darken your ground
image so that they match the exposure of the middle image - the end
result (if you stitch to an 8bit format like JPEG) is that you may as
well have taken the photos on the middle exposure in the first place.

Actually most of the time this is wanted, most panoramas I shoot these
days are taken with my phone on auto-exposure, and I don't worry that
the individual photos have different exposure times, Hugin blends them
together seamlessly.

But it doesn't work if you want to see the clouds and undergrowth in
the same final panorama - for this you need tonal range compression -
things you can do:

1. Stitch to a file format that can hold this large dynamic range,
such as EXR, and 'tone map' this into a viewable 8bit image using a
tool like LuminanceHDR.

2. Force Hugin to ignore the exposure recorded in the photos (and
discard any fine-tuning by the Hugin photometric optimiser). Select
the photos in the Photos tab, edit the Eev and set them all to the
same number. It doesn't matter what this new Eev number is, but you do
need to set the Eev of the output panorama to the same number, or the
exposure of the output will be way-off (in the Preview window there is
a little handy arrow button marked 'EV' that resets the output
panorama exposure to the average of the input photos). This will give
you your clouds and undergrowth visible in the same panorama, but the
seams might not be exactly where you want them, so create masks that
remove the overexposed clouds in your middle photo and that remove the
underexposed buildings from your sky photo - don't try and follow the
edge exactly, leave a bit of sky and building for Hugin to use for the
transition - this will move the seam to the boundary between buildings
and sky, and with luck this seam is completely invisible.

> Also, is there good info on the other techniques for a narrow vertical 
> panorama?  I don't know what projection works OK.  The best I found with a 
> google search is to turn the whole thing sideways and use the usual methods 
> for that kind of panorama, then rotate it afterward.  Is that really the best 
> way to do narrow vertical?

Most of the Hugin output projections are designed for very wide angle
of view scenes. You can try a fisheye projection like Stereographic,
these are symmetrical and treat horizontal the same as vertical. But
what you probably want is Transverse Mercator, this projection is
designed specifically for tall and narrow panoramas.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhJDihqQHCnR6-%2BtiaawS5LK4XHjA2Ue2LCYTj2Vvx68g%40mail.gmail.com.

Re: [hugin-ptx] Endless loop?

[Bruno Postle]

The optimiser can take a very long time with difficult projects.

Is this with Hugin 2021.0? or an earlier version? This latest Hugin was
released together with libpano13-2.9.21, which has had major changes to the
optimiser.

Can you attach a PTO project that shows the problem? (there is no need to
attach the images)

-- 
Bruno

On Sun, 16 Jan 2022, 15:43 Mihai Dobrescu, wrote:

> Hello,
>
> As a hobbyist, I try to make some panorama out of 20 images.
> It is stuck at align step, apparently in an endless loop.
> Is that possible? Does it have some safety to trigger when it runs in
> circles?
> Strangely, I've added one image more and it worked once, but not anymore.
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgLObeMg5Fhj9C9X-Y%3Dtro0EC3DfPuMr3EOhrQKgRLW9A%40mail.gmail.com.

Re: [hugin-ptx] Re: How to export panos to Google Maps?

[Bruno Postle]

On Tue, 4 Jan 2022, 13:33 Carlo, wrote:

>
> Stitched with Hugin and "reworked" with Gimp. There are no special
> metadata in this file.
> I uploaded this image 6000×3000 to my photos.google folder.
>

Note that Hugin adds the Google panorama metadata automatically whenever
you stitch a project.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhQpbg8a1ZdQduMJTO-h0%2BYWD-08ay3_S4JCOX7NBmf2g%40mail.gmail.com.

Re: [hugin-ptx] Re: How to export panos to Google Maps?

[Bruno Postle]

On Tue, 4 Jan 2022, 12:03 Carlo,  wrote:

> Can anyone see this one?
> https://goo.gl/maps/xJxgPLeSrAdgLmQHA
> I just published it with iPhone and the Street View app.
>

Works for me, launches in the Google maps app on Android - Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zg01isBRor0QHn%3DOo4-EWNsCD5SJ7Y%2BaAezUsZbgENMbQ%40mail.gmail.com.

[hugin-ptx] libpano13-2.9.21 released

[Bruno Postle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

libpano13 is the PanoTools library for panoramic imaging.

A libpano13-2.9.21 tarball has been uploaded to sourceforge, this is
a final release and is identical to libpano13-2.9.21_rc3:

https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.21/

This release should be binary compatible with previous versions - This means
that prebuilt Hugin executables should just work with this libpano13.

There have been several changes since 2.9.20

* New build option: USE_SPARSE_LEVMAR, requires the Suitesparce library.  This
   significantly improves geometric optimisation speed (thanks to Florian
   Königstein and Thomas Modes)

* General clean-up of the build system, removal of the autotools build system,
   CMake is now the default

* The test suite is now functional again

* A lot of fixes for potential crashes and safer handling of data

* Fix for bigendian architectures

* Link with libm if necessary

* Various installation location and content fixes

* Fix for bigendian architecture check for FreeBSD

SHA256SUM: 79e5a1452199305e2961462720ef5941152779c127c5b96fc340d2492e633590 
libpano13-2.9.21.tar.gz

This release is equivalent to HG 906:2d4aeb9ca433

Here is the full ChangeLog since 2.9.20 for more details:

2021-12-13 17:25 +0100  tmodes(1f44b6e37e89)

* panorama.h:
Fixes big endian check for FreeBSD

2021-11-29 20:46 +  Bruno Postle(cdd43e6c053c)

* ChangeLog.hg:
update ChangeLog.hg

2021-11-28 10:20 +0100  tmodes(3fb06db30161)

* panorama.h:
Improved fix for endianess for more systems

2021-11-02 20:45 +  Bruno Postle(84b6a82c8afc)

* panorama.h:
Fix for bigendian architectures (Thomas Modes)

2021-11-01 18:47 +  Bruno Postle(4d12cc78cc80)

* CMakeLists.txt:
Fix support for lib/lib64 installation dirs (Andreas Metzler)

2021-10-30 14:37 +0200  tmodes(a97fddc5a031)

* CMakeLists.txt:
Fix pkg-config file contents and location (Patch by Andreas Metzler)

2021-10-28 17:43 +0200  tmodes(1b0e1a205121)

* CMakeLists.txt:
Check if linking against libm is needed

2021-10-28 17:43 +0200  tmodes(b6aef04b6318)

* CMakeLists.txt:
Let CMake for itself figure out the lib directory

2021-10-26 21:24 +0200  tmodes(2822f00918bc)

* tools/CMakeLists.txt:
Install tools in all configurations

2021-10-26 17:39 +0200  tmodes(343847e37b1f)

* CMakeLists.txt:
Remove Windows rc files from file list for Unix

2021-10-26 17:37 +0200  tmodes(af97aa936771)

* CMakeLists.txt:
Fixes generation of libpano13.pc file

2021-10-16 19:04 +0100  Bruno Postle(ac7932640266)

* ChangeLog.hg:
update Changelog.hg

2021-09-18 11:22 +0200  tmodes(454a8e337d54)

* CMakeLists.txt:
Silence a CMake warning

2021-09-18 11:08 +0200  tmodes(ef176a030c82)

* PTcommon.c, parser.c, ppm.c, resample.c,
tests/simpleTiff2psd/reference/simpleStitch_crop_1_layer.psd,
tests/simpleTiff2psd/reference/simpleStitch_crop_2_layer.psd,
tests/simpleTiff2psd/reference/simpleStitch_uncrop_1_layer.psd,
tests/simpleTiff2psd/reference/simpleStitch_uncrop_2_layer.psd,
tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_1_layer.psd,
tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_2_layer.psd:
Merged branch libpano13-2.9.21

2021-09-18 11:04 +0200  tmodes(e1b647e267a0 )

* tests/README.TXT,
tests/simpleTiff2psd/tests/simpleStitch_crop_1_layer.psd,
tests/simpleTiff2psd/tests/simpleStitch_crop_2_layer.psd,
tests/simpleTiff2psd/tests/simpleStitch_uncrop_1_layer.psd,
tests/simpleTiff2psd/tests/simpleStitch_uncrop_2_layer.psd,
tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_1_layer.psd,
tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_2_layer.psd:
deleted file.
* tests/README.TXT,
tests/simpleTiff2psd/tests/simpleStitch_crop_1_layer.psd,
tests/simpleTiff2psd/tests/simpleStitch_crop_2_layer.psd,
tests/simpleTiff2psd/tests/simpleStitch_uncrop_1_layer.psd,
tests/simpleTiff2psd/tests/simpleStitch_uncrop_2_layer.psd,
tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_1_layer.psd,
tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_2_layer.psd:
Remove unused files

2021-09-18 11:03 +0200  tmodes(d247e9b41788 )

* file.c,
tests/simpleTiff2psd/reference/simpleStitch_crop_1_layer.psd,
tests/simpleTiff2psd/reference/simpleStitch_crop_2_layer.psd,
tests/simpleTiff2psd/reference/simpleStitch_uncrop_1_layer.psd,
tests/simpleTiff2psd/reference/simpleStitch_uncrop_2_layer.psd,
tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_1_layer.psd,
tests/simpleTiff2psd/reference/simpleTiff16-16

Re: [hugin-ptx] help for new user

[Bruno Postle]

On Mon, 27 Dec 2021, 18:38 dgjohnston, wrote:

>
> Bruno … thanks for your quick responses on this forum.  It is very much
> appreciated.
> 1. Am I correct in saying that when hugin optimizes for translation that
> the canvas always stays at 0,0,1 and then the x,y,z values basically move
> the camera position of each photo so that the control points line up as
> best as possible?
>

Yes

2. When hugin optimizes for translation is there one photo that stays at
> Z=0?
>

Usually yes, the anchor photo will stay at 0,0,0, but you can put it
wherever you like, and dragging the set around the preview in 'mosaic' mode
will change the xy values

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zhg4%2BJghX3PGxwZ8DxF%2B2uFOZsKzaWYF2Mh2Sbq0eNAjQ%40mail.gmail.com.

Re: [hugin-ptx] Re: help for new user

[Bruno Postle]

On Mon, 27 Dec 2021, 15:43 johnfi...@gmail.com, wrote:

>
> On Monday, December 27, 2021 at 9:56:13 AM UTC-5 bruno...@gmail.com wrote:
>
>>  all the images are projected is at a Z distance of 1.
>>
>
> I'm taking that as the definition of the units X, Y and Z are all in.  I
> want to use some math to verify that I understand what that means.
>
> I suddenly realize I don't know whether we normally talk about "angle of
> view" horizontally or diagonally.  I'm more comfortable with horizontal.
>

panotools/Hugin uses the horizontal angle of view in degrees. There is a
quirk which is that the lens parameters are mapped to the narrowest
dimension of the image which is not the width for landscape images.

If I'm doing my trig correctly, the width of the field of view matches its
> distance when the angle of view is 53.13 degrees.  If that was the total
> angle of view of the resulting mosaic, then the X value of each photo would
> range from -0.5 though +0.5 based on the fraction of full mosiac width that
> each component photo is off center.
> For a narrower angle of view, those X numbers would be smaller (as in the
> test I mentioned in which 0.1 was a "large" value for X).
>
> The range -0.5 to 0.5 would be shifted if the anchor image were off
> center, and could also be increased or decreased if the yaw were nonzero.
>
> For a rough understanding of the scale of X, Y have I got that right?
>

Yes I think so

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZjKiY51ec6Zk6FK6Pi%3DUEn_7UbbBGSqguG5iPAUS_ROMg%40mail.gmail.com.

Re: [hugin-ptx] Re: help for new user

[Bruno Postle]

On Mon, 27 Dec 2021, 15:37 Donald Johnston, wrote:

> Bruno, when hugin loads a number of photos does it base its initial Z
> value for the output camera on the photo marked as the anchor?
> And then optimize other Z values to that?
>

The xyz values for the viewpoint of the output panorama are always 0,0,0.
When you create a new project, all the photos are initially assigned 0,0,0
as well, since the assumption is that you are not doing any
translation/mosaic trickery.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj8KUb8ezKExwEOa4DNGH1vhnyEFP_ssFoYzyCzSZ4ukg%40mail.gmail.com.

Re: [hugin-ptx] Re: help for new user

[Bruno Postle]

On Mon, 27 Dec 2021, 13:41 johnfi...@gmail.com, 
wrote:

> " you will need to use all of these, but not all at once - this can
> confuse the optimiser. "
>
> I want to understand that detail.  Photos tab: Optimize Geometric: the
> calculate button:
> Does it start from zero when you click it or does it start from wherever
> any previous optimize finished?  Your statement, that I want to understand,
> implies that previous values of its outputs influence it.
>

It starts at the previous values, so if you are stuck in a local minima you
may have to reset all the values and start from the beginning.

In other kinds of software, a typical optimizer can find a local optimum in
> the parameter space that might be much worse than the global optimum, so
> the starting point can make a big difference.  I don't know whether that is
> what you mean by "confuse".
>

Yes, the simplest way to get stuck in a local minima is by having angle of
view for all photos at 0 (this is so easy that Hugin has various built-in
workarounds to avoid this).

There other ways to get stuck, particularly barrel distortion can be so
extreme that only resetting it all to 0 will get you out.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj-HfnP6%3DJX1Xfe9%3DXXGPguxMaPCHGjxXuD6SxhMx_GQA%40mail.gmail.com.

Re: [hugin-ptx] Re: help for new user

[Bruno Postle]

On Mon, 27 Dec 2021, 13:24 johnfi...@gmail.com, 
wrote:

>
> X and Y should hold the major values BUT I don't yet understand what units
> they are in:  In the test I just ran, they must be quite big units because
> a value of 0.1 is big.
>

The 'camera' for the output panorama is at 0,0,0 and the canvas where all
the images are projected is at a Z distance of 1. So for a mosaic, each of
the photos are likely to have a Z value between 0 and 1.

-- 
Bruno

>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zivm1wuc0agw4GOOEEVHxhhdUqjaeLJgO4za%3DtLhkddfw%40mail.gmail.com.

Re: [hugin-ptx] Re: help for new user

[Bruno Postle]

On Mon, 27 Dec 2021, 12:47 Jon Schewe, wrote:

>
> When I specify recilinear as the output projection I get a warning from
> Hugin "With a wide field of view, panoramas with rectilinear projection get
> very stretched towards the edges. For a very wide panorama, try
> equirectangular projection instead. You could also try Panini projection.".
>
> Am I correct this warning doesn't apply because what I'm creating is
> technically a "mosaic" instead of a "panorama"?
>

Yes, but with a mosaic the z values of the camera/photo positions can be
closer to the 'canvas' than the panorama viewpoint, in which case the
panorama angle of view can be anything.

>
With a small experiment I managed to get into this state by telling Hugin
> to optimize X, Y, Z only for the images. It ran the optimize and told me
> that the average distance between all control points was zero. At this
> point the project appears to be in an unusable state.
>

Maybe attach a PTO project (no need for the images), it may be obvious what
the problem is.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhYMzrBG2ynRMRgG5f%3DYtQfqioT4jG9GwyhVe1vfJk0%2BA%40mail.gmail.com.

Re: [hugin-ptx] Re: help for new user

[Bruno Postle]

On Mon, 27 Dec 2021, 00:33 Jon Schewe, wrote:

> On Mon, 2021-12-27 at 00:20 +0000, Bruno Postle wrote:
>
>
> For your document assembly project, you will need to use all of these, but
> not all at once - this can confuse the optimiser. I suggest starting with
> translation, then adding position, then view and finally add barrel
>
>
> That helps, let me restate to make sure I understand.
>
> Position refers to how the camera is rotated relative to the paper. So
> assuming the center of the camera is always at the center of each image and
> the distance to the image is the same, this corrects for how the camera may
> have rotated around a point.
>

Yes

View seems like it would be also covered by the position if using the same
> camera for all images. Am I correct?
>

The angle of view is the width of the lens, so a telephoto lens might have
an angle of view of 5°, or a wide-angle lens might have an angle of view of
70°.

>
Translation is how the center of the camera has changed relative to the
> center of the image. Am I correct that x and y are left/right and up/down
> and z is the distance the camera is from the object?
>
> Barrel fixes straight lines being curved.
>

Yes and yes.

I did find that telling Hugin to use separate lenses for each of the 2
> images helps quite a bit.
> I stumbled upon this tutorial that suggested using 2 lenses
> http://hugin.sourceforge.net/tutorials/scans/en.shtml
>

This is a similar case, but you have handheld photos taken with a camera
(generally called a 'mosaic'), so you have to optimise rotation as well as
translation.

Note also that you are assembling your images into a plane, so you need to
set the output projection to rectilinear, not equirectangular.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zjqd_GZx8bFQm69tbiKv6vDYZcSk9ycW7Qxy0GnssNQnA%40mail.gmail.com.

Re: [hugin-ptx] Re: help for new user

[Bruno Postle]

On Sun, 26 Dec 2021, 23:57 Jon Schewe, wrote:

>
> Is there a good reference for what the following terms mean to Hugin?
> Position
> View
> Translation
> Barrel
>

Position is roll, pitch and yaw.
View is the horizontal lens angle of view.
Translation is xyz position of the camera.
Barrel is the radial barrel (or pincushion) distortion of the lens.

For your document assembly project, you will need to use all of these, but
not all at once - this can confuse the optimiser. I suggest starting with
translation, then adding position, then view and finally add barrel.

-- 
Bruno


>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhdrV8mO%3DYoX1B7zjvdzWJBD5rMvzHEnRdv4my4%2BDKoYQ%40mail.gmail.com.

Re: [hugin-ptx] Focus stacking together with panorama assembly

[Bruno Postle]

On Tue, 21 Dec 2021 at 23:40, john wrote:
>
> I will keep trying things.  But from what I've tested so far, that idea 
> doesn't work (Align within stacks and combine each stack before combining the 
> results into a panorama.)
>
> A "similar" layout isn't nearly good enough.  The layout would need to be 
> near pixel perfect and I can't get close.  These are outdoors and the ground 
> gets compressed under the feet of the tripod as you work.  That isn't the 
> only source of error but it is a big enough source.  When you repeat a 
> panorama with a different focus, the alignment is poor.

Hugin should still be able to align these stacks, even if they are a
few degrees off, the sides can be a bit of a mess after enfuse has
merged them, but these sides get discarded when the panorama gets
blended. Another source of problems with focus stacks is that the
angle of view of the lens changes with different focal distances, so
you may need to optimise the angle of view of each layer separately.

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj4fW6W1VtTo59ujJMBTOUicXAgE4g5owz0Cp2rjAY4fg%40mail.gmail.com.