RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Bounties →

Bounty proposal: JPEG Support

Subscribe to Bounty proposal: JPEG Support 19 posts, 12 voices

 
Apr 28, 2014 6:11pm
Avatar Richard Keefe (1495) 81 posts

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.

 
Apr 28, 2014 6:18pm
Avatar David Feugey (2125) 2541 posts

+1

 
Apr 28, 2014 7:21pm
Avatar Rick Murray (539) 10304 posts

– 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.

 
Apr 28, 2014 8:12pm
Avatar mark stephens (181) 97 posts

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.

 
Apr 29, 2014 12:09pm
Avatar Michael Drake (88) 310 posts

– Lossless v9 files

I’m not sure that’s worthwhile.

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

 
Apr 29, 2014 7:02pm
Avatar Richard Keefe (1495) 81 posts

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.

 
Apr 29, 2014 7:18pm
Avatar Rick Murray (539) 10304 posts

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 necessary1 when the JPEG renderer was first released, it is still necessary1 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).2

1 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.

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

 
Apr 29, 2014 8:46pm
Avatar David Feugey (2125) 2541 posts

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).

 
Apr 30, 2014 11:44am
Avatar Alan Buckley (167) 218 posts

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.

 
Apr 30, 2014 9:50pm
Avatar Richard Keefe (1495) 81 posts

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.

 
Apr 30, 2014 11:06pm
Avatar Martin Bazley (331) 384 posts

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?

 
May 1, 2014 6:17pm
Avatar Richard Keefe (1495) 81 posts

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

 
Jan 7, 2015 12:09am
Avatar Steve Revill (20) 1337 posts

See our new bounty here.

 
Jan 18, 2015 1:50pm
Avatar William Harden (2174) 244 posts

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?

 
Jan 18, 2015 7:27pm
Avatar Jeffrey Lee (213) 5820 posts

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.

 
Jan 19, 2015 3:51pm
Avatar William Harden (2174) 244 posts

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.

 
Nov 2, 2016 1:41pm
Avatar Trevor Johnson (329) 1652 posts

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?

 
Nov 2, 2016 8:32pm
Avatar Rick Murray (539) 10304 posts

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.

 
Nov 2, 2016 10:46pm
Avatar Steffen Huber (91) 1597 posts

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.

Reply

To post replies, please first log in.

Forums → Bounties →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Discussion of items in the bounty list.

Voices

  • Richard Keefe (1495)
  • David Feugey (2125)
  • Rick Murray (539)
  • mark stephens (181)
  • Michael Drake (88)
  • Alan Buckley (167)
  • Martin Bazley (331)
  • Steve Revill (20)
  • William Harden (2174)
  • Jeffrey Lee (213)
  • Trevor Johnson (329)
  • Steffen Huber (91)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys