[hugin-ptx] Using align_image_stack for focus stacking

[dgjohnston]

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?

Don J.

-- 
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/5EA571DA-9821-4F07-8F09-F196800E6C26%40accesscomm.ca.

[hugin-ptx] Control Point Bias

['Michael Perry' via hugin and other free panoramic software]

Is there not a bias in the way Hugin optimises; that control points at the 
intersection of four images will be weighted three more times than those at 
the intersection of the pair of images above or below? The larger error in 
control points always tend to be the furthest from the centre.

Without manually adding control points away from the 4-way intersection (or 
removing those in the centre), is there some way to compensate for this 
with cpfind or autooptimiser?

(Hoping the attached image posts)

-- 
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/ddaa8581-edd2-4a29-b399-60e5e9d9732en%40googlegroups.com.

Re: [hugin-ptx] Re: Default Settings

['Michael Perry' via hugin and other free panoramic software]

Thank you, that works simply and perfectly


On Thursday, 28 April 2022 at 16:30:21 UTC+1 T. Modes wrote:

> michae...@mac.com schrieb am Donnerstag, 28. April 2022 um 12:23:49 UTC+2:
>
>> pto_var: can anyone tell me whether there is a way to specify, for 
>> example, optimising yaw of all images including the anchor without having 
>> to specify each image?
>>
>> Thus, some sort of:
>> --opt=yALL
>> rather than
>>  --opt=y0,y1,y2,y3,y4…
>>
>
> Assuming anchor is first image (image index 0):
> pto_var --opt=y,y0
>
>

-- 
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/bfdfe96c-2b46-467c-848c-d93423634509n%40googlegroups.com.

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

[Klaus Foehl]

On 28.04.22 17:49, Bruno Postle wrote:

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.

No, you are not.

  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);


Hence my suggestion to include more parameters from the Brown-Conrady 
model into hugin. Please. Keep the flawed parameters a and c for 
backwards compatibility.


On why these odd power parameters are mathematically flawed, I've 
written on that in postings long ago. I can revisit the topic if desired.



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.



--
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/fd50b511-1cca-cc03-c740-8f0917fc5db9%40gmail.com.