Sprite 2 Jpeg is an image converter, which allows you to convert sprites to Jpegs, and back again. It also accepts and outputs Clear files, GIFs, Targas, and it can handle deep sprites (24-bit colour). Note that for this last option, you need a version of ChangeFSI that can handle them.
Basically, S2J is an unholy matrimony between the purity of ChangeFSI and the foul, dank wretchedness of my code. So to run S2J, you'll need to have opened a directory containing ChangeFSI, though not necessarily run it. Done that ? Right.
Uh... what now ?
You can: drag an image file onto S2J, and see what happens, or examine the options. I'm going to go over the options first
here, but don't let that hold you back. Click on the iconbar-icon to open the options window, or select 'Options...' from the menu. Inside it is a scrolling list of options, which can be saved, OKed, or Canceled if you've changed your mind. But before I go through the options, I'll explain a little about the various types of image file, and how they work.
First, we have Sprites, which are the standard on the Arc. They have the advantage that everyone can read them, but this isn't always true, because there are three main varieties: old ones, which everyone can read, Risc OS 3.1 ones which sometimes can't be read on machines without Risc OS 3.1, and new ones, for people with Risc OS 3.5, which support 24-bit colour. CC have also got their own formats, but no one uses them (unless maybe you've got a ColourCard).
Then, there are Clear files. These are easy to use from a programmer's perspective, and there is only one Clear standard, so they really are pretty standard. Useful for using full colour images on old machines. They're almost identical to a similar format on other platforms, Portable BitMaps, or PBMs.
Jpeg files: these contain, almost always, real-world images (ie. scanned, digitised, whatever), in full (24-bit) colour. This normally takes up a lot of disc space (a 768 x 512, full colour Clear file could easily take up over 1.5 Mb. However, the identical Jpeg file is cunningly compressed: first, information that is so subtle it's invisble to the human eye is removed. Then, it's compressed, which means it takes as little as 25-100k or so - that's a reduction to about 2% of its original size. Because Jpeg allows you to choose the quality of the final image, balancing it against file size, this means it's well good.
GIFs are 256 colour, non-lossy compressed images from the PC world. The compression is only around 50% or so, and they're not very good for quality work.
Targas, well I have no idea of anyone who uses these. They are currently unsupported, but they might be soon (which is why the option is there. You can compress them into Jpegs, though (you just can't decompress into them).
Right, the options: they divide into the compression options, for compressing an image into a Jpeg, and the decompression options (if you can't work out what that is, then I'm not going to tell you). From top to bottom:
Quality: From 0 (ultra low quality / tiny files) to 100 (no picture loss, anti-compression). About 75 is recommended, but if you just want a low quality thumbnail, you can easily go as low as 40. A quite interesting thing to do is reduce it to about 3, which will give a very odd image, which can't be recognised normally, then squint at it, and it's quite incredible the amount of detail your brain can fill in. Weird.
Optimise file size: at the expense of compression times, reduce this file size. This does not affect quality at all.
Debug: nothing, but it's there for completeness
Extra: you can fill in command line options here (ie. -q 100), but all the ones currently implemented are available as buttons anyway. It's basically for future versions of the compressor. I'd leave it alone, cause it don't do nothing much yet.
Non-interleaved: not implemented in the compressor yet.
Arithmetic coding: not implemented, and not likely - it requires a whacking great license fee.
And the decompression options:
Quantize: reduce the number of colours down to amount specified by you. My advice is to do this in ChangeFSI - output to Clear or 24-bit sprite, then choose the number of colours you want in ChangeFSI. Max value is 256, min 8. Again, it's not much use.
1 pass quantization: use one pass quantization. Needs less memory, and is faster, but produces a lower quality image.
Grey-scale: produces a grey-scale image
Cross-block smoothing: improves the image at very low quality settings (10 - 20), but may make it worse at higher settings.
Debug: as above
Extra: as above
So: to make / unmake a Jpeg file, drag an image file onto the iconbar icon. If it's not a Jpeg, then S2J will recognise a few formats, and try it's hardest with most others; there are very few formats it won't work with. If it is, then it will decompress, and...
The save window will open. You can select the file-type to save if you dragged in a Jpeg; if not, you can only ouput Jpegs. The choices are: Jpeg, Clear, Sprite, 24-bit sprite, GIF and Targa. Save it in the normal Risc OS manner.
Well, that's pretty much it. Send fan mail / credit cards / money / letters / PD / letterbombs / no, not letterbombs - sorry, as you were / sugestions / bug reports / anything (except letterbombs) to:
The Intelligent Stoat, c/o
David Rodgman
Laurel Farm
Upper Strode
Winford
Bristol
BS18 8BG
Oh yeah, I ought to thank the Independant JPEG Group here, for their JPEG compressor / decompressor. Thanks also to: Doggysoft (for the WimpExtension module), me, Dave McCartney of the Datafile. This software is based in part on the work of the Independent JPEG Group. But they aren't responsible for what may happen to your hard disc after running this. And neither am I, for that matter.
I probably ought to say: "The Graphics Interchange Format(c) is the Copyright property of CompuServe Incorporated. GIF(sm) is a Service Mark property of CompuServe Incorporated." as well here, but I don't feel like it, so I won't.
