| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2008.08.25 10:41 "Re: creating sparse files......", by Rob Van Den TillaartJust 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 :) regards, rob, 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 > Sent: maandag 25 augustus 2008 11:37 > Cc: tiff@lists.maptools.org > Subject: Re: [Tiff] creating sparse files...... > > 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. > > John > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/ > > 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. |
|||||||