GIF: I'm having problems with the Data Sub Blocks

GIF: I'm having problems with the Data Sub Blocks

Post by Robert Sauch » Wed, 14 Aug 1996 04:00:00



I'm having problems with the GIF format:

I've got the format pretty well figured out (Header, Logical Screen
Descriptor, Image Descpriptor, and LZW compression).  But I have one
problem that I'm hoping someone might have the answer to.  It has to do
with the Data Sub Blocks in the actual Image Data.  I understand that each
Sub Block is composed of a byte count (0-255) and the LZW codes (nothing
else), if I'm wrong about this please let me know.  I looked at a GIF
made by LView (200x200 pix.).  The first character count byte was 255
(of course).  I counted exactly 255 bytes not counting the character count
byte (over and over) but the next character count byte was 248 (not 255)
but there were alot more than 255 bytes left!  Although there was a byte
with the value 255 after 250 (not 255) bytes!  Could someone please
explain why this is.  Thanks!

Robert  :)>

 
 
 

GIF: I'm having problems with the Data Sub Blocks

Post by Alexander Lehma » Wed, 14 Aug 1996 04:00:00


: I'm having problems with the GIF format:

: I've got the format pretty well figured out (Header, Logical Screen
: Descriptor, Image Descpriptor, and LZW compression).  But I have one
: problem that I'm hoping someone might have the answer to.  It has to do
: with the Data Sub Blocks in the actual Image Data.  I understand that each
: Sub Block is composed of a byte count (0-255) and the LZW codes (nothing
: else), if I'm wrong about this please let me know.  I looked at a GIF
: made by LView (200x200 pix.).  The first character count byte was 255
: (of course).  I counted exactly 255 bytes not counting the character count
: byte (over and over) but the next character count byte was 248 (not 255)
: but there were alot more than 255 bytes left!  Although there was a byte
: with the value 255 after 250 (not 255) bytes!  Could someone please
: explain why this is.  Thanks!

The size of each data subblock isn't necessary 255, it is up to the
writing program what sizes the block are (though obviously 255 creates
the least overhead). The indication that a subblock sequence is
finished is a subblock size of 0, so you should be able to read the
whole stream by reading the size and then reading (size) bytes into
your buffer until size is 0. (the next byte after the 0 is usually a ;
(end of file) or a comment introducer (!0xff, I think)).

bye, Alexander

--
Alexander Lehmann,                                  |  "On the Internet,


<URL:http://www.mathematik.th-darmstadt.de/~lehmann/>

 
 
 

1. GIF: I'm having problems with the Data Sub Blocks

I'm having problems with the GIF format:

I've got the format pretty well figured out (Header, Logical Screen
Descriptor, Image Descpriptor, and LZW compression).  But I have one
problem that I'm hoping someone might have the answer to.  It has to do
with the Data Sub Blocks in the actual Image Data.  I understand that each
Sub Block is composed of a byte count (0-255) and the LZW codes (nothing
else), if I'm wrong about this please let me know.  I looked at a GIF
made by LView (200x200 pix.).  The first character count byte was 255
(of course).  I counted exactly 255 bytes not counting the character count
byte (over and over) but the next character count byte was 248 (not 255)
but there were alot more than 255 bytes left!  Although there was a byte
with the value 255 after 250 (not 255) bytes!  Could someone please
explain why this is.  Thanks!

Robert  :)>

2. 3D model

3. Going Insane - Gig3do / Linux text problem

4. GIF: I'm having problems with data sub blocks

5. myJanee.com Art Challenge!

6. GIF: I've been having a small problem

7. Gnuplot window size

8. I'm having problems with quality of JPEG's in D5

9. Non square image sub blocks