Parsing GIF Format (NOT using Extension Builder ) SUCCESS!!!
Posted: Tue Feb 27, 2024 4:22 pm
So far it's taken a few hours of reading the GIF89a File format Specification and some tinkering around with a little trial and error. It took a little extra time to realize that I had a malformed file in my test GIFs collection, which was throwing me off because my code was correct but that file wasn't.
So far this:
Reads GIF Data Header ('magic number'/version)
Reads Global screen descriptor which includes:
- over all width and height
- whether there is a global color table or not
- intended color resolution
- global index for background color if there is one
Reads Global Color Table (CLUT) if there is one, which is a list of RGB values (byte triplets)
Checks next byte to for marker that indicates the next block is an image descriptor block or an extension block (which are things like frame delay time for animated GIFs)
Reads through all Extension Blocks and Image Descriptor Blocks, Image Frames Data Blocks (no LZW decode), local color tables (skips reading for now), Comments Blocks, Plain Text Blocks (Skips because GIF renderering engines never adopted it), and winds up at (or near) the GIF stream terminator. There may spots where it's a bit or byte or two off the mark.
Still testing this for accuracy using various test GIF files.
Theres lots of binaryDecode() used and some twiddling of packed bits (1s and 0s) in this script.
I'm trying to document in the comments every step, as I go through the GIF89a Spec.
That's as far as I've gotten so far.
I should probably rename the function GIFHeaderInfo() since it reads more than the header now. It's named like that because it started as a function that extracted the overall width and height of a GIF directly from it's data (without making invisible image boxes and other such nonsense just to get the image dimensions, which is the common answer given when the question has been asked in the past, but I found that to be extremely lame to even need a 'solution' for something so essential to dealing with graphics).
I suppose if we tinkered with the engine a bit we could expose more of GIFLib that the engine uses to parse GIF, or it could be added again separately as an extension wrapper (but I wonder if that would cause some conflict since the same library/symbols would be loaded 2x, in two different ways?).
I could probably write this with straight Extension Builder without GIFLib, but that would be basically the same as this xTalk script version with slightly different syntax and lots of variable declarations.
--- Leap Day (2/29/24) EDIT:
I just updated the code listing, it reads more of a GIF's meta information now, not 100% yet.
---EDIT (3/15/24)
WORKING CODE! It's too large to post the script here so I've attached the working stack.
NOTE: This is alpha or beta quality code, I've tested it on a bunch of GIF files, but there's very little error checking built into the scripts.
So far this:
Reads GIF Data Header ('magic number'/version)
Reads Global screen descriptor which includes:
- over all width and height
- whether there is a global color table or not
- intended color resolution
- global index for background color if there is one
Reads Global Color Table (CLUT) if there is one, which is a list of RGB values (byte triplets)
Checks next byte to for marker that indicates the next block is an image descriptor block or an extension block (which are things like frame delay time for animated GIFs)
Reads through all Extension Blocks and Image Descriptor Blocks, Image Frames Data Blocks (no LZW decode), local color tables (skips reading for now), Comments Blocks, Plain Text Blocks (Skips because GIF renderering engines never adopted it), and winds up at (or near) the GIF stream terminator. There may spots where it's a bit or byte or two off the mark.
Still testing this for accuracy using various test GIF files.
Theres lots of binaryDecode() used and some twiddling of packed bits (1s and 0s) in this script.
I'm trying to document in the comments every step, as I go through the GIF89a Spec.
That's as far as I've gotten so far.
Code: Select all
--- WORKING CODE TO LARGE TO POST HERE!
I suppose if we tinkered with the engine a bit we could expose more of GIFLib that the engine uses to parse GIF, or it could be added again separately as an extension wrapper (but I wonder if that would cause some conflict since the same library/symbols would be loaded 2x, in two different ways?).
I could probably write this with straight Extension Builder without GIFLib, but that would be basically the same as this xTalk script version with slightly different syntax and lots of variable declarations.
--- Leap Day (2/29/24) EDIT:
I just updated the code listing, it reads more of a GIF's meta information now, not 100% yet.
---EDIT (3/15/24)
WORKING CODE! It's too large to post the script here so I've attached the working stack.
NOTE: This is alpha or beta quality code, I've tested it on a bunch of GIF files, but there's very little error checking built into the scripts.