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
June 2006

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

2006.06.02 15:22 "TIFFWriteRawStrip with multi-strip?", by Bernie Pallek
2006.06.02 16:35 "Re: TIFFWriteRawStrip with multi-strip?", by Joris Van Damme
2006.06.02 17:08 "Re: TIFFWriteRawStrip with multi-strip?", by Bernie Pallek
2006.06.02 17:20 "Re: TIFFWriteRawStrip with multi-strip?", by Joris Van Damme
2006.06.07 08:50 "Re: TIFFWriteRawStrip with multi-strip?", by Gerben Vos
2006.06.07 11:48 "Re: TIFFWriteRawStrip with multi-strip?", by Joris Van Damme
2006.06.07 13:48 "Re: TIFFWriteRawStrip with multi-strip?", by Bernie Pallek

2006.06.07 13:48 "Re: TIFFWriteRawStrip with multi-strip?", by Bernie Pallek

> ...not to mention that G4 produces a stream of bits, not 
> bytes, so the boundary between two strips will not fall 
> on a byte boundary in most cases, and it is even less
> likely that it will be regular enough to determine a 
> rows-per-strip number.

Makes me wish Intel (or anyone) would introduce some "move-with-bit-offset"
instructions for external memory access.

MOV   CL,  7                  ; offset by +7 bits
MOVBO EAX, [some_variable]    ; fetch into EAX 32 bits from address of
some_variable + CL number of bits

If bits "around" the target address were always fetched anyway (haven't
thought about how to deal with bounds), there would be very little overhead
for reads.

*shrug*