Imvtogif

[+Tarzilla]

 

I've been using the imvtogif tool to convert to gif then resize in Gimp. I've noticed that there is a frame discrepancy between what is in the emulator and the final gif.

 

I'm not near a real computer to post examples but it can be seen in the animated gif in this thread.

 

http://atariage.com/forums/topic/233120-operation-sushi/

 

The copter blade is animated by alternating the blade but it appears static in the gif.

Anyone else notice this in their gifs and where is the frame dropping(for lack of a better term) happening?

[intvnut]

That's actually by design in imvtogif. I had a couple reasons for doing this, some of them out of date now.

• The animated GIF standard doesn't have a "frame rate." It specifies delays between GIFs.
• Because the delay is between frames, if a frame takes a non-trivial amount of time to display and decode, that affects the ultimate display rate.
• The delays are specified in multiples of 10ms.
• The display frame rate on the Intellivison is 60Hz, which means a new frame every ~16.7ms.... which doesn't really jibe well with 10ms quantities.

The pragmatic approach I took when I wrote imvtogif was the following:

• Assume 6.67ms decode time for frames.
• To keep the error bounded from that assumption, don't send frames more often than every 50ms (20Hz).

So, with each frame, I send the data and set the delay to the nearest 10ms multiple for display. I roll the roundoff error into the next frame.

 

Overall, this works pretty well for many things, but as you noticed, it doesn't give crisp, clean 60Hz animated GIFs. Also, in the decade or more since I wrote that code, web browsers are probably faster at displaying animated GIFs. We're not on Netscape 4 any longer, and we're not posting these GIFs to Geocities and MySpace.

 

If you're interested in playing with this, you can recompile imvtogif, modifying this line accordingly:

 

if (curr_gif_time - prev_gif_time <15) { skip++; early = 1; continue; }

If you just comment it out, it should never drop any frames. You'll get delays that oscillate between 10ms and 20ms. Due to the 6.67ms bias internally, I think all or nearly all will be 10ms delays. The animation may run on the fast side as a result, but that's likely OK.

Edited January 20, 2015 by intvnut

[intvnut]

Also, the 160x200 aspect ratio thing was a "save bytes for folks on dialup" tradeoff.

 

Pixel doubling it out to 320x200 isn't hard to do in that code, but it takes a little more work.

 

There isn't that much code in jzintv/src/util/imvtogif.c

[+Tarzilla]

Thanks, I figured it was something like that. You left some code in this thread about the bigger output images:

 

http://atariage.com/forums/topic/209570-sdk1600s-imvtogif/?do=findComment&comment=2711395

 

 

I'll have a look later in the week, real life permitting.

[intvnut]

Thanks, I figured it was something like that. You left some code in this thread about the bigger output images:

 

http://atariage.com/forums/topic/209570-sdk1600s-imvtogif/?do=findComment&comment=2711395

 

 

I'll have a look later in the week, real life permitting.

 

 

And funny... my perpetually dying Windows box came up there too. That box is up and running strong now thanks to pimpmaul69. (It had been getting incrementally unstable due to capacitor plague. I was coaxing time out of it by incrementally dialing back settings to make it 'stable' again, until finally nothing made it work. This last December, he swapped all the affected caps for me once we discovered that was the issue, and it's fit-as-a-fiddle now.)

 

 

Seeing as I've already written the code (in that other thread), maybe I should just go plop that in there. It's not much code. Lemme hammer on it this morning.

[intvnut]

Ok, so I've added some flags to imvtogif:

.

imvtogif [flags] input.imv output.gif
Flags:
    -d##   Set minimum delay to ##ms, default 50ms.
    -D##   Assume GIF decode delay of ##ms, default 3.33ms.
    -s     Stretch horizontallly 2x.
    -f     Flat images (no transparency or optimization).

.

The -f flag gives what the previous '-' flag did. It disables image optimization. If you set -d0 (or anything 16 or lower), you'll end up with an animated GIF that includes all frames. However, at least in Firefox, the resulting GIF runs like molasses, at least on my Linux box. If you load it in GIMP, however, and play it with its animation playback, it looks just like you're playing jzIntv.

 

The -D flag sets what imvtogif thinks is the penalty for decoding a single GIF frame. I've defaulted that to 3.33ms (previously it was 6.67ms). It doesn't really seem to affect things much.

 

All millisecond times get rounded down to a multiple of 3.33ms in this build.

 

Included with this are the latest builds of jzIntv, AS1600, and the SDK-1600 tools. jzIntv includes myriad updates, including arbitrary display resolutions (see the -z flag), and bugfixes on kbdhackfiles, among other things. AS1600, dis1600, etc. include bug fixes. And so on.

 

Enjoy.

• Win32 build. jzintv-20150120-win32.zip
• OS X build. jzintv-20150120-osx.zip
• Linux 64-bit build. jzintv-20150120-linux-x86-64.zip

Edited January 21, 2015 by intvnut

[intvnut]

Hmmm... I stretched "horizontally" to "horizontallly" in the flag description unintentionally.... I think I'll leave it. It makes me chuckle.

[tacrec]

Any way to convert either imv or resulting gif to a video file? My gif does not play in a browser or a player. If I convert it to an AVI, it only converts a few seconds.

[intvnut]

Any way to convert either imv or resulting gif to a video file? My gif does not play in a browser or a player. If I convert it to an AVI, it only converts a few seconds.

 

That's weird. Is it a size issue? I haven't had any issues with GIFs playing in browsers, other than perhaps playing too slowly.

 

A quick Google search suggests there's a bunch of tools out there for converting GIFs to movie formats, but I haven't tried any of them.

 

 

(And a ;) on the link.)

[tacrec]

I've tried both sizes. All I get is the first screen of the gif.

[intvnut]

I've tried both sizes. All I get is the first screen of the gif.

 

Odd. Are you sure there's more than one frame in the IMV file that you're converting? Feel free to email me privately if you'd like for me to take a look.

[tacrec]

*snip*

Edited April 13, 2015 by tacrec

[mthompson]

I did a couple of tests with Intv animated gifs and had good luck at www.files-conversion.com. Their free service does have size limits, though. I used Moderate quality at 640x480 and the iPod/iPhone H.264 compression. Here is the result from the baseball gif:

 

http://www.files-conversion.com/file-convert/result/ibltest.mp4

Edited April 13, 2015 by mthompson

[tacrec]

I found a program called virtualdub, converts it to an avi, then format factory converts it to a mov. It's a hop skip and a jump but gets it done. Results in the IBL thread!

[tacrec]

I am noticing a color remap when converting. ex "Remap 4 to 0". Just wondering if that can be altered somehow ex. "Remap 4 to 9".

[intvnut]

I am noticing a color remap when converting. ex "Remap 4 to 0". Just wondering if that can be altered somehow ex. "Remap 4 to 9".

 

The color remap is based on which colors out of the 16 Intellivision defines are actually used, vs. not used. The most commonly used colors get lower numbers in the remap, so that later frames are less likely to need to redefine them. (This is a compression heuristic.)

 

Is there a particular reason you need the GIF color numbers to have a specific value? Most GIF decoders should take the GIF color number and look it up in the currently active palette.

 

I'm just curious what you're trying to achieve, and if there's maybe a better way to achieve it. (For example, having imv2gif adopt the Intellivision palette as the GIF palette, and avoid optimizing for unused colors, for example.)

[tacrec]

I was thinking of customizing the colors in the gif to avoid having to hack the code to change sprite colors. For example, changing blue to orange in the remapping. Just a thought, seems easy to change numbers.

[intvnut]

Changing the numbers won't change the colors. All the numbers are are indices into the palette. You need to change the palette itself.

 

The "Remap 4 to 0" is just where imvtogif compresses unused colors away from the palette, and moves entry 4 down to entry 0. Moving it to entry 9 wouldn't change how the image appears. It's just shuffling the numbers assigned to the colors that are already there.

 

I don't remember if GIMP has an easy way to edit the palette in a GIF. If memory serves, it doesn't. I remember other image editors from the 90s did, though. Basically, click on the color from the palette, change it to what you want, et voila! all instances of that color change.

 

In GIMP, I believe you need to set the image type to RGB (instead of indexed), use the select by color tool, bucket fill with the new color (after selecting 'fill entire selection') and then you get your desired result. You can get there, but GIMP doesn't make that particular process easy. Its image processing model assumes the color a pixel is when you load the image is the color it's meant to be, and the palette abstraction is a structure to be worked around, rather than to be leveraged.

Edited June 30, 2015 by intvnut

[tacrec]

My gif crashes GIMP when processing the final frames, so that's out.

[tacrec]

So I solved the color problem, but I am realizing why I can't sync the audio to the resulting gif: when the imv is being made, there is no account for delays in the game. For example, in baseball there is a one second delay before the pitcher goes into his windup to throw the ball. In the imv there is no delay. It seems the imv is just capturing motion only. If there is no motion (ie the delay before the windup), no capture.

Edited July 1, 2015 by tacrec

[intvnut]

So I solved the color problem, but I am realizing why I can't sync the audio to the resulting gif: when the imv is being made, there is no account for delays in the game. For example, in baseball there is a one second delay before the pitcher goes into his windup to throw the ball. In the imv there is no delay. It seems the imv is just capturing motion only. If there is no motion (ie the delay before the windup), no capture.

 

imvtogif should be setting delays on frames. In animated GIFs, you set a delay (specified in 100ths of a second) for how long the frame should be held before going to the next frame. So, it is capturing the delays in the game. Rather than sending redundant frames, it sends one frame and says "Hold this for 1000ms" or similar.

[tacrec]

I guess it should be but it's not, there is no delay before the windup. Did I convert it from the imv wrong? My command was

"imvtogif -s -d0 BMRSatSPRT.imv BMRSatSPRT.gif"

[intvnut]

I guess it should be but it's not, there is no delay before the windup. Did I convert it from the imv wrong? My command was

"imvtogif -s -d0 BMRSatSPRT.imv BMRSatSPRT.gif"

 

Hmm. I don't see an issue with those flags. How are you viewing the animated GIF? In a web browser or with some other mechanism?

[tacrec]

I opened it with a program called VirtualDub. It's the only program I've found that can process it. GIMP crashes because the gif is so big. I just opened it with internet explorer and the delays are there. Hmmm...

[tacrec]

Yea, VirtualDub does not handle VFR gifs. Looking for software that does....