2008.08.19 05:17 "[Tiff] Regarding DICONDE and its Specification", by Harsha

2008.08.25 10:41 "RE: [Tiff] creating sparse files......", by Tillaart, Rob van den

Just thinking out loud,

  1. is it not possible to reuse the intermediate file again in stead recreating one? I imagine that for every stich another part of the intermediate file is used.
  2. is it not possible to do some kind of smart banding or tiling.

One could create one (large?) zero filled tile and let the internal "tile-pointers" in the tiff file all point to this same 'empty' tile. Would give quite some compression without compressing, just bending the rules. If a tile is updated it should be appended of course as other tags still point to the empty tile. The empty tile could also be implemented by a tag indicating the tile as empty so one only needs the size and position.

As said earlier, just thinking out loud :)


Rob van den Tillaart | Researcher | Research & Development | Océ-Technologies B.V.

P.O. Box 101, 5900 MA Venlo | St. Urbanusweg 43, Venlo | Netherlands | Trade register 12002662

T +31 (0)77 359 4076 | F +31 (0)77 359 5337 | I http://www.oce.com

> -----Original Message-----
> From: tiff-bounces@lists.maptools.org
> [mailto:tiff-bounces@lists.maptools.org] On Behalf Of
> jcupitt@gmail.com

2008/8/22 Rogier Wolff <R.E.Wolff@bitwizard.nl>:

I'm stitching kind of large panoramas. This results in big

intermediate files. On my last run, which took overnight to

> stitch, I

> > thought 42 Gb of free disk space would be enough. Wrong!

I was a mentor on a google summer of code project to look at this issue. Sadly the student we selected failed, but this is still an item on the TODO list.

In case anyone is unaware, panotools currently stitches panoramas in three separate stages. First, it analyzes the input images and for each sub-image calculates a transform from the input space to the output space. Next, it resamples each input image to a temporary file, writing zero for 'no value', and also writing a mask file indicating which sections of the transformed image are valid. Finally, the set of transformed images are blended together to make the final panorama using the masks as weighting values, and I think also fixing radiometric differences.

The problem here is that, for large panoramas, these intermediate files are very, very inefficient. If you blend 100 images, you will make 100 intermediates, each as large as the final panorama, and consisting almost entirely of zeros (the GSoC project was to combine the last two stages into one using an image processing library which can handle very large images).

This sparse file for tiff idea is a good one to fix this immediate problem, but it seems to me that it's not an ideal solution. A better short-term fix, as someone said, is to get it to use compressed tiffs for the intermediates. And a proper fix for the problem is to not generate colossal intermediate images in the first place. I would be concerned that a feature is going into libtiff that will need maintaining and testing forever, and which will be unused by anyone, even by the original application, rather soon.

This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.

If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.

Thank you for your co-operation.