flat mosaic stitching (scans etc) and field of view

[torger]

I have troubles stitching flat stuff shot piece by piece in a copy
stand.

The transparencies or prints are shot typically in four parts with a
macro lens perpendicular to a light box. This seems like it would be a
straight-forward flat mosaic stitch.

But I don't get it - Hugin optimizes width lots of yaw and pitch -
despite it was shot flat, and uses the field of view which should be
irrelevant for a flat mosaic? The end result is often distorted and
with multipixel distance error between control points, since there is
put in much yaw and pitch in the optimization.

Anyway, I have found out a method that often gives a good result. The
macro lens I use is 150mm, but if I lie to Huign and say it is 1000 mm
instead so I get a very narrow field of view, and thus very little
perspective in terms of yaw and pitch, the optimization goes much
better, with very small distance errors, less than a pixel, as it
should be.

But is this really how mosaic flat stitching should work? Any ideas?

[Terry Duell]

On Mon, 30 Jan 2012 11:01:57 +1100, torger <tor...@ludd.ltu.se> wrote:

>
> But is this really how mosaic flat stitching should work? Any ideas?

Have you had a look at the hugin tutorial "stitching flat scanned images"?
<http://hugin.sourceforge.net/tutorials/scans/en.shtml>.
It might help.

Cheers,
--
Regards,
Terry Duell

[torger]

Yes I have looked at that. They use a dummy fov and just skip yaw/
pitch optimization. I don't get any good fit then. I think the problem/
difference here is that I'm not using a flatbed scanner but have a
real lens, that is there is not zero distortion. It may actually also
be some very small yaw and pitch since it might not be 100% exactly
perpendicular. So probably there should actually be some small yaw and
pitch to get the best fit.

So perhaps I'm doing this right for this case? By telling Hugin that I
have a very small field of view I tell it that it should only use
small yaw/pitch corrections, and it does get a good fit then. If I
specify I wide field of view, I get poor match. Since it is a macro
lens used at macro distance I guess the field of view may be a bit
tricky and not really match the focal length?

And another question, which projection should I use to get area-
correct result (not stretching or bending etc)? Some tutorials say
equirectangular, others indicate rectilinear. My guess is
equrectangular...

[kfj]

On 30 Jan., 08:45, torger <tor...@ludd.ltu.se> wrote:
> Yes I have looked at that. They use a dummy fov and just skip yaw/
> pitch optimization. I don't get any good fit then. I think the problem/
> difference here is that I'm not using a flatbed scanner but have a
> real lens, that is there is not zero distortion. It may actually also
> be some very small yaw and pitch since it might not be 100% exactly
> perpendicular. So probably there should actually be some small yaw and
> pitch to get the best fit.

Reading your posting, I have the impression your camera is mounted to
a repro stand (I hope that's the right english word...).

First calibrate your lens and setup. Find a subject which is rich in
non-repetitive detail (best would be photos of detail- and contrast-
rich natural subjects). Use your repro process on it - a few
additional images won't do any harm. Use the correct fov. Input
projection rectilinear, output projection rectilinear. Generate lots
of CPs, try cpfind with

--fullscale --sieve2size 5 -o %o %s

in the settings. Now optimize for x,y in all but the anchor and a,b,c
in all images. Note that you don't optimize for z, since with your
setup z is fixed. This should already deliver a reasonable result, but
in case you want to adjust to minimal errors in your setup you can
proceed to try this:

Optimize for y, p and r only if you're not happy with the result as it
is. If you used a repro stand, all y, p and r values should be quite
close, and you can just average over the lot and use the average
values for all images in the future.

If you didn't use a repro stand for the images, you will definitely
need to optimize for z, y, p and r and you're entering tricky
territory, since the optimizer now has to deal with (often too) many
degrees of freedom. Your mileage will vary, and the procedure for this
situation usually involves optimizing only a few variables at a time
and doing several iterations. Best to be avoided, laborious and not
repeatable, and you may have to add line control points to get
anywhere.

Once you've gone through the calibration process, you have

- lens calibration data which you can save in a lens.ini file to use
for future projects with this lens
- possibly y, p and r values for your mount which you can also reuse
if the mount is unchanged

You may want to correct for lens shift as well, but it's tricky doing
that with x and y being optimized at the same time - nevertheless you
may want to experiment with the lens shift parameters. You might try
and switch off x and y in the optimization when you optimize for d and
e, and vice versa. If you alternate between the two for a few
iterations, you may arrive at a reasonable result.

For future stitches with your repro setup, you can now simply load the
lens correction data from your saved lens.ini file, set y, p and r,
and only optimze for x and y only

So, once again in a nutshell

- use a repro stand if you can
- calibrate your lens
- optimze y, p and r only if you must.

Kay

[Carlos Eduardo G. Carvalho (Cartola)]

I hope you are trying to put the camera in the same relative position to do each shot, but maybe if you think it is not too precise it could be an idea to set different lenses for each image, so hugin can optimize them separately. I would do that after calibrating the lens, as suggested. I would also try to do the optimization little by little, starting with few items, maybe y, p, r only and then going through other parameters.

If you get desperate you can try to make your images available (maybe resized) so we can try to make it.

Good luck,

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/1/30 kfj <_k...@yahoo.com>

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[torger]

Thanks for the elaborate and helpful replies.

I actually don't use a repro stand but use a very sturdy setup,
probably more sturdy than many repro stands. However, as sturdy as it
is perfect perpendicularity cannot be guaranteed here, and to some
extent it is not desired. I shoot medium format transparencies at 1:1
macro distance, meaning I have about ~0.5mm depth of field. Film
curvature and possibly lens curvature leads to that minor adjustments
for optimal focus (using a precise leveling head and focus rail) is
necessary when the film has been moved to shoot the next part of it.
Small Z/yaw/pitch differences is thus introduced there. I need to move
around a flat hard plastic card on the film to reduce curvature of the
part to be shot (it is mounted on a cardboard frame to provide some
air from the lightbox glass to avoid newton rings), so that can
disturb the system a bit too, but gives the best quality (sharpest)
for the individual images.

When moving around I don't care much to avoid rolling, thinking that
the optimizer would be able to handle that. To avoid rolling I'd have
to invest in a high quality coordinate table. Keeping everything
within the 0.5mm DoF when moving stuff around to shoot the different
parts would require very high precision in the system, so my idea here
is to just be able to shoot every frame with high quality (which I can
with this relatively simple setup, just readjust and verify focus all
over the frame in 10x live view), and then let Hugin solve the fitting
problem. I do provide horizontal lines as lead for roll optimization.

Lens correction I do in advance by developing RAWs to 16 bit tiffs in
RAW therapee with distortion and CA correction.

I tried to use the obvious method first, as Kay described, only
optimize the parameters that should need to be optimized (X/Y/roll),
but the adjustments after moving stuff leads to precision errors that
do require some yaw/pitch.

Then my idea was to optimize X/Y/roll first and then add final yaw
pitch optimization after that, but poor result, and very much
dependent on FoV.

To get the optimizer do make a good fit in this type of stitching it
seems like trial-and-error with small FoVs is the best method. What
surprised me was that the optimizer by its own does not seem to be
able to figure out that to get a good subpixel fit (which is possible
- I have succeeded after messing around a lot) the major adjustments
are in roll/X/Y and only very small adjustments of yaw/pitch is
required, and that provided starting FoV have such a big impact on the
result.

One thing though, perhaps I'm disturbing the optimization process by
using manual CPs. I'm a perfectionist and as such I almost always use
manual CPs for my stitches, since for all the time I've used Hugin for
normal stitching (that is shooting landscape panoramas from a panorama
head) I usually get better results then, I place them in strategic
positions etc, and almost always get subpixel precision in my
stitches. But there are then only about 4 points per image, widely
spaced though. It seems like a lot have happened in auto CP finding
since I made the decision to always do manual CPs though, so perhaps
there's a reason to try auto again...

[torger]

Oh, I'd like to brag and say I'm a quite advanced Hugin user :-). I
have followed the development and used it for several years, can do
very good quality stitches and have a good feel of the optimizer,
doing custom parameters in order etc when needed. So I have a decent
understanding of how the things work and challenges the optimizer have
to deal with and how one can help it out. However I use pano heads
normally, and this thing with repro shooting and doing mosaics is new
to me so it is a learning experience.

Should the output projection really be rectilinear? Not
equirectangular? The difference is very small when the fov is small,
but it would be nice to know what is "correct", that is assuming a
perfect system with perfect perpendicularity etc which output
projection would produce the same image as if shot by a single
rectilinear lens that covered the whole area. Umm... when I say it
like that it seems like rectilinear would be the correct projection.

[torger]

Sorry for spamming... just came to think about FoV. Macro lenses are a
bit special, fov doesn't match focal length at near limit. My 150mm
macro lens from the focal length says "13.69 degrees fov". But at 1:1
distance is 380mm so the fov would then be 2 * arctan(36/2 / 380) =
5.42 degrees, that is about the same as a 380mm lens. Anyway, I'll do
some more experiments and report about the results.

[Carlos Eduardo G. Carvalho (Cartola)]

Well, I did mosaic maybe only a couple of times, but I didn't remember having difficulties. I wouldn't do lens correction before hugin and I wouldn't think of doing so much precise controls. Maybe with macro they are more important, but I really don't know. Manual CP are surely not a problem, just make sure you use at least 3 between each pair. Many times I use only 3 (but to do spheric panoramas). Can't you give us an example image set? Could be reduced size jpg preferably without any previous processing, like that lens correction you mentioned.

Is FoV so much important? Many times I just put a reasonable value and let the optimizer correct this. More important is to guarantee that it won't think it is a 360º panorama, so I would think any kick to guarantee that the total FoV is not going to get to 360 would be a good start, but again, "guessing" here looks to me like a little loose of time if compared to see your images to address the real problem.

Cheers,

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/1/30 torger <tor...@ludd.ltu.se>

[torger]

I appriciate the helpfullness, but unfortunately I cannot share the
images since the originals are not mine.

However, I worked this evening with this on a few images and tested
several methods and have great help of your input. I get good results
now (often subpixel fits), and consistent enough.

The interesting fact is that setting a 1 - 2 degrees FOV is required
for the best results. I've tried to let Hugin optimize it by itself
but it rarely goes down to those low values, even when starting with
the calculated 5.42 degrees. The fit often gets kind of ok with that
5.42 starting point, but not as good as it can get. I suspect that
this is a special case occuring for this type of repro setup when
there are just minor but still some yaw/pitch errors. Almost perfect
perpendicular, but not 100% as a flatbed scanner, and not as large as
hand held mosaics of walls. Seems to fall outside normal optimization
space.

I've also tested auto control points, and it works kind of ok, but
there's always some outliers so I think I continue do them manually,
having relatively few points and well-defined places gives me a better
overview of stitching result I think, but I guess it is a matter of
taste.

I normally don't pre-correct lens distortion, since Hugin indeed does
better fitting result if it can correct barrel etc itself, but in this
special case the optimizer easily goes haywire so having close to
perfect rectilinear input seems to work better. I've also tried to pre-
correct roll, but it is not really worth it, that correction works
well.

This is the hugin workflow that gives me consistent results so far for
this application:

* Create new project
* Open the 16 bit tiff images (usually four)
* Don't use the field of view from EXIF, instead pre-set to 1 degree.
* Make control points to connect all images
* Make horizontal (and possibly also vertical) guides on all images
* You should have included film edge on all your frames and that is
what you use as guide
* Now the exciting part - the optimizer tab
* First correct X and Y for all but one
* Then add roll to all and optimize again
* Theoretically this would yield perfect result already here,
but as
said the repro setup is rarely that perfect
* Then add Z for all but one and yaw and pitch for all, and
optimize
again
* Then open up GL preview, goto move/drag and select drag
mode "mosaic", and then drag the image into the center of the
view,
close and optimize again
* Typically the optimizer has put the image far from center,
and
moving it back into the middle again and reoptimizing can
give
better result.
* You can try to add lens view as a final parameter but that
usually
does not improve things.
* Open up GL preview
* Choose rectilinear projection
* Mosaic-drag so the center is in the center of the image
* Fit/autocrop the view
* Stitch to 16 bit tiff output, for further processing in your
favourite raw converter or photo editor

On Jan 30, 7:08 pm, "Carlos Eduardo G. Carvalho (Cartola)"

<cartol...@gmail.com> wrote:
> Well, I did mosaic maybe only a couple of times, but I didn't remember
> having difficulties. I wouldn't do lens correction before hugin and I
> wouldn't think of doing so much precise controls. Maybe with macro they are
> more important, but I really don't know. Manual CP are surely not a
> problem, just make sure you use at least 3 between each pair. Many times I
> use only 3 (but to do spheric panoramas). Can't you give us an example
> image set? Could be reduced size jpg preferably without any previous
> processing, like that lens correction you mentioned.
>
> Is FoV so much important? Many times I just put a reasonable value and let
> the optimizer correct this. More important is to guarantee that it won't
> think it is a 360º panorama, so I would think any kick to guarantee that
> the total FoV is not going to get to 360 would be a good start, but again,
> "guessing" here looks to me like a little loose of time if compared to see
> your images to address the real problem.
>
> Cheers,
>

> Carlos E G Carvalho (Cartola)http://cartola.org/360

[Carlos Eduardo G. Carvalho (Cartola)]

Thanks for sharing your final recipe!

About manual CPs, you probably already do them well, but a good tip is to put them away from each other not letting any big part of the joining parts without any. As I said, I sometimes do only 3 between each pair and they are put one at the top, one at the middle and the last at the bottom of the image, whenever this is possible.

Cheers,

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/1/30 torger <tor...@ludd.ltu.se>

I appriciate the helpfullness, but unfortunately I cannot share the

[kfj]

On 30 Jan., 20:44, torger <tor...@ludd.ltu.se> wrote:

> However, I worked this evening with this on a few images and tested
> several methods and have great help of your input. I get good results
> now (often subpixel fits), and consistent enough.

Nice to hear you've figured out a work flow which works for you :)

> The interesting fact is that setting a 1 - 2 degrees FOV is required
> for the best results. I've tried to let Hugin optimize it by itself
> but it rarely goes down to those low values, even when starting with
> the calculated 5.42 degrees.

Hugin can only come up with a correct fov value if you do a full
spherical panorama. It certainly can't even come near to a correct
value if you only give it a few CPs. If you want to calculate an
estimate for your lens' fov, you can derive it from the distance of
your NPP to the object.

It might well be that with the specialized optics you use, treating
the incoming images as rectilinear isn't the best solution, even
though it is the obvious one. I had similar issues stitching satellite
images, and I also resorted to using artificial small fov values. But
you might try and use a different input projection.

> I've also tested auto control points, and it works kind of ok, but
> there's always some outliers so I think I continue do them manually,
> having relatively few points and well-defined places gives me a better
> overview of stitching result I think, but I guess it is a matter of
> taste.

The outliers aren't a problem. The optimizer is quite intelligent and
figures out which CPs are outliers, and they won't spoil your
registration, even if they show up on the preview as red and give you
a high average cp distance. And if you generate a generous amount of
CPs in the first place (like, with the CPG setting I have proposed
earlier), there's nothing stopping you from subsequently throwing the
worst ones of them away, using the 'clean control points' button or
doing it by a distance threshold.

Having many CPs allows you to calculate lens distortion coefficients,
which are essential. And you might surprise yourself by just how
accurate a fit you can get from a field of, say, 100 automatically
generated CPs per pair. cpfind is really very good, give it a shot.

> I normally don't pre-correct lens distortion, since Hugin indeed does
> better fitting result if it can correct barrel etc itself, but in this
> special case the optimizer easily goes haywire so having close to
> perfect rectilinear input seems to work better. I've also tried to pre-
> correct roll, but it is not really worth it, that correction works
> well.

The optimizer tends to go haywire if it doesn't have enough CPs. The
more degrees of freedom you give it, the more CPs you need to keep it
on a sane path.

Kay

[paul womack]

torger wrote:

>
> Lens correction I do in advance by developing RAWs to 16 bit tiffs in
> RAW therapee with distortion and CA correction.

I think you should allow Hugin to do as much of the correction
as possible, since Hugin rolls up all the corrections
and mappings into a single step resampling process.

This provides higher quality than successive resampling
processes.

BugBear

[Dane]

I would think that mosaic field of view would be: (lens field of view
at distance used)*(width of each image/width of mosaic image)
This would be closer to your 1-2 degree.

[torger]

I forgot the nodal point in my fov calculation...

I agree that it is best to let Hugin do as much correction as
possible, I will probably move barrel correction to hugin. But anyway,
I've done further experiments with more images and I'm not really
pleased with the stability afterall, too often there's too much of a
hassle to get a decent result. I tested a number of different
workflows, both mostly automatic and mostly manual.

Researching more into the business of flat stitches I realize that
Hugin is probably the wrong software to use, it lacks the necessary
features. The stitching problem that I need solved here is more
similar to stitching maps from aerial photography, where you do static
lens correction then X/Y/roll and then rubber sheeting to fix final
minor matching issues.

I tried a commercial software, PanoVue, which has a specific mosaic
mode, where you pre-specify number of rows and columns, then get only
four control points per image, and it is rubber-sheeted together and
merged with wide blends. Simplistic approach but for this specific
application it works much better. It would be nice with an application
that can rubber-sheet with many more control points to get subpixel
matches over the whole area and then use narrow seams, haven't found
one though.

Without rubber sheeting or corresponding non-linear stretching it
seems hard to solve this problem well.

What I would need in Hugin would be to do lens/X/Y/roll correction
normally which leaves a smaller but significant residual error and
then have a button "stretch-to-match" which would rubber-sheet control
points to exact match. Nona would have to support rubber-sheeting then
of course...

I've also noted that enblend's seams on film-grained sky don't get
invisible (due to grain disturbance) unless there's a sub-pixel match,
which means that you really can't get away with anything else than a
perfect match over the whole area.

[torger]

On Jan 31, 11:34 am, kfj <_...@yahoo.com> wrote:
> Having many CPs allows you to calculate lens distortion coefficients,
> which are essential. And you might surprise yourself by just how
> accurate a fit you can get from a field of, say, 100 automatically
> generated CPs per pair. cpfind is really very good, give it a shot.

I've tried it and it works ok, although film grain can confuse it a
bit.

I have no problems with Hugin when doing normal panorama work using my
panorama head, the stuff Hugin is designed for. This application
introduces non-linear issues though, possibly micro-variations in film
curl etc, the micro-metric scale makes it hard to provide "error-free"
input, and on top of that the grainy structure makes seams in slightly
mismatching low contrast areas visible.

As said in the previous post, I now think it is hard to solve this
problem without having a rubber-sheeting or similar non-linear
correction model to handle residual errors. A software designed for
stitching aerial photographs for maps may be the thing, still
searching for something suitable and that works on a tight budget
though.

The trick I did with yaw/pitch corrections and small FOV was just a
"hack" to deal with residual errors the yaw/pitch that the optimizer
finds is not real, but sometimes it works and improves matching
without bad side effects. At first I thought it almost always worked,
but now after more testing I've been forced to change my mind.

[kfj]

On 1 Feb., 15:25, torger <tor...@ludd.ltu.se> wrote:
> I forgot the nodal point in my fov calculation...

> Researching more into the business of flat stitches I realize that
> Hugin is probably the wrong software to use, it lacks the necessary
> features. The stitching problem that I need solved here is more
> similar to stitching maps from aerial photography, where you do static
> lens correction then X/Y/roll and then rubber sheeting to fix final
> minor matching issues.

I think Hugin's standard slave programs don't support 'rubber
sheeting', but PT has the feature - it's just not exploited by the
FOSS replacements hugin uses. If I'm not mistaken, the feature is
named morph-to-fit or so in the original panotools, and there may even
be software floating about doing it and honouring 'C' lines, but I've
never played with that. Anybody out there who knows about this?

Kay

[Bruno Postle]

On Wed 01-Feb-2012 at 07:34 -0800, kfj wrote:
>
> I think Hugin's standard slave programs don't support 'rubber
> sheeting', but PT has the feature - it's just not exploited by the
> FOSS replacements hugin uses. If I'm not mistaken, the feature is
> named morph-to-fit or so in the original panotools, and there may even
> be software floating about doing it and honouring 'C' lines, but I've
> never played with that.

I think PTmender in libpano13 respects the morph-to-fit parameters,
though PTmender doesn't support any of the Hugin photometric
features.

morph-to-fit works by dividing the photo into triangles based on the
control point positions and then distorting the triangles so the
points align in each overlapping photos.

I'm fairly sure that the reason it was never implemented in nona was
that this isn't a very elegant way of solving the problem. So what
often gets suggested as the 'right' way to do this is to use the
control points to distort a spline patch that covers the whole
photo.

--
Bruno

[torger]

A spline-based morph-to-fit would be really cool. I don't think many
stitchers have that feature. It seems like some high end cartography
software have it, but not many of the common panorama stitchers.

Stitching in this case is not really bad, with X/Y/roll/barrel one
gets down to a residual error of say 3-4 pixels. With a rectangular
film frame and grainy structure small errors in shape and overlaps
become more evident than in normal landscape panorama stitching
though.

If spline-based morph-to-fit / rubber sheeting would make it possible
to reduce smaller residual errors to near zero around the seams it
would be great. At the current maturity level of stitchers I think it
is more valuable with a feature that allows to go from "fair to
perfect" than from "poor to fair".

[kfj]

On 1 Feb., 22:08, Bruno Postle <br...@postle.net> wrote:

> I'm fairly sure that the reason it was never implemented in nona was
> that this isn't a very elegant way of solving the problem. So what
> often gets suggested as the 'right' way to do this is to use the
> control points to distort a spline patch that covers the whole
> photo.

I wouldn't be so sure about the reasons for the omission from nona.
I've been doing more digging into libpano code recently, and it's hard
going:

- there is no real documentation
- the few comments state the obvious or name the person who's made a
change
- the interface is terribly 'C' and procedureal - it's like having to
fill a complicated form and send it off to some mysterious black box
mechanism which is guaranteed to deliver a result if the form was
filled out correctly...

And nona does not implement other things which should be easy to have
at little cost - the first thing springs to mind is CA correction - if
the image gets warped anyway one might as well warp the colour
channels differently (they're warped seperately anyway) - instead of
using yet another program, fulla, for the purpose; introducing yet
another interpolator run on the data does not help, nevermind the
interpolators are good. (Please correct me if I'm mistaken and nona
has this feature now - nona isn't precisely well-documented either)

On 2 Feb., 09:04, torger <tor...@ludd.ltu.se> wrote:
> A spline-based morph-to-fit would be really cool. I don't think many
> stitchers have that feature. It seems like some high end cartography
> software have it, but not many of the common panorama stitchers.

as you mention it, yes, it's a common thing in cartography, and in
fact I found that there are many common points between cartography and
panoramic imaging. The cool thing is that there is high-powered
geography software which is FOSS. Look, for example at

http://www.gdal.org/

Cartographers deal with mathematical models of the strangely shaped
object we inhabit which are far more complex than our simple
panosphere, yet compared to the degree of mathematical involvedness
I've seen in astrophysics they are straightforward and obvious. Now
take the next step and realize gdal has python bindings, and so does
hugin. Nothing stopping one to use gdal algorithms on hugin data.

> Stitching in this case is not really bad, with X/Y/roll/barrel one
> gets down to a residual error of say 3-4 pixels. With a rectangular
> film frame and grainy structure small errors in shape and overlaps
> become more evident than in normal landscape panorama stitching
> though.

Did you ever doublecheck if the film grain, seen from different
angles, might not introduce parallactic differences between the images
you're trying to match? After all if you're talking of resolution at
the film grain level, the film's thickness and the position of the
pigment particles therein becomes a 3D thing. And with very linited
DOF you might even cut a different optical slice (hope that's the
correct term) from the film. You might be asking too much from a
method that deals with 2D data.

> If spline-based morph-to-fit / rubber sheeting would make it possible
> to reduce smaller residual errors to near zero around the seams it
> would be great. At the current maturity level of stitchers I think it
> is more valuable with a feature that allows to go from "fair to
> perfect" than from "poor to fair".

I'm all for having tools which may do the trick in a situation, never
mind they aren't necessarily general.

Kay

[torger]

> Did you ever doublecheck if the film grain, seen from different
> angles, might not introduce parallactic differences between the images
> you're trying to match? After all if you're talking of resolution at
> the film grain level, the film's thickness and the position of the
> pigment particles therein becomes a 3D thing. And with very linited
> DOF you might even cut a different optical slice (hope that's the
> correct term) from the film. You might be asking too much from a
> method that deals with 2D data.

The sampling using a 5Dmk2 at 1:1 macro is about 3900 ppi, with some
lens/aa-filter/diffraction/demosaicing loss about 3600 ppi effective.
It is enough to show grain, but not really to sample them fully. The
DOF at f/8 at this resolution is about 0.4-0.6 mm so it is thin but
thicker than the film. It is a challenge to keep the film flat enough
to keep it within the DOF, but it is doable. It is coarse enough
sampling so I don't think "grain parallax" is an issue. I may still be
asking too much though :-)

[torger]

gdalwarp commandline tool seems to do some of that spline deformation.

I also found this interesting paper on stitching with perfect matching
through deformation:

http://www.cse.cuhk.edu.hk/~leojia/all_final_papers/img_stitching_pami08.pdf

[Bruno Postle]

On Thu 02-Feb-2012 at 02:03 -0800, kfj wrote:
>
> And nona does not implement other things which should be easy to
> have at little cost - the first thing springs to mind is CA
> correction - if the image gets warped anyway one might as well
> warp the colour channels differently (they're warped seperately
> anyway) - instead of using yet another program, fulla, for the
> purpose;

fulla was never intended to be used in a stitching workflow, it was
a replacement for the clens tool, which itself was an open source
alternative to ptlens.

> introducing yet another interpolator run on the data does not help,
> nevermind the interpolators are good. (Please correct me if I'm
> mistaken and nona has this feature now - nona isn't precisely
> well-documented either)

nona needs tCA correction, this is unfinished business, but somebody
needs to write the code. All the hard work was done when fulla and
tca_correct were developed, it just needs to be integrated.

--
Bruno