2006.05.10 01:28 "Re: [Tiff] TIFF Rotation", by Joris
Well, I've tried to dodge this, but I don't see another option. I need to be able to rotate TIF's by 90, 180, or 270 degrees. Near as I can tell, there's not really any support for this in libtiff, and I don't want to pay the ImageMagick penalty for bi-tonal images. To be honest, performance is not a huge concern, since it will be done rarely at best. But, I can't afford ImageMagick's memory usage. Although I can probably accommodate a single uncompressed directory. So I guess I need to roll my own.
I'm not sure that something like this should be in libtiff "core". Personally, I would prefer a light-weight library for loading tiff images. Perhaps this belongs in another lib/layer that sits on top of libtiff? Is this functionality that you need within the library itself or just some add-on utility that you can use from time to time (eg. option in tiffcp).
I personally agree. LibTiff is a codec, not an imaging library. What is useful, outside of the encoding and decoding functionality, may be added in tools and contribs, but should not polute the core codec. Otherwise, concepts get poluted, and things are out of place and no longer purely modular...
Consider the fact that half of the 8 possible rotations require a buffer. This buffer is essentially an internal memory representation of an image. This, is essentially the core ingrediënt of an imaging library. Such libraries may choose to implement it as tile arrays, and implement particular streaming methods on its input and output sides.
Also consider the fact that in theory any other image file format may have similar rotation encoding support. DIBs, for one, can be top-down, but most are bottom-up, which is 180 degrees rotation plus mirroring. I can't think of many other file formats that have similar property from the top of my head, but the point that any codec *could* require this rotation stands.
Considering this, it is logical that an imaging library layer, and not any codec, deals with rotation.
Note that this is not a purely negative statement, as we're also saying there *is* a proper place for some example/default implementation, in the tool or contrib section. I would personally think a tiffrot.c tool or contrib could be very useful to some. So just make it a seperate module, or, indeed, hook it in tiffcp as an option.
Joris Van Damme
Download your free TIFF tag viewer for windows here: