hugin update

[Kai-Uwe Behrmann]

Am 10.11.03, 18:06 +0100 schrieb Pablo d'Angelo:

> I'm using exactly the same transformation routines as panotools. I've
> written my own remapping function with that information, since the pano
> tools version was a bit to slow. (the preview also uses bilinear
> interpolation now, before it just did nearest neighbour, for speed).

Sounds good to me. So I will look in this.

> Hmm, I haven't implemented a method to get the size of a remapped image
> pixel, just for the center of the pixel. so the region of interest (ROI)
> for the remapping might be a few pixels to small at the poles. hmm.

This should be solvable.

> > This, I would like to render individual images as small as possible and
> > merge them later to on multilayerd output file with all offsets as
> > appropriate.
>
> Jep, thats possible and how the preview window works. (actually it still
> uses full screen images, but only remap the ROI.) putting this
> into PTStitcher is probably impossible, so it would require a completely new
> stitcher.

Other than I mentioned on 6.oktober no new stitcheris needed. Instead
telling to render the whole picture area, as today, we only to render the
ROI. This is very simple and enough. To merge the resulting images, is a
thing I can implement in hugin. A additional output option should not
bother ;-)  For very large images I find Your offset idea very amazing,
Pablo.

> > We talked about this some time earlier together with other
> > speed-ups. Such multilayerd tiffs of course as an option.
>
> That would be a nice thing to have. But it should also be possible to do
> this just with the multiple tiff output of pano tools:
>
> for(all pics) {
>    calculate ROI that contains all non black pixels
>    add cropped layer to output tiff
> }
> save output tiff.

Ok I will do a test and compare: rendering of the whole picture and
rendering only the ROI. I expect a difference in speed. If it would speed
things up by a reasonable amount I will implement, otherwise Your above
mentioned solution is more standard and I will take Your suggestion.

> Then gimp/cinepaint needs to be able to read these multilayer tiff. since
> I'm not familar with the tiff libraries, I haven't started writing it
> myself.

Cinepaint does it since one year - they accepted my patch.
For gimp the patch is available. I only need to update for gimp-2.0, but
will wait for the final release and try to bring it in once more.

> speaking of gimp. Is there a plugin that can calculate curves,
> based on two similar regions, like its done by PTStitcher?

Can You explain me what curves? Luminosity, warping ...

best
Kai-Uwe