Bounty Proposal JPEG

High Level Description
Update SpriteExtend to support latest Jpeg Formats (JPEG SWI’s)

RISCOS Currently supports JPEG (JFIF) files based on the IJG4 jpeg reference. This means that RISCOS is unable to directly make use of files that include the following features:
– Progressive / Interlaced
– Arithmetic Coded
– Lossless v9 files
– Adobe CMYK files

Phase 1
– Modify SpriteExtend so that the implantation of newer JTEG specs is much simpler in future
– Update SpriteExtend to support either the IJG8-Turbo or the IJG9a Jpeg Reference
– This would fix by implication bug no 349.

Phase 2
– Update SpriteExtend so that the user can chose the IJG (8T or 9a) implementation as a system setting / dynamically by file decoding
– Support NEON/SIMD instruction on ARM A8+ cores for optimal performance (select module during boot / automatic)
– Update other jpeg implantations eg ChangeFSI to match

I have £120 from Sales of Impression-X Beta & Donations to put into this Bounty

Perhaps that the bounty could be more attractive with the inclusion of new file formats (PNG…)? Or some tools to help adding new formats to SpriteExtend.

Anyway, that’s a good idea.

NB: do you have a website for the beta version of Impression-X and people who want to get access to the beta program?

RISCOS Currently supports JPEG (JFIF) files based on the IJG4 jpeg reference. This means that RISCOS is unable to directly make use of files that include the following features:
– Progressive / Interlaced
– Arithmetic Coded
– Lossless v9 files
– Adobe CMYK files

Progressive JPEGs ought to be supported in this day and age – they are widely used.

Arithmetic, unlikely. Wiki says: “The JPEG standard also allows, but does not require, decoders to support the use of arithmetic coding, which is mathematically superior to Huffman coding. However, this feature has rarely been used as it was historically covered by patents requiring royalty-bearing licenses, and because it is slower to encode and decode compared to Huffman coding. Arithmetic coding typically makes files about 5–7% smaller.”

Lossless v9 – is that part of JPEG-LS or JPEG-2000?

Adobe CYMK – quoting Wiki again: "However, Photoshop generally saves CMYK buffers as four-component “Adobe JPEGs” that are not conformant with JFIF. Since these files are not in a YCbCr color space, they are typically not decodable by Web browsers and other Internet software.". I had a CYMK picture sent to me and I tried extracting each part by hand to recombine as CYMK layers, but it didn’t want to work like that because the software kept trying to interpret it as RGB. If you hav a four-component thing being interpreted as a three-component thing, it ain’t gonna work. So I asked for a copy saved as a normal type of image and I received a 40MiB PNG in reply. Goodness! I fiddled the DPI to something sane and saved it as a perfectly decent 5MiB JPEG. ;-)
Aaaanyway – what would you suppose RISC OS do with a CYMK JPEG? Display it (converting on the fly to RGB)? What if somebody wants to edit it? Should it stay as CYMK? Does RISC OS have support for CYMK sprites at this time?
It might be better to leave this one until there is better “back end” support.

However – may I make a suggestion? If SpriteExtend comes across a known image file that it does not understand, it really ought to raise an event or something, so if there should be software that can deal with CYMK JPEGs, it can hook into SpriteExtend and deal with it.

Actually, it ought to be possible to register yourself with SpriteExtend with a file type and a handler address, so I could – for example – write a BMP decoder, which would be called (get info? decode image? decode line?) by SpriteExtend as and when necessary. So, you load my BMP decoder module, suddenly clicking on BMP images “just works”. This could be expanded for whatever other sorts of images people take a liking to. In fact, the JPEG decoding could be pushed off to a specific module so all SpriteExtend really needs to understand is sprites and “some other stuff over there”.
Extra Brownie Points if the spec is capable of optionally registering handlers for image saving too. ;-)

Actually, it ought to be possible to register yourself with SpriteExtend […] for image saving too. ;-)

Yep, it would be very useful. I’m not on system things, but I did write some image decoders a long time ago. Give me a framework and some examples and I could make it again.

IMHO, RISC OS needs more facilities for developers (other examples: framework for image file systems ; bbc basic lib for network access ; simple filters for keyboard/clipboard interaction ; etc.).

I know how to code in C, but don’t really like to use the PRM :)

but don’t really like to use the PRM :)

I can recall having to examine bundled desktop applications (which were written in BASIC), add things like VDU7 in various places to try to work out what was going on. That was before the PRMs were produced. Having the PRMs makes things much easier. Is it that you just want the challenge of guessing and the satisfaction when you guess correctly?

I’m much more on algorithms and code than on frameworks, that are too big for me.
Not patient enough, probably.

See our new bounty here.

A recent NetSurf bug report involves an Adobe CMYK JPEG/EXIF, which can’t be converted to anything displayable.

We’ve uploaded a zipfile which we believe is a good-enough-for-beta-testers – it’s a softloadable SpriteExtend module to show some progress on the JPEG bounty. It’s built for a generic 32 bit machine, so doesn’t have any fancy ARMv6/v7 instructions in it, and can be softloaded on anything Risc PC or later. Please help us by giving this a spin to shake-out any remaining issues.

Bug fixes:

• 0xFF padding is now accepted in the marker fields, previously the JPEG decoder accepted these, but the up front check didn’t, so they were being erroneously rejected
• Workspace for greyscale JPEGs now calculated correctly, was 3x too big before

New features:

• Handles 4 component JPEGs (CMYK and YCCK colour spaces)
• Handles RGB colour space JPEGs
• Decodes any power-of-2 YUV subsampling ratios (adds 1×4 2×4 4×2 4×1) compared with current SpriteExtend
• Optimised cases for most common 2×2 subsampling direct to RISC OS pixel formats, other cases use slower 32 bit internal format

Not yet complete:

• Progressive and arithmetic JPEGs
• Optimisation pass
• Bug in error diffused dither causing a multicolour band

We’ve uploaded a zipfile …

The zipfile appears to contain SpriteExtension v1.68 (26 Sep 2015) … which is exactly the same as in RO5.23 (11 Oct 2015).

Can you confirm that the zip is indeed newer?

It is difficult to compare them directly because one is Iyo ROM and one is standalone. If they are different, it makes it very difficult to see which is being used!

Ooooh yes … it is easy to tell the difference!

I have a normal photo jpeg as pinboard background on my Iyo, displayed in 168×1050 16M, and normally if I drag windows around over it there is a very slight (but not annoying) delay as the jpeg is re-drawn in the wake of the drag. With the zip SA version loaded, it is much more noticeable, as you can watch the grey rectangles being re-drawn. Certainly annoying.

Geminus is not involved.

The zipfile appears to contain SpriteExtension v1.68 (26 Sep 2015) … which is exactly the same as in RO5.23 (11 Oct 2015).

Can you confirm that the zip is indeed newer?

Module version numbers + dates are generally updated automatically by a custom script that’s used to help check code into CVS. So chances are that it is new code, it just doesn’t look like it because it’s using the VersionNum file from the most recent CVS version.

The new module renders the wrong colours on omap 5432evm in netsurf when using render by os 16m colours, photo desk is the same as is David’s imagemaster, this maybe a problem with the htmi driver?..

It is difficult to compare them directly

ROM
*Help SpriteExtend
==> Help on keyword SpriteExtend
Module is: SpriteExtension 1.68 (26 Sep 2015)

Softload
*Help SpriteExtend
==> Help on keyword SpriteExtend
Module is: SpriteExtension 1.68 (26 Sep 2015) Development version
*

Ooooh yes … it is easy to tell the difference! … Certainly annoying.

That’s a much quicker way to tell the difference.

There is now a new version to test here.

It’s built for a generic 32 bit machine, so doesn’t have any fancy ARMv6/v7 instructions in it, and can be softloaded on anything Risc PC or later.

New features:

• Handles progressive JPEGs
• Handles arithmetic (and arithmetic progressive) JPEGs
• Does lazy colour conversion in 2×2 subsampling, so only the bits of the screen needing redraw are converted

Not yet complete:

• Optimisation of inverse DCT
• Bug in error diffused dither causing a multicolour band

No bug reporting about performance please – see the above release notes…!

No bug reporting about performance please – see the above release notes…!

Sorry, I’m not clear what you’re referring to. However having just tried the version available now, I can say that it let me load some jpegs into TechWriter which had previously failed with an error that SE couldn’t handle that jpeg format. However I have no idea what specific format detail was that caused this. TheAppThatCantBeCalledImageMaster and NetSurf both loaded them anyway, and the info on them shown by the former was the same as for other jpegs that had been fine.

Jim

No bug reporting about performance please – see the above release notes…!

Sorry, I’m not clear what you’re referring to.

Basically, don’t complain about it being slower than the ROM version of SpriteExtend (potentially both for sprites and JPEGs). The ROM versions of the module generally only have to target one CPU architecture, so it’s easy for them to make use of newer (faster) instructions. The softload version has to cope with everything from the past 20 years, so it only uses instruction which are safe for all CPUs.

If softlloading SpriteExtend was a more common thing this could be improved, but so far I don’t think it’s been enough of a priority for anyone to bother.