If you know that the original painting is indeed a parallelogram, and 
hopefully square, then you can create lines on the control points window to 
force Hugin to see Horizontal and Vertical lines. 
https://hugin.sourceforge.io/docs/manual/Hugin_Control_Points_tab.html


On Thursday, August 11, 2022 at 2:35:46 AM UTC-7 [email protected] 
wrote:

> Hi all, so here's a follow up to my investigations;
> I figured out why I had bad matches: I had to revert the last change I 
> made to my scripts, that removed TrZ optimization. Now I understand that 
> the optimizer needs to be able to tweak TrZ to adjust TrZ, FoV and 
> resolution together.
>
> I'm back to good matches, but the trapezoidal distorsion is also back. So 
> far it has never been severe anymore (maybe I've been lucky though), but 
> it's noticeable enough that I prefer manual stitching when it happens :/
> To rule out some slant in scanned images, I took an example of 4 scans 
> that demonstrate the issue when stitched together, rotated all of the 180° 
> (no rescan) and stitched them again that way; 
> And both time I get trapezoidal distorsion with left end taller than right 
> end, so it doesn't follow images content, it seems there's some bias in the 
> stitching process itself:
>
>     http://ks369561.kimsufi.com/~petchema/gfx/I121-19/I121-19.jpg
>     http://ks369561.kimsufi.com/~petchema/gfx/I121-19/I121-19r.jpg
>
> I created a tar with all resources needed to reproduce the problem, if 
> somebody wants to investigate: 
>
>     http://ks369561.kimsufi.com/~petchema/gfx/I121-19/I121-19.tgz
>
> -- 
> Pierre
> Le samedi 6 août 2022 à 11:15:07 UTC+2, Pierre Pierre a écrit :
>
>> Thank you both for suggestions, I wasn't sure how to best measure 
>> shearing, so I scanned a try square multiple times, changing position and 
>> orientation, then used scalar product to calculate angle, and only found a 
>> few thousandth of degree discrepancies, which must be below measurement 
>> errors. If shearing exists, it's probably very small.
>>
>> I added `--set x=0,y=0` to my `pto_var` call, it does seem to have the 
>> intended effect (limit transformations to translations and rotations) 
>> sometimes with visible output artefacts that are probably due to poor 
>> automatic selection of control points. I will see over time how often it'll 
>> require manual optimization, but detecting matching errors seems like an 
>> improvement.
>>
>> -- 
>> Pierre
>>
>>
>>
>> Le vendredi 5 août 2022 à 20:16:22 UTC+2, [email protected] a écrit :
>>
>>> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/e581dec5-d9d8-48f0-abf8-d45e39ff5c9cn%40googlegroups.com.

Reply via email to