Re: rududu image codec

Nicolas wrote:
Thomas Richter a écrit :
What is your definition of "bit stream"? Otherwise, it is easy to setup a context for
the entropy coding that does not compress at all, or otherwise interrupt the entropy
coding and continue it from that point on later. This technique is used in J2K.
Sure you can output uncompressed bits through arithmetic coder, but your bits are slow to output, slower than just a shift (as without an arithmetic coder). And interrupting an arithmetic coder has an overhead which is not acceptable if you do it every few ( <16 ) coded symbol.

It has a complexity overhead, not a rate overhead. Besides, a reasonable MQ coder implementation is *very* fast (one addition, one comparison in the common coding path). That said, it doesn't mean your approach is bad.

Look into J2K, it uses context modeling from nearest neighbours to compress the sign bit.
I know that, but from my point of view it's not "simple enough" (too much operation / coefficient). Maybe I'll implement it, but I doubt the compression gain will be enough to justify the CPU time (always according to my goal).

In some case or another, you need to check "related" samples for a context model of the sign bit. If you don't want to invest for this complexity, don't expect a gain. (-:

Have you made perceptual measurements of the quality? If not, I can make the ms-ssim measurement
tool available that is currently used by the JPEG to evaluate HDPhoto aka JPEG-XR. PSNR doesn't have
to say much.
You already sent me the mssim source code, and I thank you for that. But I have not made perceptual measurement because current optimizations are made for psnr, and developing for psnr is easier. I'm planning to implement perceptually driven quantization and I'll switch to ssim at this point.

That said, we will continue to go check for good metrics at the JPEG. SSIM is not the last word on this. All I'm saying at this time: Check whether you can adjust your code to other metrics.

How about scalibility/flexibility?
As I said here and in the web site, there is no quality scalability (for speed reason and lack of use for video compression), only resolution scalability (as it's a wavelet codec). I'll also implement adaptive quantization, so perceptual quantization / ROI will be possible.

How about complexity? Can you give estimates how fast is it compared to JPEG/JPEG-XR/JPEG2000?
Current implementation (plain C++) is about as fast as imagemagick's convert utility when converting to/from JPEG. And the wavelet transform uses about half the time.

Sounds fine to me. Can this be partially fit into some kind of "low-complexity" J2K? For that, we would want to keep the codeblock structure of J2K, just replace the EBCOT coder by something simpler.

Note that this requires that there are no inter-band decorrelation processes (unlike what happens in the EZW or SPIHT).


So long,
Thomas
.

Relevant Pages

  • Re: Need a bit of information about Compression
    ... What my question is that "What is the best possible method to compress ... coding can result. ... input stream to be seen in parallel, and only requires the ability to ... shift by two and three positions, so a barrel shifter is replaced by ...
    (comp.compression)
  • Re: Compress a subset of bits form
    ... Google entropy coding, arithmetic coding, run-length coding, etc.. ... I cannot comment about combinatorics, but I know that the arithmetic coding ... Another possibility is to use an arithmetic coder. ...
    (comp.compression)
  • Re: Compress a subset of bits form
    ... run -length coding, I will use approximately 68 bits in on average. ... Google entropy coding, arithmetic coding, run-length coding, etc.. ... I cannot comment about combinatorics, but I know that the arithmetic ... Another possibility is to use an arithmetic coder. ...
    (comp.compression)
  • Re: THE NIGHTLIGHT CHALLENGE
    ... > posts about how great his stuff is and how arithemtic sucks ... The mentioned coding gaps are, ... probabilities correctly except in special cases, and even then, it ... > compress this arithmetically. ...
    (comp.compression)
  • Re: Recommend Compression Algorithm for Student Real-Time Videoconferencing Project
    ... coding or Huffman coding is okay, ... higher throughput on an original Pentium. ... I wrote a Huffman video compressor which managed over 200 Mb/s on a 333Mhz Celeron. ... Incidentally, if the raw image is RGB, you can compress it down to 37.5% of its original size just by 4:1:0 chroma decimation. ...
    (comp.compression)