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
September 1994

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

1994.09.19 17:34 "Now that you mention bit order...", by Craig Jackson
1994.09.19 19:04 "Bit order revisited ...", by Scott Wagner
1994.09.19 22:46 "Re: Now that you mention bit order...", by Sam Leffler
1994.09.19 23:53 "Re: Now that you mention bit order...", by Craig Jackson
1994.09.20 13:25 "Re: Now that you mention bit order...", by Scott Wagner
1994.09.22 22:50 "Re: Now that you mention bit order...", by John M Davison
1994.09.22 23:49 "Re: Now that you mention bit order...", by Sam Leffler

1994.09.22 23:49 "Re: Now that you mention bit order...", by Sam Leffler

    To:  tiff@sgi.sgi.com
    Subject:  Re: Now that you mention bit order...
    Cc:  wagner@itek.com
    Date: Thu, 22 Sep 1994 17:50:54 CDT
    From:  John M Davison <davisonj@ecn.purdue.edu>

            Scott Wagner (wagner@itek.com) writes:
    >And that, IMHO, is the bit-order confusion story in a nutshell.
    
            Mr. Wagner left out one fact, namely that the notion of "native machine
    bit order", as it exists in Sam Leffler's TIFF interface software, is
    nonsensical.
    
            While a "bit order" issue certainly does come up when dealing with
    rendering/scanning systems that erroneously permute bits, the handling of this
    erroneous behavior is the responsibility of the associated drivers, not of any
    device-independent TIFF interface software (such as what Leffler has written).
    
            Thus, the notion of "native machine bit order" should be expunged from
    Sam Leffler's TIFF interface software.  Leffler's software has no business
    whatsoever worrying about rendering/scanning device "bit order".

Come on folks, enough of this crap already.  As I've repeatedly
explained; the library handles the FillOrder tag as necessary for image
data that's encoded.  For data that is uncompressed it does its best to
return the data to the application program in the appropriate bit+byte
order for the application to directly interpret sample values (consider
the case where IEEE floating point samples are to be exchanged between
hosts with CPUs that use different bit+byte order).  The library has
done this for many years and I've yet to receive a single solid example
of what it's doing wrong.  I intend to provide a mechanism whereby the
library's behaviour for uncompressed data can be defeated so that an
application does not have to undo work in order to make use of the
data.  This should close the one obvious loophole in the API.

If you or someone else has a specific example where the library does
something wrong, please send me mail directly.  Please do not send me
hypothetical examples, send me something real.

	Sam