JPEG bounty captured, parrot unharmed
Posted by Steve Revill Thu, 02 Jun 2016 20:06:00 GMT
Ahoy there! Any land lovers who watch the recent changes to RISC OS will have noticed a recent wave of activity in the area of JPEG, marking the completion of this bounty.
JPEG images are most commonly encountered from digital cameras or similar real life pictures. They achieve very high compression ratios by relying on the design of the human eye (the one without a patch over it) where brightness detail is more important than colour detail.
Extensive update
Many of the bounties are by their very nature quite wide reaching – the bounty scheme was set up to tackle larger pieces of work than volunteer developers can manage in their limited shore leave. This one in particular involved working on several components of both the operating system ROM and disc applications where JPEG images are accepted.
SpriteExtend
This has received most work as it is central to RISC OS’ JPEG decoding. The Risc PC was the first machine to include a SpriteExtend module with JPEG capabilities in RISC OS 3.60, loosely based on libjpeg version 4 released in 1993.
JPEGs come in many different varieties now, but at the time of version 4 this was only the baseline type from the standard.
Later, as processing power increased and people started connecting computers together in a wide area network to share images the progressive JPEG was added. This rapidly delivers a coarse image with finer and finer detail being added as more of the file arrives.
Delivering an image in progressively finer detail
Later still, after the patent expired on the more efficient Arithmetic compression algorithm, both arithmetic and progressive arithmetic encoded images became possible.
The number of colour formats also increased beyond the original YUV used in baseline images to add CMYK, YCCK, and RGB colour spaces. The latter also meant it was now possible to create a lossless JPEG starting from an RGB sprite, since the RGB to RGB transform does not lose any information and the subsequent Huffman or Arithmetic compression is already lossless.
Bringing SpriteExtend up to date means it now supports a sea of different formats:
- Baseline
- Extended sequential using Huffman or Arithmetic
- Progressive using Huffman or Arithmetic
- All valid power-of-two subsampling ratios at 8 bits per sample
- YUV, CMYK, YCCK, and RGB colour spaces
- Lossless encoded using RGB colour space (note, this isn’t JPEG-LS/JPEG-2000 which is a different standard entirely)
ChangeFSI
Where possible ChangeFSI will use the decoder from SpriteExtend, but where that is not possible (for example some of the more esoteric non-power-of-two resampling ratios) it throws the image overboard to djpeg which is the command line decoder in the reference implementation. Also included is cjpeg which can compress a bitmapped image back into a JPEG. Both of these have been updated to version 8d where previously it was using version 6b circa 1998.
CompressJPEG
This module, provided inside !System, takes lines of sprite image data and returns a baseline JPEG. A few small bugs have been fixed in the module, and a new SWI ‘CompressJPEG_Comment’ has been added which allows JPEG images such as photos to be tagged with text such as where the photo was taken. Although the text isn’t shown as part of the image, many popular editors will provide this in the image information dialogue box.
Other applications
Any application which hooks into the JPEG SWIs (such as Paint and Draw) will also benefit immediately, though they themselves haven’t been changed – for example dropping a CMYK format picture into Draw would load it.
For reference, the version numbers are
- ChangeFSI 1.58 or later
- SpriteExtend 1.76 or later
- CompressJPEG 0.08 or later
all three of which are based in part on the work of the Independent JPEG Group.
Keep donating
There are many other bounties on the horizon, so if you’ve got some pieces of 8 to spare be sure to surrender them on the bounties page.
This is fantastic work, well done all involved.
However, to “finish” the JPEG stuff, it would be really good to have JPEG export in !Paint (esp for screengrabs). At present this is a two-step process on RO5 (save as sprite, convert with CFSI) and many folks don’t immediately see how to do it. For tech support, sending JPEG screenshots is handy via email.
This is one area where RO Adjust !Paint is still ahead (it also does PNG). It’d be very nice if this gap could be closed.
Fantastic indeed – great stuff.
Andrew: I think there’s some debate about whether Paint ought to be in the business of loading and saving non-sprite formats. I don’t have a problem with it personally, but I can see some logic in Paint remaining focussed as a sprite editor, and other apps dealing with general image conversion/viewing.
In terms of opening up email attachments, any modern machine will come with ChangeFSI and PrivateEye, both of which can handle JPEGs and PNGs. Arguably PrivateEye is the thing to use here, as it’ll handle transparency, etc., which Paint won’t do for a fair while. And it’s a very nice app to use, too.
Thanks for the comment, Chris. I can see that argument, although please forgive me for not being swayed by it.
I agree that that is the traditional RISC OS way. However, in an era of Raspberry Pi, and people trying RISC OS for the first time, there’s a natural expectation for the built-in image editor to handle common file formats (one way or another).
Whilst I appreciate that 3rd party apps allow (for example), JPEG screenshots, leaving the core apps unable to handle standard file formats for “purity” reasons isn’t too helpful.
Users familiar with other systems don’t expect to have to use converter applications to handle such common formats, and doing so feels clumsy (I’ve been told so, recently).
I’m more concerned with export, really, rather than import (because as you’ve said, !ChangeFSI will kick in when a JPEG or PNG is double-clicked).
I can quite agree with my customer who (paraphrasing) said – “In 2016, it really isn’t OK to not be able to save a sprite that you’re working on in a form that can be emailed or used elsewhere without resorting to converters.”
I’d point to equivalent apps on Windows (MS Paint) or Linux/Mac (??).
These apps support saving as BMP (ie. native sprite), JPEG, PNG, GIF and TIFF. That’s the yardstick/bar that has been set.
I supported this bounty and am very pleased to see it complete. I agree that export as JPEG from !Paint is important (RO6 can do this, as well as export as PNG) and hope that this will emerge in due course.
Excellent work by all concerned.