2002.08.15 00:33 "Orientation field", by Dante Allegria

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:

  1. If there's not much code involved, why write bottom-up anyway?
  2. a) Because the corresponding device does it this way.
  3. If so: why does it *and* why should this image be destined for display by an image viewer then, in the first place?
  4. Examples: Scanners. But you always could flip the original, before scanning.
  5. b) Because the used frame-buffer is organized this way.
  6. 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.
  7. Examples: a bottom-up frame buffer memory (simply read from 'native' bottom-right to upper-left and flip it this way)
  8. If memory consumption is not an issue, why not flip on/after the source instead of inside the TIFF viewer?
  9. a) Because it's a different kind of device with different restrictions.
  10. 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)
  11. b) Because those TIFFs can be upto 4 GB (etc.)
  12. Well, too large for PCs, either. See a)
  13. 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 |