Bounty proposal: JPEG Support

It is not possable to render all Jpeg files that one finds, they tend to cause various error messages or worse.

RISCOS Currently supports JPEG (JFIF) files bassed 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

It is proposed that the SpriteExtend module be updated to support the IJG9a reference, with if possable reference made to the IJG8-Turbo implementation to make use of the SIMD Instructions available in the later ARM cores.

This would fix by implication bug no 349.

+1

– Progressive (Interlaced)

Wasn’t the later interlaced JPEG “patent encumbered” at the time?
That said, it looks like many have been trying it on → http://en.wikipedia.org/wiki/JPEG#Patent_issues

That said, I’d say +1 to interlaced. They’re quite widespread these days.

– Arithmetic Coded

Arithmetic coding may or may not be viable – http://en.wikipedia.org/wiki/Arithmetic_coding#US_patents – yeah, it’s a dumb headache, isn’t it?

– Adobe CYMK files

I had one of those once. Be aware – it was not CYMK. I never managed to get a ‘sane’ image from the data. I now know the colour model was “YCCK” which appears to be a messed-with version of YUV with the colour and luminance split apart…
In the end, I asked for the image to be sent as a CYMK BMP. A billion times larger, but at least I could make sense of it.

You need to convert YCC (which is YCbCr) to CMY and then include the K so you can do YCCK to CMYK. If you do not use color profiles you find black and white especially do not convert well.

– Lossless v9 files

I’m not sure that’s worthwhile.

See, for example http://www.libjpeg-turbo.org/About/Jpeg-9

My thinking was that the new JPEG support should be able if possable to render the largest number of found JPEG files – if possable and to provide performance if available.

My thinking was that the new JPEG support should be able if possable to render the largest number of found JPEG files

That’s a fair enough point. Now what you need to do is provide pointers to a reasonable number of said JPEGs to allow us to assume that the format in question is worth considering. Not as a “support everything” but to support that which is commonly found in the wild.

My PC image/photo editor supports normal and interlaced JPEG with an option to vary the ‘resolution’ of the colour encoding (ie 4:2:2). To my knowledge, since ~1999 it has failed to open maybe a dozen. It has failed to correctly decode several (that were not RGB; but MSIE failed on it too). Most worked. Real life downloaded JPEGs from regular websites. No fancy test suite stuff.

RISC OS could do with supporting interlaced JPEG natively. It was very necessary¹ when the JPEG renderer was first released, it is still necessary¹ now.

However – I must ask – wouldn’t it be more essential to provide OS level support for PNG than to support less-common types of JPEG? PNG is widespread. Stuff like !Paint ought to be able to load/save PNGs (inc. with mask).²

¹ Perhaps more necessary in the past than now as it helped ‘build’ an image over a slow modem connection. These days faster ADSL makes it less necessary, but you still find such JPEGs – some software just does it that way “by default”. It is probably helped by the unusual quirk that interlaced JPEGs are often (slightly) smaller than their baseline counterparts.

² I think “the other branch” does, doesn’t it? :-)

Hum. A good point would be to give the possibility to add some new format easily (with some ANSI C and ASM examples). SpriteExtend extensions :) I could then revive some code for high compression image format (fractal one).

However – I must ask – wouldn’t it be more essential to provide OS level support for PNG than to support less-common types of JPEG? PNG is widespread. Stuff like !Paint ought to be able to load/save PNGs (inc. with mask).

+1 for PNG support. It would be nice if we could have a general image file system like they do on the “other branch” which it was easy to write plug-ins/modules for to give support for other formats.

I think I read on the forums somewhere an opinion that the other branches API and/or implementation could be improved, but have completely failed to find the link.

The SpriteExtend code is based on IJG4 which is basically libjpeg (release 4). I’m suggesting that the software be rebuilt using release 9, or possibly release 8 ( with maybe a separate or runtime version that uses libjpeg-turbo release 8). This would enable all (if release 9 was used or most (99%+) if release 8 is used. I think the minimum should be release 8 as this would as well as providing progressive/interlaced JPEG’s would allow all pictures from Adobe (Photoshop / Lighroom) and any camera propriety formats to be rendered without conversion.

The SpriteExtend code is based on IJG4 which is basically libjpeg (release 4). I’m suggesting that the software be rebuilt using release 9, or possibly release 8 ( with maybe a separate or runtime version that uses libjpeg-turbo release 8).

So, something like the (apparently stalled) work going on in this branch of SpriteExtend then?

That is exactly the work I was trying to get completed.

See our new bounty here.

How is it proposed that the NEON/SIMD optimisations work? All the code being in C am I missing something? Surely the compiler compiles with switches pertinent to the platform?

Or is the proposal to recode chunks in NEON / SIMD assembler and switch to them where available?

Another question (probably for Sprow): I note there are chunks acquired from earlier iJTs in the code including some from 8) that is there. Would it be possible to describe what is in and where and what is not? Just a better feel for the code would be nice.

Finally – AIUI some GPUs have hardware JPEG decoders. Would it be possible to alter the HAL so hardware JPEG decoding is used in preference where available?

All the code being in C am I missing something?

The code isn’t all C – there are a few JPEG-related files in the Sources folder (jdcolor, jdhuff, etc).

Or is the proposal to recode chunks in NEON / SIMD assembler and switch to them where available?

I’d imagine that would be the preferred way of doing things, yes.

Finally – AIUI some GPUs have hardware JPEG decoders. Would it be possible to alter the HAL so hardware JPEG decoding is used in preference where available?

Assuming we have the docs, yes.

Another ‘newbie’ question on the subject. What is the difference between IJG and libjpeg? Are they different projects, related projects or the same project? I’ve found libjpeg8-Turbo and libjpeg9, but there seems some mismatch to IJT.

However – I must ask – wouldn’t it be more essential to provide OS level support for PNG than to support less-common types of JPEG? PNG is widespread. Stuff like !Paint ought to be able to load/save PNGs (inc. with mask).

+1 for PNG support.

+1

My 2p: If my understanding is correct, Sprites are either uncompressed or the compression used is lossless; AFAIK the latter applies to PNG. If Paint were to (optionally) export as (generally lossy) JPEG, reloading said JPEG back into Paint would generally render a slightly different result to the original image. The original image data may have been lost if not also stored in a lossless format, potentially resulting in a confused user.

Compression artifacts around high-contrast items (e.g. line art, monochrome System font) would be more obvious than for photographs.

If the RISC OS community is in the business of enabling computer literacy, mightn’t we want to be wary of potentially blurring the distinction between lossy and lossless compression via a direct Paint implementation?

Hi Trevor, nice to see you back.

I wasn’t aware that there was any official form of compression with sprite files.

I think, traditionally, RISC OS has coped better with JPEG due to some measure of support being baked into the OS. Our branch never received built in PNG support.

I’m not entirely sure I agree about distinction blurring, as even Windows Paint supports saving pictures in BMP (mono, 16 col, 256 col, 24 bit), JPEG, GIF, TIFF, and PNG. Worse, there doesn’t appear to be and quality setting, so who knows what sort of JPEG is actually created.
That is the XP build. Either Win10 does even more, or it has been dumbed down to the point where you get “picture” and no, you don’t get to know what sort of picture it is. ;-)

I think it should be reasonable not only to support JPEG and PNG (in addition to Sprite), but also for the user to understand the difference between the two. It is pretty basic stuff, and each has its purpose.

If the RISC OS community is in the business of enabling computer literacy, mightn’t we want to be wary of potentially blurring the distinction between lossy and lossless compression via a direct Paint implementation?

Don’t know if our community is in any business, but: no. Supporting JPEG import and export directly in Paint is just one thing: sensible. OK, maybe two things: sensible and long overdue. Same for PNG support.