AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2007

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2007.01.15 01:09 "bigtiff", by Albert Cahalan
2007.01.15 03:42 "Re: bigtiff", by Frank Warmerdam
2007.01.15 06:00 "Re: bigtiff", by Albert Cahalan
2007.01.15 08:01 "Re: bigtiff", by Joris Van Damme
2007.01.15 09:13 "Re: bigtiff", by Rob Van Den Tillaart
2007.01.15 09:43 "Re: bigtiff", by Joris Van Damme
2007.01.15 16:12 "Re: bigtiff", by Albert Cahalan
2007.01.15 17:22 "Re: bigtiff", by Frank Warmerdam
2007.01.15 17:34 "Re: bigtiff", by Joris Van Damme
2007.01.16 06:17 "Re: bigtiff", by Albert Cahalan
2007.01.16 09:25 "Re: bigtiff", by Joris Van Damme

2007.01.15 17:34 "Re: bigtiff", by Joris Van Damme

Albert,

Albert Cahalan wrote:
> The waste is less than a millionth of the file size, or 0.0001 %.
> At "ten times", it's still only 1/100000 of the file size, or 0.001 %.

Ah, is it?

Say an image is 32x32 pixels. You have those, in TIFF. Say there are ten
tags in the IFD that are just over 4/8 bytes in size and don't fit the
IFD, and five others. Let's be generous and do you the favour of not
compressing the image, and say all pixels have four bytes.

The BigTIFF size is 16+8+15*20+8+10*8+32*32*4. The size of what you
propose in the first of your two proposals that seem to be pulled
between the conflicting desires of compatibility and sanity, is
RoundUpToMultipleOf4096(16) + RoundUpToMultipleOf4096(8+15*20+8) +
10*RoundUpToMultipleOf4096(4096) + RoundUpToMultipleOf4096(32*32*4).
Give or take a few bytes, as this is just from the top of my head, you
end up with at least 10 times as much, with the exact same image data in
there.

> With bit shifting, there is no need to worry. The writer shifts values
> to the right. The reader shifts values to the left. There is no way to
> create a reader or writer that is semi-compatible. Either it works or
> it does not.

You seem to miss the point, BigTIFF *is* TIFF. There is no such
bitshifting to get rid of insignificant bits in offsets, in TIFF.

I would agree though that the requirement to align is one of the most
redundant rules in TIFF and BigTIFF alike. It is also one of the most
violated. And its violation is no problem, at all. My own codec does
align, but I came very close to deciding otherwise.

So I just don't see the benefit of ensuring it, nor do I see the benefit
or killing it, nor do I see what is the big deal to 'worry' about as
opposed to bitshifting. What I do see, is advantage to keeping BigTIFF
totally as close as possible to TIFF.

> Clearly the spec has been overly difficult to implement and/or just
> not all that desirable.

That's just not the case.


Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html