Patches: improved vig_optimize diagnostic output

[Dima Kogan]

Hi. I was doing some vignetting-curve optimization, and improved
vig_optimize a bit. I'm attaching 3 patches:

- The diagnostic file that "vig_optimize -w" reports now has a comment
labelling the fields. This is documentation, but it's also a valid
vnlog datafile, so this can be processed with all the various tools:
https://github.com/dkogan/vnlog

- The diagnostic file that "vig_optimize -w" reports now has two extra
fields, indicating the world-coordinate of each pair of measurements.

- The default point count selected by "vig_optimize -p" raised from 200
to 20000

This was done primarily to produce empirical vignetting curves WITH the
residual points included. A python script that does this and sample
output for an arbitrary dataset is included. This is useful as a
quick/dirty validation of the results. It makes it clear that the
default point count of 200 is not nearly enough (there are too few
points to determine the curve with any accuracy). And for this sample
dataset it clearly shows that the resulting curve isn't very accurate
either (here the intrinsics model doesn't fit the actual lens well).

Thanks.

[T. Modes]

Hi Dima,

thanks for your patches

di...@secretsauce.net schrieb am Mittwoch, 29. Juli 2026 um 07:57:35 UTC+2:

Hi. I was doing some vignetting-curve optimization, and improved
vig_optimize a bit. I'm attaching 3 patches:

- The diagnostic file that "vig_optimize -w" reports now has a comment
labelling the fields. This is documentation, but it's also a valid
vnlog datafile, so this can be processed with all the various tools:
https://github.com/dkogan/vnlog

- The diagnostic file that "vig_optimize -w" reports now has two extra
fields, indicating the world-coordinate of each pair of measurements.

This patches can't be applied in current form. You change the output to match your needs, but the patches break reading back the files with vig_optimize -i

This is a no go.

 

- The default point count selected by "vig_optimize -p" raised from 200
to 20000

I'm not sure about this one. Your example is using very small images (640x480 pixel) with a big overlap and linear response.

For estimation of the vignetting a smaller overlap of about 50 % is recommended (see https://wiki.panotools.org/Vig_optimize ).

For real world panorama I have not seen any general problem with this number of samples per overlap. Increasing this default number by *2* order of magnitude increase the calculation time for the photometric optimizer significantly.

So for problematic case you can increase the number on the command line on a per case base.

Otherwise provide real world sample(s) which work only with such a high number of samples, so we can have a look, whats going wrong here.

Thomas

[Dima Kogan]

"'T. Modes' via hugin and other free panoramic software" <hugi...@googlegroups.com> writes:

> This patches can't be applied in current form. You change the output
> to match your needs, but the patches break reading back the files with
> vig_optimize -i This is a no go.

Oh. Yeah. I didn't realize that option exists. Hmmm. We can make -i work
with a different format, but then the old vig_optimize wouldn't be able
to read the new files; do you care?

If the data had field labels (like .vnl files), then the format becomes
more future-proof, which maybe is worth doing. The main reason I wanted
this functionality was to be able to make the residual plots. Do you
care about being able to do that?

At this point I maybe don't care anymore, since I reimplemented all of
vig_optimize to handle its other limitations, and probably I'll use my
tool from now on. Happy to send that to the list, if there's interest.

> - The default point count selected by "vig_optimize -p" raised from 200
> to 20000
>
> I'm not sure about this one. Your example is using very small images
> (640x480 pixel) with a big overlap and linear response. For estimation
> of the vignetting a smaller overlap of about 50 % is recommended (see
> https://wiki.panotools.org/Vig_optimize ). For real world panorama I
> have not seen any general problem with this number of samples per
> overlap. Increasing this default number by *2* order of magnitude
> increase the calculation time for the photometric optimizer
> significantly. So for problematic case you can increase the number on
> the command line on a per case base. Otherwise provide real world
> sample(s) which work only with such a high number of samples, so we
> can have a look, whats going wrong

Hmmm. I didn't think of my use case as being particularly different from
the "normal" case. I guess I wasn't trying to "make a panorama", but
rather to compute the response curve, but the input data should be
mostly similar for both usages.

I was seeing the computed response curve jump around a LOT with every
run of vig_optimize, and adding more points stabilized it dramatically.
Plotting the residuals showed why that was: the curve was being computed
off a very small number of points. And on my 10-year-old laptop it
solves the "-p 20000" problem in a few seconds. I can easily imagine
that this all changes for higher-res images. Ideally the tool would do
the right thing for both high-res and low-res images, but it's not
clearly worth the time.

OK. Thanks for replying. Let me know if you want a patch to make -i read
the -w files or if you want to see the new tool.