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
March 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.03.31 10:31 "A little PackBits bug", by Roland Nahser
1994.03.31 19:30 "Re: A little PackBits bug", by Dan Mccoy

1994.03.31 10:31 "A little PackBits bug", by Roland Nahser

Dear TIFF-Developers,

I am an user of your fantastic libtiff Version 3.30beta. With 3.3 it
is much easier to port to different environments. But there seems to 
be a little bug in PackBitsEncode in the following if statement:
                case LITERAL_RUN:       /* literal followed by a run */
                        /*
                         * Check to see if previous run should
                         * be converted to a literal, in which
                         * case we convert literal-run-literal
                         * to a single literal.
                         */
                        if (n == 1 && -op[-2] == 1 && *lastliteral < 126) {
                                state = (((*lastliteral) += 2) == 127 ?
                                    BASE : LITERAL);
                                op[-2] = op[-1];        /* replicate */
   
variable op is declared as tidata_t (unsigned char *). Using it as 
-op[-2] does not always result in 1 as expected but in -255.
(binary representation of -1 as u_char = 255 (on nearly every machine I know
from). This bug arose on DEC Ultrix and SunOS with gcc. I think the most
portable way is to test: op[-2] == 255.
The solution: - (char)op[-2] == 1 works on machines where 
char is signed char. Using explicit signed char is not possible on all
machines (I think Ultrix is one of them).

---
Second I am using a "private" TIFF-format for temporary storing 
images generated by our GKS-software in the following format
Separate planes
SamplePerPixel = 3 or 4
BitsperSample  = 1
Compression    = PACKBITS or LZW

when I try to use RowsperStrip > 1 (for better performance and 
compression with LZW) I get the errormessage:

TIFFWriteScanline:Compression algorithm does not support random access 

I am writing the image with the following simplified code fragment :

    for (i = 0; i < numscans; i++) {
      /* small loop over planes (or) samples */
      for (sample = 0; sample < samperpix; sample++ ) {
        /* start byte in data stream = startdata */
        startdata = (char *) &data[iofp] + startbyte;
         (void) TIFFWriteScanline(out, (tdata_t) startdata, tmprow, 
                                  (tsample_t) sample);
        iofp += planelen;
      } /* end loop over samples */
    } /* end loop over scans */
  
I do not understand why this is direct access. 
Are there any plns to support real direct access in libtiff? I am
looking for a format for intermediate storage of tiled images within
rasterization of very large high resolution images for 
phototype setters.
-- 
Roland Nahser


+----------------------------------+--------------------------------+
|GraS - Graphische Systeme GmbH    |     email : rn@gras.de         |
|Mecklenburgische Str. 27          |     Phone : +49 30 8232074     |
|D-14197 Berlin                    |     FAX   : +49 30 8248779	    |
|Germany                           |                                |
+----------------------------------+--------------------------------+