2002.08.16 12:11 "Re: Orientation field", by Peter Nielsen
Mind you, not supporting the orientation tag is pure laziness. For the writer
As - in most cases - also is writing images bottom-up. That is: lazyness.
Some points to consider:
- If there's not much code involved, why write bottom-up anyway?
Writing any other orientation than top-up (orientation 1) should be avoided at all cost.
- If memory consumption is not an issue, why not flip on/after the source instead of inside the TIFF viewer?
This is the way it should be done. (However, it is fully understandable that this possibly can't be done in small handheld devices with restricted hardware resources).
- a) Because it's a different kind of device with different restrictions.
- But why not at least write as many "strips" as there are "rows", with a "rows per strip" of one and then re-arrange (sort) the strips? (i.e. the offsets of the strips)
This does not help if the image is rotated by 90 degrees. (Which is the common problem with cameras; portrait vs. landscape)
- Where's the problem in batch-converting a bunch of wrongly oriented images right after creation?
There you go! This is what the orientation field REALLY is intended for. It is a place where the device manufacturer can store the orientation in a non- proprietary way. Once the TIFFs are in a place with sufficient recources, the orientation should be corrected, since a baseline tiff viewer is not required to support other rotations than top-up.
Ideally, the software that transfers the pictures from the device should always correct the orientation automatically and create a new file with orientation=1. This step is usually not taken and this is where the lazyness really is...