Re: 4-level image compression ?


"Thomas Richter" <thor@xxxxxxxxxxxxxxxxx> wrote in message
news:h2kntk$rjl$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
cr88192 wrote:


I had thought he meant 2bpp, not 4bpp...

he says 4 gray levels, not 16 gray levels...

I have my doubts as to how well the coding scheme used by JPEG-LS will
work with 2bpp images.

Of course it will work.


the question though is, how well?...

sadly, I can't answer as presently I don't know the specifics of its coding
scheme, but it is sounding like it is using rice-coding for the residuals.

rice coding would take at least 2 bits per item, meaning it is not a good
scheme (a lumping scheme would be needed, ...).

2-bits per item with 2-bpp input means no compression, or worse, inflation.


FWIW, if the input were 1bpp, I would likely have suggested a scheme based
on xor...


also, in special-use cases, dragging around a full JPEG-LS or JPEG-2000
codec may well be too expensive...

JPEG-LS, expensive? I beg your pardon, but this is very light-weighted.


compared to?...

well, I guess the big question is what kind of CPU and how much RAM is
available, how much space is available in the process image, ...

a general-purpose library could easily take 10s of kB to store the code, and
maybe a bit more in order to run (say, 100-200kB?...).

by most definitions a PNG codec is light-weight as well, but there are cases
where PNG may well be too expensive...


as well, a little bit-twiddling and a LUT can handle much of the process
as well.

Not quite.


depending on available RAM, FWIW, there may not even be enough for a
table-based huffman decoder...

of course, the LUT would be a good way to prepare the data for a huffman
compressor (or deflate).
this way, we can worry not as much about the actual encoding, as to how to
condition the bits so they best go through huffman. a scheme which reduces
most of the bytes to 0x00 doesn't hurt, and LZ would be better, if
affordable.


another strategy would be to use a specialized PAQ-style codec, which could
be adapted to this particular use case. the problem would be, however, that
it would deliver good compression at the cost of poor speed (or how most
people use the term, performance...).

(a PAQ-style coder could be made to work, and would require approx 512 bytes
for the context...).


I guess the big question is "how much?"

I was making a conservative guess:
maybe it is in the kB range?...


one can probably infer that the space is small, after all, the issue of
compressing 2-bpp images came up in the first place, and from the way the
message is written, it is very well possible it is in this range (or, maybe
the low MB range, but with a lot of RAM needed for other stuff...).

similarly, since it is mentioned that the final version would be in
assembler, it can be inferred that either CPU time or memory is rather
tight, ...


sadly, to know how to best compress images in this case would likely require
experimentation...


So long,
Thomas


.

Relevant Pages

  • Re: 4-level image compression ?
    ... he says 4 gray levels, ... I have my doubts as to how well the coding scheme used by JPEG-LS will work with 2bpp images. ... It also includes a runlength code, and since the images are 2bpp, this would also be used quite a lot. ...
    (comp.compression)
  • Re: 100 megaton bombs atop Saturn V rockets
    ... >>since it could be made to work without compression. ... Super" the scheme for a self-sustaining combustion wave in uncompressed ... > Probably not, a) because fusion fuel is pretty light, and b) because ... cryotank of liquid deuterium, like the Saturn upper stage or the Shuttle ...
    (sci.space.history)
  • Re: 100 megaton bombs atop Saturn V rockets
    ... >>since it could be made to work without compression. ... Super" the scheme for a self-sustaining combustion wave in uncompressed ... > Probably not, a) because fusion fuel is pretty light, and b) because ... cryotank of liquid deuterium, like the Saturn upper stage or the Shuttle ...
    (sci.space.policy)
  • Re: Theory of Cryptography 2004 - Preliminary Program
    ... > I suspose about the simplist keyed compression ... > schemes is do a bijective adaptive huffman but you change ... > of BWT compression it would be much harder to break ... have been very enthousiatic in propagating your scheme, ...
    (sci.crypt)
  • Re: Packbits implementation
    ... then repeat AB a total of N+2 times. ... which one gave the best compression. ... I did a similar scheme once that checked not successive bytes, ... the decompressor is not much more compilcated. ...
    (comp.sys.apple2.programmer)