LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 2006
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2006.06.12 15:09 "Re: Editing a tiff image using libtiff", by Joris Van Damme
Sachin, Sachin Garg wrote: > Appending is a good option, but will waste space and it does changes > the order of blocks/tags. > > My assumption here is that users might expect that a program doing > minor edits will not restructure the entire file. (Imagine a huge tiff > image where someone has saved the tiles in an order which minimize > seeking etc... like in pyramidal tiffs.) I could be wrong in assuming > that people might be structuring tiff images as per their > requirements, I myself haven't worked on such applications. > > To maintain the order, I am just a bit overwhelmed by the complexity > of having to update offsets of the all tags/values after the changed > tile. Is it actually hard or is it just me? It will be really great if > this can be possible using libtiff. You are correct about the space waste. That's the trade-off. Either you rewrite a complete file, or you sacrifice space in the existing file. There is no work-around. This is not a 'bad thing', really, in the sense that rewriting a file is still an option, and is the only option with many other file formats. You can view sacrificing some space as an 'extra option'. OT: Things could have been different if TIFF had a memory-manager scheme in it. Additional data on the blocks, used and unused, would then allow a codec to do memory management, i.e. present an API where you can 'allocate' a certain sized block in the file, and 'de-allocate' it as well. Of course, that would be seriously complicated all by itself, but it would also complicate other matters too as you would have to know the size of each required block beforehand and had to buffer complete compressed tiles/strips all the time, instead of just streaming them out to the end of the file as compression progresses, or either compress them first to get a compressed size only, and next a second time to stream them out... Anyway, that's off-topic, there is no such thing as memory-manager supporting data in TIFF. While the wasted space is an issue, in my opinion you are wrong to worry about 'restructuring' the file. There is no such thing as an order in TIFF, every block can be located anywhere in the file, and any codec needs to do random access in the file. There may be one or two quick hack decoders that impose restrictions in this field, like there are one or two quick hack decoders that only read 24bit/pixel RGB data from a TIFF file... it's a huge internet after all. But there are no such restrictions in any main-stream codec, including LibTiff. After all, even the order in which the data is needed may vary from codec to codec and application to application... Some applications may want to investigate first IFD and decode image data immediatelly after that. Some others may want to investigate first IFD, next take a look at the first IFD's SubIFDs, and only next decode image data of smallest variation inside that first IFD and its SubIFDs. Some others may insist on building a complete page overview before doing any image decoding at all. Even in the investigation of a single IFD, some codecs/apps may wish to read every single tag value, others might ignore some tag values until the time they actually need it and thus turn the order of reading around, etc etc... There is no such thing as a 'good' order of data blocks in TIFF. Your concern about minimizing seeking needs may be more legit. Though, if tile/strip sizes aren't too small, the seeking needed in decoding an image is probably negligable compared to the total needs of IO and decoding. The negligable part that remains, you'll have to view as part of the trade-off: if it's objectional, consider rewriting the complete file instead of updating a single tile/strip. > To maintain the order, I am just a bit overwhelmed by the complexity > of having to update offsets of the all tags/values after the changed > tile. Is it actually hard or is it just me? If you remain set on that goal, you may find it is indeed a bit of work. > It will be really great if > this can be possible using libtiff. I'm not the most experienced LibTiff user, but post specific questions if you get stuck and I'm sure someone here is able to help. Also remember to look at the tools and contribs, there's loads of LibTiff using code there, some of which shows how to copy IFDs and such with LibTiff. If you decide to forget the 'data block order' issue, as is intended in TIFF design, you may find it is likely easy to write a single tile/strip. You'll likely need to focus on TIFFWriteEncodedXxx and work from there. But again, I'm not the most experienced LibTiff user, don't take my word on any matter other then pure file format issues. Best regards, Joris Van Damme info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html