Thread

2002.08.16 07:23 "Re: Orientation field", by Andreas R. Kleinert

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?
a) Because the corresponding device does it this way.
If so: why does it *and* why should this image be destined for display by an image viewer then, in the first place?
Examples: Scanners. But you always could flip the original, before scanning.
b) Because the used frame-buffer is organized this way.
If so: if it's a random-access memory, a bit of arithmetics (basically the same as for a flip-operation but without the need for extra memory) will help.
Examples: a bottom-up frame buffer memory (simply read from 'native' bottom-right to upper-left and flip it this way)
If memory consumption is not an issue, why not flip on/after the source instead of inside the TIFF viewer?
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)
b) Because those TIFFs can be upto 4 GB (etc.)
Well, too large for PCs, either. See a)
Where's the problem in batch-converting a bunch of wrongly oriented images right after creation?