fulla implicitely cropping output

Bug #679988 reported by mayne on 2010-09-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Run fulla to fix some radial barrel distortion with cropping disabled.
$ fulla -s -g 0:-0.2:0:1 -o output.jpg input.jpg

Expected: A corrected image on an enlarged canvas.
Actual result: A corrected image cropped to the original canvas size.

rew (r-e-wolff) on 2010-12-02
Changed in hugin:
importance: Undecided → Wishlist
status: New → Triaged


this has been re-submitted recently against 2014.0.0 in <http://bugs.debian.org/779003>, fulla ignores the -s option.

ametzler@argenau:/tmp$ fulla -s -g -0.004318:0.039896:-0.096925:1 -o a.jpeg P1040118.JPG
    correcting image: : |

ametzler@argenau:/tmp$ fulla -g -0.004318:0.039896:-0.096925:1 -o b.jpeg P1040118.JPG
    correcting image: : |

ametzler@argenau:/tmp$ md5sum a.jpeg b.jpeg
2e3b30e1ec1359181ffdef09c8a9477b a.jpeg
2e3b30e1ec1359181ffdef09c8a9477b b.jpeg

FWIW, imho ignoring a documented option is not wishlist.

cu Andreas

tmodes (tmodes) wrote :

The switch -s works, but not as the thread opened is wishing.

fulla -s -g -0.004318:0.039896:-0.096925:1.061347 -o a.tif input.tif
Saving a.tif
fulla -g -0.004318:0.039896:-0.096925:1.061347 -o b.tif input.tif
Saving b.tif
md5sum a.tif b.tif
492bc5efef088c6a213b8222f8055026 a.tif
31e68917a31fd77875e20011457ecfb3 b.tif

The problem with your example is probably the d parameter.
With d=1-a-b-c no scaling happens. But your d value is different, so you request an additional scaling. With the additional scaling the corrected image remains inside the initial image rectangle and there is no need for an additional rescaling. So the output of fulla with and without is the same.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.