Quo Vadis JPEG - Another update

[thorfdbg]

Hi folks, here is another update of the new JPEG standard in the making. There is a new version of a proposal for this recent JPEG call here: https://github.com/thorfdbg/libjpeg.git Basically, what is new here is that there is an optional experimental noise-shaping algorithm enabled by -N which will better spread quantization errors in the HDR residual signal. As there is also a call from VESA for a high-speed online compression for video signals, I also tried to answer that and included a very slim variant of SPIHT for answering this call. It is a lossy to lossless compression algorithm operating only on lines, using the 5/3 wavelet and an un-encoded line version of SPIHT to compress (actually truncate, since there is no entropy coding) the signal. Works fairly well given its simplicity. I should also say that Guido Vollbeding (one and only member of IJG) seems to follow a different route and tries to establish a not-backwards compatible codec for HDR or lossless compression. Why that is a good idea (that is, to loose backwards compatibility, and *not* picking one of the existing standards in this area, e.g. JPEG LS or so) is beyond me. After all, there are already more than enough lossless/HDR image formats to pick from, and I don't see the need for another (non-compatible) one. But judge yourself...

[Stephan Busch]

Can anyone please provide compiled version so that I can test lossless compression? And where can I find Guido Vollbeding's lossless implementation?

[thorfdbg]

Can anyone please provide compiled version so that I can test lossless compression? And where can I find Guido Vollbeding's lossless implementation?

I can certainly send you a binary for Linux. I don't care about windows, and I don't care about wasting my time with Visual Studio. What I can also send you are measurement results on the JPEG test image set.

However, before we proceed, let's make an important statement: The major goal of this development is backwards compatibility (e.g. old code can decode the images ok, though not 100% lossless). The Vollbeding implementation is not compatible (it is a new code) to JPEG. Requiring backwards compatibility has, however, important impact on the compression performance: If you need that feature, you cannot compress as good as you could without it. Basically, what you get is approximately the same compression performance as PNG with the backwards compatible implementation. This is of course not as good as JPEG 2000 or JPEG LS.

[Shelwien]

http://nishi.dreamhosters.com/u/jpeg_tr03_v0.rar

Got me another bug in IntelC, but somehow that file wasn't necessary(?).

codestream/residualsequentialscan.cpp(93): internal error: assertion failed: lower_expr: bad kind (shared/cfe/edgcpfe/lower_il.c, line 17719)

    m_Stream.OpenForRead(io);

[thorfdbg]

http://nishi.dreamhosters.com/u/jpeg_tr03_v0.rar Got me another bug in IntelC, but somehow that file wasn't necessary(?).

 codestream/residualsequentialscan.cpp(93): internal error: assertion failed: lower_expr: bad kind (shared/cfe/edgcpfe/lower_il.c, line 17719)      m_Stream.OpenForRead(io);

residualsequentialscan is not part of the distribution (or at least should not). It is indeed not needed. The logic for residual scans is in "residualscan" and "residualhuffmanscan" (the former for the AC coded, the latter for the Huffman coded version.)

[pat357]

http://nishi.dreamhosters.com/u/jpeg_tr03_v0.rar

Gives an error like :

the requested URL /u/jpeg_tr03_v0.rar was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

[Shelwien]

Apparently my server was restored from a week-old backup or something - I compiled it and uploaded again though.

[thorfdbg]

Just updated the code today once more. I mostly cleaned up the scan management and removed a lot of code duplications - all "differential" scans have been merged into the regular scans since the differences are very minor anyhow. I also downloaded the 10918-2 test streams from ITU and made a complete test with the official JPEG streams. I had to make a couple of fixes, mostly in the lossless huffman and lossless arithmetic case (not in the residual huffman case, which is a backwards compatible extension). The resulting code should now be fully conforming to JPEG/10918-1 and is also fully tested with 10981-2.