Looking for small GIF loading routine

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
User avatar
TheNameOfTheGame
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2051
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Looking for small GIF loading routine

Post by TheNameOfTheGame »

Does anyone have a small, fast GIF image loading routing written in 68000 assembler? The GIFs are screenshots of games so are low resolution dimensions.

I noticed GIFs are compressed so would loading an uncompressed NEO image be faster?
User avatar
mfro
Atari God
Atari God
Posts: 1116
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Looking for small GIF loading routine

Post by mfro »

TheNameOfTheGame wrote: Wed Jun 29, 2022 5:54 pm I noticed GIFs are compressed so would loading an uncompressed NEO image be faster?
There is nothing faster than loading an uncompressed NEO image as that is 1:1 the ST screen format.
User avatar
TheNameOfTheGame
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2051
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Looking for small GIF loading routine

Post by TheNameOfTheGame »

Ah, ok, then I'll stick with NEO.

I just don't have a batch convertor for GIF->NEO and there are over a thousand game screenshots.

So the conversion to NEO is a big issue.
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2181
Joined: Sun Aug 03, 2014 5:54 pm

Re: Looking for small GIF loading routine

Post by ThorstenOtto »

Batch conversion should be possible with netpbm tools.
JeanMars
Captain Atari
Captain Atari
Posts: 418
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: Looking for small GIF loading routine

Post by JeanMars »

Hi,

you can do this using VISION, just adapt SCRIPTS/bconv.ini file to your needs, e.g.:
; SrcPath: Folder where source files are hold
SrcPath=H:\PURE_C\PROJECTS\VISION\IMGTEST\BYPLANES

; SrcMask: mask for files of interest
SrcMask=*.*

; SrcRecurse (0 or 1) if files of interst are to be searched in sub-folders
SrcRecurse=1

; OutputFormat: the 3 letter code for output format (e.g. DEG,GIF,TIF,JPG,PNG,...)
OutputFormat=NEO

; DstPath: folder whare files will be converted to
DstPath=H:\PURE_C\PROJECTS\VISION\TEMP


Make sure GIF source images are 320x200x4

Once SCRIPTS/bconv.ini is modified, load SCRIPTS/bconv.vcs from VISION (File-->Load or drag'n'drop bconv.vcs to VISION app icon).
That should do the job.

Cheers,
Jean
User avatar
sporniket
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Feb 16, 2018 5:39 pm

Re: Looking for small GIF loading routine

Post by sporniket »

mfro wrote: Wed Jun 29, 2022 6:13 pm
TheNameOfTheGame wrote: Wed Jun 29, 2022 5:54 pm I noticed GIFs are compressed so would loading an uncompressed NEO image be faster?
There is nothing faster than loading an uncompressed NEO image as that is 1:1 the ST screen format.
I would expect the contrary, especially if the file is loaded from the slow floppy disk drive.
User avatar
troed
Atari God
Atari God
Posts: 1590
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Looking for small GIF loading routine

Post by troed »

netpbm is always your friend.

cat picture.gif | giftopnm | pnmquant 16 | ppmtoneo > picture.neo

(pnmquant makes sure to limit the number of colors to 16. If you pictures aren't already 320x200 or less you need a scaling step too)

You then script this line into supporting batches.

http://netpbm.sourceforge.net/

/Troed
AnthonyJ
Atari maniac
Atari maniac
Posts: 93
Joined: Sat Jan 26, 2013 8:16 am

Re: Looking for small GIF loading routine

Post by AnthonyJ »

TheNameOfTheGame wrote: Wed Jun 29, 2022 5:54 pm Does anyone have a small, fast GIF image loading routing written in 68000 assembler? The GIFs are screenshots of games so are low resolution dimensions.
Google is your friend - top hit for "gif decode atari st": viewtopic.php?t=12418
I noticed GIFs are compressed so would loading an uncompressed NEO image be faster?
This perhaps depends on what you're trying to do really - as mentioned, floppies are slow, so maybe there's a chance that a smaller disk access + then decompression might be quicker than transferring the uncompressed data. If you have over a thousand of these images, you're likely not to be loading it from a floppy though, so that probably changes the balance significantly.
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2181
Joined: Sun Aug 03, 2014 5:54 pm

Re: Looking for small GIF loading routine

Post by ThorstenOtto »

It may still depend on the hardware. If you have a fast decompression routine, loading a compressed file from a slow harddisk and then decompressing it may still be faster, at least on TT or similar.
User avatar
TheNameOfTheGame
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2051
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Looking for small GIF loading routine

Post by TheNameOfTheGame »

Thanks for all the suggestions, they were very helpful. I ended up using troed's netpbm command line to batch convert since this is on linux.
User avatar
Mug UK
Administrator
Administrator
Posts: 11751
Joined: Thu Apr 29, 2004 7:16 pm
Location: Stockport (UK)
Contact:

Re: Looking for small GIF loading routine

Post by Mug UK »

I've got a 68000 linkfile code so you could bung all the images (packed in whatever format you want to use) into a single file. Less clusters used etc. if you're basing it on a floppy disk.
My main site: http://www.mug-uk.co.uk - slowly digging up the bits from my past (and re-working a few): Atari ST, Sega 8-bit (game hacks) and NDS (Music ripping guide).

I develop a free Word (for Windows) add-in that's available for Word 2007 upwards. It's a fix-it toolbox that will allow power Word users to fix document errors. You can find it at: http://www.mikestoolbox.co.uk
User avatar
TheNameOfTheGame
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2051
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Looking for small GIF loading routine

Post by TheNameOfTheGame »

Mug UK wrote: Thu Jun 30, 2022 3:59 pm I've got a 68000 linkfile code so you could bung all the images (packed in whatever format you want to use) into a single file. Less clusters used etc. if you're basing it on a floppy disk.
Well, thanks for the offer, but for this use case it probably wouldn't apply. :cheers:
troed wrote: Thu Jun 30, 2022 9:48 am netpbm is always your friend.

cat picture.gif | giftopnm | pnmquant 16 | ppmtoneo > picture.neo

(pnmquant makes sure to limit the number of colors to 16. If you pictures aren't already 320x200 or less you need a scaling step too)

You then script this line into supporting batches.

http://netpbm.sourceforge.net/

/Troed
Ok, little problem with this command string when converting the .GIF using ppmtoneo.

The resulting .NEO file is 32036 bytes which doesn't display properly. I guess that comes out to (2 word header?)(16 words palette)(16000 words data)

If I use GrafX2 to convert the .GIF, then the .NEO file is 32128 bytes and it displays properly.

Looking at the webpage https://www.fileformat.info/format/atari/egff.htm it shows the .NEO header format as this:

neochromeheader.png

So the 128 bytes before the source that GrafX2 prepends should be the correct header.

Can the ppmtoneo tool output a header like this for its NEO files?
You do not have the required permissions to view the files attached to this post.
User avatar
TheNameOfTheGame
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2051
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Looking for small GIF loading routine

Post by TheNameOfTheGame »

Weird, browsing the source for ppmtoneo at https://sourceforge.net/p/netpbm/code/H ... ppmtoneo.c it seems that it is supposed to account for the 128 byte header:

ppmtoneoheader.png

Wonder why that isn't happening when I run it? Has to be because they are using FSEEK on stdout. It's not working in my shell (bash).
You do not have the required permissions to view the files attached to this post.
neanderthal
Captain Atari
Captain Atari
Posts: 298
Joined: Sun Jul 10, 2016 10:58 pm

Re: Looking for small GIF loading routine

Post by neanderthal »

fseek() on stdout,,some modern stuff maybe? Anywho,thinking more of the tradeoff balance with compressed vs diskload time which folks mentioned before. Specially on floppy load thats something to think about.But if using native style stuff for originals some sort of RLE coding maybe?.Remember doing one for my old donkey game since it felt like a handy way of doing the screens.The benefit depends heavily on the picture data of course.
User avatar
TheNameOfTheGame
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2051
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Looking for small GIF loading routine

Post by TheNameOfTheGame »

After not getting the fseek in ppmtoneo to work through the shell to pad the header bytes I just let it make the 32036 byte file and then padded the header with null bytes through scripting so that it became a 32128 byte file. Kind of a kludge in post-processing but it works.

Now they are displaying correctly.
mlynn1974
Atari Super Hero
Atari Super Hero
Posts: 561
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: Looking for small GIF loading routine

Post by mlynn1974 »

I remember GIFs being very slow to read on a standard 14MHz A1200 with Personal Paint (?) so I think it would be a lot slower on a standard ST. GIF has loads of features you don't need for 16 colour graphics like support for animation, 256 Colour Palette, LZW encoding which a reader would have to implement or at least be aware of. It would be much faster to load in a standard .NEO and get a bit of compression using Pack ICE or something like that with a commonly available depack routine.
Still got, still working: Atari 4Mb STe, 520STFM (x2), 2.5Mb STF, Atari 2600JR, Flashback 8 Gold.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).
User avatar
metalages
Captain Atari
Captain Atari
Posts: 224
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: Looking for small GIF loading routine

Post by metalages »

would be efficient to convert from planar to chunky then compress with regular lzw (arj depack avaliable somewhere for instance)

In the old existing format the tiny format was a compressed graphic format

https://www.fileformat.info/format/atari/egff.htm
User avatar
troed
Atari God
Atari God
Posts: 1590
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Looking for small GIF loading routine

Post by troed »

TheNameOfTheGame wrote: Thu Jun 30, 2022 7:56 pm Wonder why that isn't happening when I run it? Has to be because they are using FSEEK on stdout. It's not working in my shell (bash).
Nice find. I think you should post an issue on the project.

https://stackoverflow.com/a/25329811

/Troed
simonsunnyboy
Moderator
Moderator
Posts: 5482
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Looking for small GIF loading routine

Post by simonsunnyboy »

Just for the record I never encountered a .NEO file that used other metadata than the palette.
I only grab my palette ans ignore the rest. Works good enough.

Regarding GIF, I would suspect that having a apacked NEO picture being unpacked by n ST native routine will be faster than a GIF decoder which will need to implement dithering.

All St based GIF viewers/tools I saw take seconds to decode a file and it looks like sh*t.
Offload this to a PC tool, store as NEO and maybe pack for the ST will be much more efficient.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
elliot
Captain Atari
Captain Atari
Posts: 164
Joined: Tue Mar 17, 2009 2:00 pm

Re: Looking for small GIF loading routine

Post by elliot »

simonsunnyboy wrote: Fri Jul 01, 2022 3:05 pm Just for the record I never encountered a .NEO file that used other metadata than the palette.
I only grab my palette ans ignore the rest. Works good enough.
I thought that NEO format could also store a palette shift, for example (classic image that came with it) a waterfall which shifted a couple of whites and blues to "animate" the image. Maybe the Degas format could also do it but I do not remember.

I also agree, loading a compressed image and decompressing is faster than a floppy and I suspect faster than an old school mechanical hard disk. A compressed image is small (maybe 4K-6K) and only takes a moment to unpack but a full image is 32K plus palette. I suppose if you made a very incompressible image (say static in multicolor) then it would not be but...
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
simonsunnyboy
Moderator
Moderator
Posts: 5482
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Looking for small GIF loading routine

Post by simonsunnyboy »

elliot wrote: Fri Jul 01, 2022 5:20 pm
simonsunnyboy wrote: Fri Jul 01, 2022 3:05 pm Just for the record I never encountered a .NEO file that used other metadata than the palette.
I only grab my palette ans ignore the rest. Works good enough.
I thought that NEO format could also store a palette shift, for example (classic image that came with it) a waterfall which shifted a couple of whites and blues to "animate" the image. Maybe the Degas format could also do it but I do not remember.
Yes that is possible however I never had a need for that in my productions. Not to mention most tools do not export that data, e.g. popular paint packages beside Neochrome itself. Basic .NEO is widely supported by tools.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
rockyone
Atari Super Hero
Atari Super Hero
Posts: 543
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Looking for small GIF loading routine

Post by rockyone »

I prefer PI1 which can be compressed to PC1 32128 byte NEO files only have one color cycle The Degas Pi1 files, 32066 bytes, 1 to 4 color cycles and assembly compression/decompression routines are on this site.
elliot
Captain Atari
Captain Atari
Posts: 164
Joined: Tue Mar 17, 2009 2:00 pm

Re: Looking for small GIF loading routine

Post by elliot »

I remember way back using Double Space on old slow 386 machines with crap HDs, they would be quicker after as small file loads and decompression was faster than pulling large files from disk PLUS you effectively had more space.
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
Post Reply

Return to “680x0”