Parsing GIF Format (NOT using Extension Builder ) SUCCESS!!!

[OpenXTalkPaul]

Here's an updated stack with some errors corrected, and a few more demos of doing stuff with the GIFArray

GIFEdit_better.oxtstack

(190.74 KiB) Downloaded 9 times

And here is some sample output (original vs. edited)

dancin_lepro.gif (12.15 KiB) Viewed 386 times

EditedGIF5.gif (12.1 KiB) Viewed 386 times

sample_2_animation.gif (218 Bytes) Viewed 386 times

EditedGIF.gif (172 Bytes) Viewed 386 times

[xAction]

Worked pretty good on the little traffic light gif, not so good on a big hunkin' one like I use around here

[OpenXTalkPaul]

Worked pretty good on the little traffic light gif, not so good on a big hunkin' one like I use around here

Oh? Please post any problem GIFs, it will help me find any flaws in the parser.
I've tried it with a few larger GIFs around 2MB and didn't have a problem reading / writing them.

I'm still testing it. I was just playing around with swapping out the GIf's global color table.

div-6.gif (1019.01 KiB) Viewed 379 times

div-6-edit.gif (1017.64 KiB) Viewed 379 times

[OpenXTalkPaul]

New Demo stack version, with global color table swap demo:

GIFEdit_better.oxtstack

(184.28 KiB) Downloaded 8 times

ColorTableSwap.jpg (302.31 KiB) Viewed 379 times

That GIF looks much more cool animated with the darkMode window background showing though the transparency color.
Looks like the Eye of Sauron of something, hah!

Not as cool lookin in light Mode:

ColorTableSwapLight.jpg (320.94 KiB) Viewed 379 times

[OpenXTalkPaul]

While I'm on the subject of Index Color Tables, I should note it was already possible to apply a color table without these handlers I've posted here, but NOT for an animated GIF.

It can be done using the 'Export Snap Shot' syntax.
Here's some example script that I used to convert an image to the Mac II (and Decker) 16 colors table:

Code: Select all

on mouseUp pButtonNumber
   export snapshot from widget "Original" to pictVariable as GIF
   set the text of image "SVGRasterizedAsGIF" to pictVariable
   export image "SVGRasterizedAsGIF" to pictVariable as gif with palette getDeckerMacIIPalette()
   set the text of image "SVGRasterizedAsGIF" to pictVariable
   -- PUT getDeckerMacIIPalette()
end mouseUp

function getDeckerMacIIPalette
   get "255,255,255" & cr & \
         "255,255,0" & cr & \
         "255,101,0" & cr & \
         "220,0,0" & cr & \
         "255,0,151" & cr & \
         "54,0,151" & cr & \
         "0,0,202" & cr & \
         "0,151,255" & cr & \
         "0,168,0" & cr & \
         "0,101,0" & cr & \
         "101,54,0" & cr & \
         "151,101,54" & cr & \
         "185,185,185" & cr & \
         "134,134,134" & cr & \
         "69,69,69" & cr & \
         "0,0,0"
   sort it NUMERIC BY ITEM 1 OF EACH
   return it
end getDeckerMacIIPalette

Here's a site that has bunches of index color table schemes:
https://lospec.com/palette-list/

[xAction]

I tried this gif, it didn't work out for me.

Ant_Maze.gif (57.24 KiB) Viewed 373 times

[OpenXTalkPaul]

I tried this gif, it didn't work out for me.
Ant_Maze.gif

OK thanks for posting it, I'll give it a looksee and try to figure out what went wrong.
Edit: just tried that one and it gets stuck in the parsing loop for me too, there's some work to do there.

I think there's possibly somethings wrong with some of the parameter elements of the GIFArray, like transindexcolor or disposeMethod.

I was just now doing some experiments using it to create new animated GIF from a series of image and widget controls.
This one was created using my vector drawing widget (so I'm not going to include it in the demo stack):

[xAction]

That's progress! Woo! More exclamations to satisfy the forum gods.

[OpenXTalkPaul]

I'm still struggling to figure out why Ant Maze Gif (and one or two others) do let parse correctly (now) it seems, but do not get reassembled correctly for some reason. But the effort to find the problem has lead me to tightening up the scripts a bit, hopefully I'll get more time to track it down soon (but going on a vacation soon). I do get it to extract the first frame, but extracting or deleting like image frame 2 or 50 is when there's the problem.

[richmond62]

As the Ant Maze GIF is derived from a stack of mine I wonder how the GIF was made.

I, personally, on a Mac, would use COMMAND 5 to take a movie file of the relevant section of the stack, and then convert that movie file to a GIF using an online thingy to do that.

[OpenXTalkPaul]

As the Ant Maze GIF is derived from a stack of mine I wonder how the GIF was made.

I, personally, on a Mac, would use COMMAND 5 to take a movie file of the relevant section of the stack, and then convert that movie file to a GIF using an online thingy to do that.

I'm guessing it was made with either FFMPEG or ImageMagick.
Whatever made that GIF did so in a very inefficient way, there is absolutely no reason there needs to be a separate color table for each of the 50 image frames inside that GIF because the colors for every frame in that animation are the same. Also it set the header to GIF87a but it should be GIF89a because it includes animation frame delays.

I found the problem, which wasn't in the read part (which I did tighten up a bit) but rather it was simply that I had just never finished writing the GIFArrayToGIFData handler , it wasn't including local color tables in the data it was writing back out at all, it only wrote the image descriptor. The local color table part doesn't apply when there's only a global color table so many GIFs worked fine without the local table code.

Ant_Maze_fast.gif (701.44 KiB) Viewed 264 times

This should complete the GIF in and GIF out mechanisms enough for general use.
Now it can be optimized for speed.

[OpenXTalkPaul]

As the Ant Maze GIF is derived from a stack of mine I wonder how the GIF was made.

I, personally, on a Mac, would use COMMAND 5 to take a movie file of the relevant section of the stack, and then convert that movie file to a GIF using an online thingy to do that.

I'm guessing it was made with either FFMPEG or ImageMagick.
Whatever made that GIF did so in a very inefficient way, there is absolutely no reason there needs to be a separate color table for each of the 50 image frames

Hmm, now I think at some point I myself must have recreated that GIF adding all of those local color tables for every frame? I say that because it looks like the GIF xAction originally posted was only 59KB while what wound up in my test GIFs folder is like 700k! Anyway, now that it's all working properly I should be able to easily create a handler that removes all of the local color tables leaving only a global color table resulting in a much smaller GIF data.

I'm most excited by now having the ability to spin brand new animated GIFs from stack objects, there's all sorts of cool things that could be done with that beyond just editing existing GIF data.

One thing I should recommend is the Tree View extension, which is part of the IDE, used by Property Inspector. It's very handy for getting a visual representation of an array with the simple syntax: set the arrayData of widget "My Tree View" to tMyArray.

Here's the latest iteration of the stack/script:

GIFEdit_best.oxtstack

(1.51 MiB) Downloaded 11 times

[richmond62]

Of course a "prissy B" might point out that something is not quite right:
-

quality.png (94.69 KiB) Viewed 242 times

-
Original stack on the left, your GIF on the right.

Sorry to be a complete pain.

[xAction]

I think those local color tables are there in the event that the gif is not mostly a static image like these UI element or cartoon loops are. Maybe static isn't the right word...homongenous?

For instance the GIFs you see on giphy.com that are rips of movie scenes, commercials, stock videos and tiktok nonsense. Since you don't know what you're recording you can't predict what the color table should be and the software 'just works'.

The software in question is liceCap

[OpenXTalkPaul]

Of course a "prissy B" might point out that something is not quite right:
-
quality.png
-
Original stack on the left, your GIF on the right.

Sorry to be a complete pain.

I think I may have re-saved that GIF from Preview or Photoshop, so it may have gotten its color table replaced or some ColorSync thing had some effect, I'm not sure why else that might be. Normally it should be the same exact color table as the original, unless you explicitly replace tables in a GIF Array before converting back to the GIF File Data format.
I retried with the original GIF, without any edits to the GIFArray, and then converted the Array back to GIF and the resulting size was identical. I'd have to do a DIFF with a Hex editor (HEXFiend ) to be certain that it's %100 same ...
One thing I noticed may still be broken is the 'Plain Text Extension blocks, which 99.9999% of GIFs do not use (I have only 1 test file for that and it's from the Compuserve GIF89a introduction), that feature was never adopted by the public, but since I've gone this far I might as well go for supporting the complete GIF89A spec.

[OpenXTalkPaul]

The software in question is liceCap

OK thanks. I'll have to give that a try.
It looks like licecap uses GIFlib (the same library the engine and lots of other software uses)
https://github.com/justinfrankel/liceca ... WDL/giflib

FFMPEG and ImageMagick can do record screen to GIF as well, if fed them the right commands.
https://superuser.com/questions/556029/ ... le-quality.

[OpenXTalkPaul]

I will say that the engine's rendering seems to prefer it if there's a local color table.

The thing is the image data (the 'imageData' element is the LZW compressed chunk of each [image] elements in the GIFArray), when expanded to 'pixels' are actually 8-bit indexes that each point to a color in these tables, so could be a problem if dropping in a lists of colors that's a smaller list than the original color table, situation might arise where a pixel might call for using color index 27 but you've replaced the color table with a 16 color table so there is no color 27. Color tables size must be a length that's some power of 2 (2,4,8,16,32,64,128, or 256), but Ive swapped out 128 color table with a 2 color Black and White table and the engine and browsers still renders it without complaints. I think this was actually one of the original intentions for the GIF format, to be able to 'downgrade' image colors to whatever color set was available on a machine, which in 1987 might have meant a Atari or Commodore color palette.

I also added Mac II 16 color, GameBoy 4-color green set and a few others from lospec (https://lospec.com/palette-list) in a pop-up menu. I think I'll make a handler that makes a visual representation of the color table. I might also write a handler to import GIMP color table files as found on that sight.

[tperry2x]

One thing I should recommend is the Tree View extension, which is part of the IDE, used by Property Inspector. It's very handy for getting a visual representation of an array with the simple syntax: set the arrayData of widget "My Tree View" to tMyArray.

Hi Paul, sorry to cover old ground, but could I back-pedal a bit and ask for additional detail on the above?

Could you give me a screenshot of what it looks like inspecting an array, just as I think I'd understand it better with a visual representation.

The reason I ask is to ensure that the property inspector I'm making (to replace the inspector) - I don't want it to be missing any features, and this sounds like something handy to be able to do, if I'm interpreting what you mean correctly?

Do you mean you can inspect the values of an array / multi-dimensional array? Can you get/set these array values?
Sorry if this is a dumb question. Just a part of the IDE I've not ever used much.

[OpenXTalkPaul]

One thing I should recommend is the Tree View extension, which is part of the IDE, used by Property Inspector. It's very handy for getting a visual representation of an array with the simple syntax: set the arrayData of widget "My Tree View" to tMyArray.

Hi Paul, sorry to cover old ground, but could I back-pedal a bit and ask for additional detail on the above?

Could you give me a screenshot of what it looks like inspecting an array, just as I think I'd understand it better with a visual representation.

The reason I ask is to ensure that the property inspector I'm making (to replace the inspector) - I don't want it to be missing any features, and this sounds like something handy to be able to do, if I'm interpreting what you mean correctly?

Do you mean you can inspect the values of an array / multi-dimensional array? Can you get/set these array values?
Sorry if this is a dumb question. Just a part of the IDE I've not ever used much.

There's no such thing as a dumb question.

And that is exactly what I'm talking about.
Download that demo "GIFEdit_best.oxtstack", the last demo stack I posted, I used it in that,.

I think I may have modified that widget, as I have done with several other widgets used by the IDE, like the color swatch widget or the gradient ramp editor widget, so that by default they'll appear in the rest of the Widgets in the tools palette.
The Tree View widget has several options that change its behavior, the widget can be in edit mode or read only view mode.

And yes, there are several widgets that are used by the Prop Inspector and its value editors stacks. For another example there textAlign (left|center|right) uses that header button bar widget.

[xAction]

The reason I ask is to ensure that the property inspector I'm making (to replace the inspector) - I don't want it to be missing any features, and this sounds like something handy to be able to do, if I'm interpreting what you mean correctly?

Do you mean you can inspect the values of an array / multi-dimensional array? Can you get/set these array values?
Sorry if this is a dumb question. Just a part of the IDE I've not ever used much.

The inspector has this array editing built in via the custom properties:

custom_properties_are_arrays.png (13.14 KiB) Viewed 190 times

All controls even the stack itself is an array

put the properties of this stack into tArray
repeat with K in keys of tArray
put K & "=" & tArray[K]
end repeat

An inspector is essentially the 'most commonly modified keys' of the array. And custom properties are "Hey, they forgot to add this (or these) property (or thousand properties) to the array...I'll add my own!"

Any time you have an array in memory, shoving it into a custom property is a good way to get a look at it without printing it the message box or a file. Great for seeing "Oh, that's all wrong!"