Encyclopedia of Graphics File Formats

Errata for Encyclopedia of Graphics File Formats

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.


Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted
Printed Page 30
It seems to me that the order of the third and fourth paragraphs are

reversed.

Anonymous   
Printed Page 68, 70
Figures 3-1 and 3-3 are identical. It appears that the intended

Figure 3-1 was omitted.

Anonymous   
Printed Page 267
In "Atari ST Graphics Formats" under "DEGAS Format", the three values of

"Resolution" are described as "Left", "Off", and "Right". These should be "Low", "Medium", and "High".

Anonymous   
Printed Page 269
bottom

This isn't really a technical mistake, but worth pointing out anyway. I would suggest that some clarification text be inserted in this section - perhaps at the front? The Atari NeoChrome format is rich enough to handle most of the tasks needed for basic picture storage. For instance it can, in a single file type, handle all of the file types represented by the multiple DEGAS PI* formats, the IC formats, and the Tiny format. So why are there so many formats on the ST? Well the NEO format, used by the NeoChrome program from Atari, went unreleased and it's format stayed out of developer view. During the first few months to a year of being on the market many graphics programs for the machine were shipped which had to invent their own formats. A year or so later NEO was finally released but by that time the formats had already become entrenched in the market.

Anonymous   
Printed Page 350
In the section on Lotus PIC, the header is quoted as

01 00 00 00 01 00 08 00 44 00 00 00 0C 7F 09 06 The correct header, I believe, is 01 00 00 00 01 00 08 00 44 00 00 00 00 0C 7F 09 06

Anonymous   
Printed Page 373
The header of a DVM version 1.0 file doesn't contain the info flag.

Also, it is not possible to include text in a version 1.0 file. So the header of a v1.0 file should be: typedef struct _DVM_HEADER { char ID[3]; /* File ID "DVM" */ char Size; /* Q or F */ WORD Wait; /* Time (ms) to wait between frames */ } DVM_HEADER; The last sentence says that version 1.0 or higher should use an enhanced palette. Only version 1.0 should use one, because the header of version 1.0 doesn't have an info entry that defines that there's no enhanced palette. If an enhanced palette occurs, before every frame comes the palette. So there are three frames, there are three enhanced palettes. The file would be like this: [header][palette 1][frame 1][palette 2][frame 2][palette 3][frame 3] In DVM version 4.0 (which is not discribed in the book), it is also possible to use one palette for the whole file.

Anonymous   
Printed Page 374
In the C source, the following lines are untrue

palette[r*36+g+b+16].r=(BYTE)(ROUND((DOUBLE)r*12.6)); palette[r*36+g+b+16].g=(BYTE)(ROUND((DOUBLE)g*12.6)); palette[r*36+g+b+16].b=(BYTE)(ROUND((DOUBLE)b*12.6)); They should be: !! palette[r*36+g*6+b+16].r=(BYTE)(ROUND((DOUBLE)r*12.6)); palette[r*36+g*6+b+16].g=(BYTE)(ROUND((DOUBLE)g*12.6)); palette[r*36+g*6+b+16].b=(BYTE)(ROUND((DOUBLE)b*12.6));

Anonymous   
Printed Page 382
entire page contains multiple errors

EPS's created using the preview format shown on this page will not work properly due to a number of errors in the description. The typedef listing shows the checksum as a DWORD, or 4 bytes long. It is in fact a 2 byte (WORD?) field instead. Later on the page the book notes "if the checksum field is zero, ignore it", this too is incorrect, the proper flag for ignoring the checksum is FFFF. Nor is the way to construct the checksum mentioned, which is to XOR bytes 0 to 27 of the header. Thus when describing the EPS header format and length, the book reads "so it's offset is always 32". This is wrong because the checksum is smaller, the header is only 30 bytes long. Using the information as provided will make the EPS fail to view properly as the EPS parser will "miss" the start of the EPS and consider it invalid! Finally the book suggests that these formats for previews are not recommended, and that authors should look to the plaftorm-independant EPSI format instead. In reality I have yet to find a single program that supports EPSI, whereas every program I have supports the TIFF preview format. So another change I would make to this page would be to suggest the use of TIFF preview files, specifically little-endian ones because MS's previewer can't read big-endian versions. page 438 typedef struct _Win3xBitmapInfoHeader { WORD Headersize: should be DWORD rather than WORD.

Anonymous   
Printed Page 441
6th paragraph (2nd paragraph from the bottom)

In the second sentence describing Windows BMP RLE compression escape sequences, the values for the "end of image" and "end of line" are reversed. A programmer writing an RLE decompressor for the BMP file format would only be able to decompress the first line. The sentence should read: " A value of 0 in the second byte signals the end of a scan line; a value of 1 indicates the end of the image; ...."

Anonymous   
Printed Page 513
in the paragraph that begins with "Extension code", the "13h" should be

"12h".

Anonymous   
Printed Page 664
The description of the PCX format states that the "identification value

defined by the PCX specification as always being 10h." It is customary to add the letter "h" to a number that is in base sixteen, so 10h would mean 10 in base sixteen, but the actual value for the identifier is 10 decimal or 0A hexadecimal.

Anonymous   
Printed Page 667
The second sentence of the paragraph immediately below the table reads:

"The number of bits per pixel per plane is multiplied by the number of color planes and shifted to the left by one. MaxNumberOfColors = (1L << (BitsPerPixel*NumBitPlanes)) ; " The code is correct, but not the explanation. The above line of C code shifts the bits of 1 to the left by the number in (BitsPerPixel*NumBitPlanes).

Anonymous   
Printed Page 674
In the 7 steps for "Encoding PCX Image Data", the 5th step should have

an additional clause before "then", namely "or the count is 1 and the data value has the two MSB's on".

Anonymous   
Printed Page 706
line 4:

This defines the values for the PNG file IHDR marker as "69484452h". The correct value is 49484452h.

Anonymous   
Printed Page 901

On page 901/2, describing the PackBits RLE scheme, the two coding schemes are the wrong way around. At the bottom of page 901 'The actual run-count value stored is in the range 0 to 127 and represents the values 1 to 128 (run count + 1).' This should be 'The actual run-count value stored is in the range -1 to -127 and represents the values 2 to 128 (-run count + 1).' Similarly the description of the literal run packet is wrong on page 902.

Anonymous   
Printed Page 956
In the Wavefront RLA description you have

ImageHeight = (ActiveBottom - ActiveTop) + 1; Up above, it says that the RLA format uses a lower-left coordinate system (standard for SGI's), which means that you should have: ImageHeight = (ActiveTop - ActiveBottom) + 1;

Anonymous