align_image_stack command line
Brent
change slightly as follows (before it is incorporated into a release):
- the -c option to set the corner threshold should be replaced with a
'-n' option to specify the number of control points to keep during the
process. Then instead of thresholding the corner points, just the
'n' best ones would be kept. The cornerThreshold is non-intuitive
to users and its choice is dependent on the bitdepth and contrast of
the images.
- if no -o option is specified then there should be no optimization or
output of aligned tiff files rather than defaulting to 'aligned_*'.
There are cases where it would be desirable to create the ptofile and
not the tiff output files. If neither '-p' nor '-o' are specified
then an error message would be printed.
- a value of 0 for the -t option should disable all control point
filtering.
- it is not clear to me why setting the hfov (-f) is important or
useful. The alignment process does not depend on the hfov since it
is assumed that the output is identical to the input without any lens
modifications.
If there is general agreement as to some of these, and there aren't
other programs that depend on some of these options, I can go ahead
and make some or all of these changes.
Brent
Pablo d'Angelo
Brent schrieb:
> I think that the command line options for align_image_stack should be
> change slightly as follows (before it is incorporated into a release):
>
> - the -c option to set the corner threshold should be replaced with a
> '-n' option to specify the number of control points to keep during the
> process. Then instead of thresholding the corner points, just the
> 'n' best ones would be kept. The cornerThreshold is non-intuitive
> to users and its choice is dependent on the bitdepth and contrast of
> the images.
Yes, this was on my todo list. Note that the whole align_image_stack was
basically an one evening project to provide qtpfsgui with a useable
alignment program. The matching algorithm itself only handles smaller
displacements, but I guess that should be ok for most purposes.
Also the naive implementation of the correlation used inside hugin is dead
slow. It should really be replaced by a nicely optimized version (for
example, opencv has a quite fast implementation of cross correlation, it
might be possible to adapt that).
> - if no -o option is specified then there should be no optimization or
> output of aligned tiff files rather than defaulting to 'aligned_*'.
> There are cases where it would be desirable to create the ptofile and
> not the tiff output files. If neither '-p' nor '-o' are specified
> then an error message would be printed.
Good.
> - a value of 0 for the -t option should disable all control point
> filtering.
Good.
> - it is not clear to me why setting the hfov (-f) is important or
> useful. The alignment process does not depend on the hfov since it
> is assumed that the output is identical to the input without any lens
> modifications.
Hmm, I have to think about that, but I guess you are right for normal
perspective images. For other
> If there is general agreement as to some of these, and there aren't
> other programs that depend on some of these options, I can go ahead
> and make some or all of these changes.
qtpfsgui uses align_image_stack, so Giuseppe might also have some ideas or
areas where things could be improved, and what needs to be preserved to
maintain computability with qtpfsgui.
ciao
Pablo
rota.g...@gmail.com
I see that the "-a" option has been removed in the new version (and so
hdr output). I gues it's not a big deal, i'll just modify the way
Qtpfsgui calls align_image_stack.
Apart from that I don't see right now any other critical point that
has to be addressed...
Giuseppe
>
> ciao
> Pablo
Pablo d'Angelo
rota.g...@gmail.com schrieb:
> First off thank you Pablo for restoring align_image_stack.
> I see that the "-a" option has been removed in the new version (and so
> hdr output). I gues it's not a big deal, i'll just modify the way
> Qtpfsgui calls align_image_stack.
ahm, thats a mistake... I accidentally moved an outdated version into the
new trunk... Will fix that now.
ciao
Pablo
Pablo d'Angelo
I noticed that the latest version already has a "number of control points"
flag instead of the corner threshold. :-)
I also added the option to optimize the field of view for the images, this
is useful for focus series.
New usage:
Usage: align_image_stack [options] input files
Valid options are:
Modes of operation:
-p file Output .pto file (useful for debugging, or further refinement)
-a prefix align images, output as prefix_xxxx.tif
-o output merge images to HDR, generate output.hdr),
Modifiers
-v Verbose, print progress messages
-t num Remove all control points with an error higher than num pixels
(default: 3)
-f HFOV approximate horizontal field of view of input images, use if
EXIF info not complete
-m Optimize field of view for all images, execpt for first.
Useful for aligning focus stacks with slightly different
magnification.
-c num number of control points to create between adjectant images
(default: 200)
-h Display help (this text)
ciao
Pablo
Bruno Postle
>
>I also added the option to optimize the field of view for the images, this
>is useful for focus series.
Would it be useful to have some different preset optimisation
strategies: optimising roll, pitch & yaw for HDR stacks;
field-of-view for extended depth-of-field stacks; and field-of-view,
a, b & c for calculating chromatic aberration.
--
Bruno
Brent
Thanks for the quick work on making these changes! Using the -c
option this way is much better.
I was thinking about the comment you added in the code that it
would be better to have some distribution of control points to avoid
too much clustering. One simple way might be to call
createCtrlPoints on subregions of the original images so that each
region gets a fixed number of control points (if there are any
reasonable ones there). Breaking the image into 4x4 subregions
would go a long way to get something distribution of control points.
Otherwise, if some local distribution metric is used during the
thresholding, it is unlikely it would be able to achieve wide area
distribution.
By the way, it seems that the 'g' option in Hugin's control point
display could also benefit from changing from corner threshold to
number of control points, as well as distributing the points.
One other thing, do you see any easy way to have hugin,
align_image_stack, etc. recognize when the input files are linear
(i.e. direct from raw) rather than assuming a default EMoR response?
For example, I'm using align_image_stack with linear files, but then
the HDR output options are of no use since they assume default EMoR
(which, by the way, wouldn't work very well on any files since the
EMoR is untuned in this case). Of course, using ICC profiles for
everything would do the trick, as I've argued in the past, but I agree
that that may be a change that permeates many places.
Note also that it is sometimes hard for users to notice that they are
creating HDR's with incorrect photometric functions since the results
on a monitor always look fairly similar, but in fact end up with poor
HDRs that don't tonemap very well.
Thanks,
Brent
Bruno Postle
I gave this a go and added an option to optimise v, a, b & c, but
all images are given the same 'lens' - So these parameters are
always linked and never get optimised.
i.e. I can't get it to work, but it seems that your new -m option
doesn't do anything either.
--
Bruno
Bruno Postle
fringing described on this page:
http://hugin.sourceforge.net/tutorials/tca/
First attached is a patch to align_image_stack to give it a '-n'
option, this tries to align any stack of images by generating
control points and optimising a, b, c & v lens parameters. I
haven't applied it because I don't really know what I'm doing (did I
mention that already? ;-).
This can be used to align the red, green and blue channels from any
photo that displays transverse chromatic aberration (in principle).
The second attachment is a script that extracts the RGB channels,
runs align_image_stack and reassembles the photos:
$ correct-tca.pl DSC_113*.tif
Here is a 'before and after' photo taken with a Peleng 8mm set at ∞,
notice the green/magenta fringing in the original on the left:
http://www.flickr.com/photo_zoom.gne?id=2110996116&size=o
This isn't a day-to-day tool, creating and sifting 20000 control
points takes around ten minutes here, but luckily align_image_stack
outputs a hugin .pto project which can be processed to extract just
the information needed by 'fulla' (another hugin tool) to correct
TCA quickly for subsequent images.
Pablo's octave script for doing this doesn't work here any more, so
the third attachment is a script that implements the simple
calculation described on the tutorial page. Here's an example of
the calculation from four different photos:
$ pto2fulla.pl DSC_113*.pto
-r -0.001791:0.005649:-0.005582:1.002299 -b -0.003965:0.010388:-0.008476:1.003056
-r -0.002305:0.006149:-0.004932:1.001671 -b -0.003958:0.009540:-0.007013:1.002492
-r -0.001314:0.004119:-0.003886:1.001565 -b -0.004849:0.012491:-0.009690:1.003044
-r -0.004241:0.011709:-0.009849:1.002944 -b -0.002808:0.006092:-0.003752:1.001590
..the output is a series of fulla parameters, notice that they are
all slightly different. One way to get a "good" set of parameters
would be to average all these values, but it is easier to simply
merge all the control points for all the photos into a single
massive project and reoptimise it:
$ grep -h '^c ' DSC_113{6,7,8}.tif-tca.pto >> DSC_1135.tif-tca.pto
$ autooptimiser -n -o optimised.pto DSC_1135.tif-tca.pto
$ pto2fulla.pl optimised.pto
-r -0.002382:0.006819:-0.005968:1.002080 -b -0.003902:0.009637:-0.007217:1.002527
Hope someone finds this useful. Though I'm still not sure where
this stuff belongs - On one hand it would be nice to extend the
hugin lens model to "do" TCA, but on the other hand there are good
technical reasons why it should be done at the RAW conversion stage.
--
Bruno
Gerry Patterson
Thank-you for the scripts. However when I try to open either one of the scripts instead of line endings and '=' signs I see control characters. I might be the only one who is seeing this. If someone else would verify these scripts download correctly, please post a message.
Thanks again,
- Gerry
-r -0.004241:0.011709:-0.009849:1.002944 -b - 0.002808:0.006092:-0.003752:1.001590
..the output is a series of fulla parameters, notice that they are
all slightly different. One way to get a "good" set of parameters
would be to average all these values, but it is easier to simply
merge all the control points for all the photos into a single
massive project and reoptimise it:
$ grep -h '^c ' DSC_113{6,7,8}.tif-tca.pto >> DSC_1135.tif-tca.pto
$ autooptimiser -n -o optimised.pto DSC_1135.tif-tca.pto
$ pto2fulla.pl optimised.pto
-r -0.002382:0.006819:-0.005968:1.002080 -b -0.003902:0.009637:-0.007217:1.002527
Hope someone finds this useful. Though I'm still not sure where
this stuff belongs - On one hand it would be nice to extend the
hugin lens model to "do" TCA, but on the other hand there are good
technical reasons why it should be done at the RAW conversion stage.
--
Bruno
+++ src/tools/align_image_stack.cpp (working copy)
@@ -77,6 +77,8 @@
<< " -f HFOV approximate horizontal field of view of input images, use if EXIF info not complete" << std::endl
<< " -m Optimize field of view for all images, execpt for first." << std::endl
<< " Useful for aligning focus stacks with slightly different magnification." << std::endl
+ << " -n Optimize field of view and lens parameters for all images, except for first." << std::endl
+ << " Useful for aligning RGB channels for tca correction." << std::endl
<< " -c num number of control points to create between adjectant images (default: 200)" << std::endl
<< " -h Display help (this text)" << std::endl
<< std::endl;
@@ -220,12 +222,14 @@
hfov = 0;
pyrLevel = 2;
optHFOV = false;
+ optTCA = false;
}
double cpErrorThreshold;
int nPoints;
double hfov;
bool optHFOV;
+ bool optTCA;
int pyrLevel;
std::string alignedPrefix;
std::string ptoFile;
@@ -288,6 +292,22 @@
lv.setLinked(false);
pano.updateLensVariable(0, lv);
}
+ // unlink all lens parameters?
+ if (param.optTCA) {
+ l = pano.getLens(0);
+ LensVariable lv = map_get(l.variables, "v");
+ LensVariable la = map_get(l.variables, "a");
+ LensVariable lb = map_get(l.variables, "b");
+ LensVariable lc = map_get(l.variables, "c");
+ lv.setLinked(false);
+ la.setLinked(false);
+ lb.setLinked(false);
+ lc.setLinked(false);
+ pano.updateLensVariable(0, lv);
+ pano.updateLensVariable(0, la);
+ pano.updateLensVariable(0, lb);
+ pano.updateLensVariable(0, lc);
+ }
pano.setSrcImage(imgNr, srcImg);
@@ -360,11 +380,20 @@
// optimize yaw, roll, pitch
std::set<std::string> vars;
- vars.insert("y");
- vars.insert("p");
- vars.insert("r");
- if (param.optHFOV) {
+ if (param.optTCA) {
+ vars.insert("a");
+ vars.insert("b");
+ vars.insert("c");
vars.insert("v");
+ } else if (param.optHFOV) {
+ vars.insert("v");
+ vars.insert("y");
+ vars.insert("p");
+ vars.insert("r");
+ } else {
+ vars.insert("y");
+ vars.insert("p");
+ vars.insert("r");
}
optvars.push_back (vars);
}
@@ -450,7 +479,7 @@
int main(int argc, char *argv[])
{
// parse arguments
- const char * optstring = "a:f:hmp:vo:t:c:o:";
+ const char * optstring = "a:f:hmnp:vo:t:c:o:";
int c;
opterr = 0;
@@ -474,6 +503,9 @@
case 'm':
param.optHFOV = true;
break;
+ case 'n':
+ param.optTCA = true;
+ break;
case 't':
param.cpErrorThreshold = atof(optarg);
break;
Bruno Postle
>
>Thank-you for the scripts. However when I try to open either one of the
>scripts instead of line endings and '=' signs I see control characters. I
>might be the only one who is seeing this.
You are right, google has mangled the quoted-printable encoding,
I'll reattach them unquoted.
--
Bruno
rota.g...@gmail.com
here's a quick question: do you have to specify on the commandline the
images ordered by exposure value? If so, is it an ascending or
descending order?
thanks,
Giuseppe
> 3KDownload
>
> correct-tca.pl
> 1KDownload
>
> pto2fulla.pl
> 1KDownload
Bruno Postle
>First attached is a patch to align_image_stack to give it a '-n'
>option, this tries to align any stack of images by generating
>control points and optimising a, b, c & v lens parameters.
After thinking about this a bit more: the patch works fine, but
really the parameters to optimise should be completely configurable.
For some tca cases it is only appropriate to optimise 'v' (e.g. to
determine the tca scaling parameters for dcraw), for others
optimising just 'c & v' is sufficient.
For other uses, optimising 'd & e' or even 'g & t' might be useful,
so a new flag that looks something like this would do it:
align_image_stack -z deg image1.tif image2.tif ...
i.e. "optimise d, e & g'.
..somebody else will have to write this one.
--
Bruno
