just came back from the JPEG meeting in Paris (actually, Saint Denis near Paris), and it is probably worth an update on what is going to happen. Actually, quite interesting as we have now three open calls for proposals. But one after another:
* There is a call for proposals for a backwards compatible JPEG codec for coding of HDR images. That is, a codec that encodes (and decodes) > 8bpp images with a 8bpp base layer in such a way that any JPEG (10918-1) decoder can decode it directly. This is of course in line what you already have with the libjpeg codec I posted here a while ago, except that you want to have a smarter tone mapping than just the downshift implemented in the 0.2. The 0.3 will be rolled out in the near future and will contain a smarter base layer computation, so stay tuned here. The call also requests for lossless coding of such images - that's already available.
I should state that the "lossless one block mode" of the IJG code is not 10918-1 compliant and hence does not address such needs (note to all: This is *not* a JPEG codestream it generates in such a case - avoid! - and it is unlikely that we will standardize anything *not* backwards compatible to 10918. There are already many lossless standards such as LS, and nobody sees the need of creating another lossless one.)
* We requested liason with MPEG to cooperate on an image codec based on HEVC (the second thing that was already mentioned earlier). HEVC requires a couple of extension to be suitable for that, for example higher bitdepth and larger gammut, but its I-frame compression is a very neat image codec already, so there is likely only a couple of minor extensions to be discussed with the committee "next door". Whether MPEG picks this up or not is still to see.
* We got one input from VESA for an extremely light-weight image compression for computer-display interfaces with limited bandwidth. Basically, VESA is asking for a "lossy compressed" version of HDMI to address the needs of larger screens while keeping the bandwidth limited. There is no frame buffer assumed here, and all one has for granted is a two-lines image buffer at the decoder. Of course, this will be implemented in hardware.
Thus, yes, we're moving foreward, and - I am happy to announce - quite in the direction where I want to move. Stay tuned, there will be updates for the software soon.