Re: Differential intra-interchannel filters for RGB images lossless compression

> this does bring up a thought:
> why are the values for the filter types stored prior to each row?
> if I were designing png myself, I would have likely had all the filter type
> values in their own little area (maybe seperate, maybe as a prefix or suffix
> to the image data).
> why? because the values are likely to readily rle-compress...
I agree. I evaluate the predictor for the whole image and save the
predictor as a byte appended (and removed in the inverse process) in
the header. If I would do a scaline-oriented or area oriented
evaluation, I would do an analogous thing, reserving a separate area
for that kind of data that would be rather non consistent with image
data and so should not be mixed to have better compressibility.
This is one of the reasons why the 48 MB demo image linked on PNG site
is compressed to 114 Kb with PNG (90KB with higly optimized PNG) and to
only 9 KB with dif.
However, I must admit that in performance oriented and simplicity
oriented application it's useful to simply point to a row and to his
filter in a single pass rather than searching separately the filter in
the filter's data area and separately the related image data in his
specific area, but this IMHO is an issue that in a more parallelized
computing environment could become progressively less important.

> other thoughts would include splitting the image into seperate color planes.
> even a trivial filter, eg:
> Y=G U=R-Y V=B-Y
> works pretty well for lossless uses in my experience.
It's a simple form of interchannel differential, it's widely used in
multichannel audio compression and I was wondering why it's not used in
mainstream multichannel image compression, so I implemented it in dif
(Y=G U=R-Y V=B-Y is like my A-family filters).
Moreover, we can very simply correct the interchannel differential
prediction above in the form (my B-family filters):
Y=G U=R-Y V'=B-Y-U
That's like saying: if U prediction is inaccurate, V prediction could
be inaccurate too; we can use error in U prediction (U value) to
correct V prediction in V' prediction; if U and V prediction are biased
in the same direction it will make V' even worse, but if U and V
prediction are biased in different directions it will make V' better
than V.
Generally speaking odds are 50%-50% so A and B form should be
equivalent, but in the limited field of image data Appendix A shows
that this correction almost regulary lead to some more efficience on
image data.
That, implicitly done simply with a minus operation.

> of course, all this would increase complexity.
Well, yes, but as you can see in my source interchannel filters are not
so much complex to code.
>>From the computational point of view this lead to some more integer
addition/subtraction for pixel, so we are always in fast operations
fileld, note that dif filters are far than optimized (works on bytes
instead than on integers, save output to the disk instead of keeping it
in memory in order to be able to send data to arbitrary external
compressor) but filtering impose a negligible overhead also compared to
fasetst deflate compression, a differential approach to filtering
keeping using only very siomple and very fast math.

> then again, if all this is for personal uses or enjoyment, I guess it works.
Definitely! IMHO it's a pleasure to code and to test.
However, keeping code and test free as speech, may be also a productive
thing to do since when something is created, noone can know if, where
and when it could come out to be useful to someone.
I don't aim to set up a new standard in image compression formats
(there are plenty!), however, existing standards like TIFF, lossless
JPEG and PNG (or even, general purpose compression tools lacking image
compression plugins) could undergo revisions in next years like they
did in past years, since computing paradigms shifts (i.e. parallelism
is gaining importance on serial execution speed even in desktop
environment) and/or acceptable trade between complexity and speed
evolve.
So, here is my free as speech work that shows some results that can be
obtained in the field of differential filtering using interchannel
filtering, channel specific output and different families of
compressors instead of the plain deflate.
If lossless JPEG would implement, for a future revision, even
differential filters to be efficient on non photorealistic works, the
community shouldn't look only to TIFF and PNG standards but even to
newer experimental works, like mine.
If PNG and TIFF would undergo a revision, they will not need to
reinvent the weel and will jet know what to expect using interchannel
filtering and channel specific output and what kind and range of
improvements should they expect using newer compression algorithms, due
to my work and other works made publicly available.
If someone want to give a image compression specific plugin to a next
release of his compressor, similary, have publicly available many hints
to what to implement and what to expect.

.

Relevant Pages

  • Help creating PNG graphics using zlib libraries?
    ... I'm using the excellent Deflate/Inflate zlib compression library ... BMP and GIF. ... I can create the PNG headers, with all the image information about the ... My issue is with the filter byte in the PNG spec. ...
    (microsoft.public.vb.general.discussion)
  • Help creating a PNG with zlib libraries?
    ... I'm using the excellent Deflate/Inflate zlib compression library ... I can create the PNG headers, with all the image information about the ... My issue is with the filter byte in the PNG spec. ... I have a byte array Bwith all my image data in it. ...
    (microsoft.public.vb.general.discussion)
  • Help creating PNG graphics using zlib libraries?
    ... I'm using the excellent Deflate/Inflate zlib compression library ... BMP and GIF. ... I can create the PNG headers, with all the image information about the ... My issue is with the filter byte in the PNG spec. ...
    (microsoft.public.vb.winapi.graphics)
  • Help creating a PNG with zlib libraries?
    ... I'm using the excellent Deflate/Inflate zlib compression library ... I can create the PNG headers, with all the image information about the ... My issue is with the filter byte in the PNG spec. ... I have a byte array Bwith all my image data in it. ...
    (microsoft.public.vb.winapi.graphics)
  • Re: Examples of Anti-Anti-Alias Requirements
    ... EEG is much more random than ECG, and you can't really learn as much even from a perfectly recorded signal. ... I'm laughing right now because right before I read your post I found out that if I filter it at about 400Hz it looks pretty good... ... I would add to that that should I be tasked with storing an EKG recording in some storage-sensitive way I'd probably look at some adaptive compression scheme. ... I'm really not sure if I'd consider lossy compression without lots of research behind me, but one could probably do some sort of lossless compression that would vary the compression rate depending on the signal. ...
    (comp.dsp)