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?
Andreas_Kleinert@t-online.de | http://www.ar-kleinert.de |
Freelance Consultant & Writer | Software Engineering |
*** PerSuaSiVe SoftWorX *** | x86 Win/Linux, 68k/PPC Amiga and more |