Re: JPEG 9 new lossless JPEG standard

Discussion in 'Digital Photography' started by Martin Brown, Jan 23, 2013.

  1. Martin Brown

    Martin Brown Guest

    On 22/01/2013 21:38, Alfred Molon wrote:
    > There is a new lossless JPEG standard released just now:
    > http://www.infai.org/jpeg
    >
    > Does anybody know more (performance, compression etc.)?


    Performance will be better than the original lossless JPEG (which was
    pretty terrible and in practice almost never used outside a handful of
    niche markets). PsPro8 will write a JPEG lossless file and give it the
    ..JPG extension thus crashing almost every other JPEG decoder.

    JPEG came to always mean lossy JPEG in common usage and I hope that IJG
    are giving their new format a distinctive name like .JPGL to avoid
    codecs crashed by a format that they can't make sense of a la PsP8.

    The new standard probably gives compression for 24bit rgb images broadly
    comparable with or if they have done it right slightly better than PNG.
    I have not had time to play with the new release yet.

    --
    Regards,
    Martin Brown
    Martin Brown, Jan 23, 2013
    #1
    1. Advertising

  2. Martin Brown

    Joe Kotroczo Guest

    On 23/01/2013 09:11, Martin Brown wrote:
    > On 22/01/2013 21:38, Alfred Molon wrote:
    >> There is a new lossless JPEG standard released just now:
    >> http://www.infai.org/jpeg
    >>
    >> Does anybody know more (performance, compression etc.)?

    >
    > Performance will be better than the original lossless JPEG (which was
    > pretty terrible and in practice almost never used outside a handful of
    > niche markets). PsPro8 will write a JPEG lossless file and give it the
    > .JPG extension thus crashing almost every other JPEG decoder.
    >
    > JPEG came to always mean lossy JPEG in common usage and I hope that IJG
    > are giving their new format a distinctive name like .JPGL to avoid
    > codecs crashed by a format that they can't make sense of a la PsP8.


    Any application which crashes because the content of a file doesn't
    match what it expected due to the file's filename extension is broken.

    As is an operating system that solely relies on filename extensions to
    figure out file type.


    --
    audentes fortuna iuvat
    Joe Kotroczo, Jan 23, 2013
    #2
    1. Advertising

  3. Martin Brown

    Martin Brown Guest

    On 23/01/2013 09:22, Joe Kotroczo wrote:
    > On 23/01/2013 09:11, Martin Brown wrote:
    >> On 22/01/2013 21:38, Alfred Molon wrote:
    >>> There is a new lossless JPEG standard released just now:
    >>> http://www.infai.org/jpeg
    >>>
    >>> Does anybody know more (performance, compression etc.)?

    >>
    >> Performance will be better than the original lossless JPEG (which was
    >> pretty terrible and in practice almost never used outside a handful of
    >> niche markets). PsPro8 will write a JPEG lossless file and give it the
    >> .JPG extension thus crashing almost every other JPEG decoder.
    >>
    >> JPEG came to always mean lossy JPEG in common usage and I hope that IJG
    >> are giving their new format a distinctive name like .JPGL to avoid
    >> codecs crashed by a format that they can't make sense of a la PsP8.

    >
    > Any application which crashes because the content of a file doesn't
    > match what it expected due to the file's filename extension is broken.
    >
    > As is an operating system that solely relies on filename extensions to
    > figure out file type.


    I agree, but Microsoft and the commonly used IJG codec both baulk on
    Lossless-JPG streams with a .JPG extension. Malformed JPG files have
    been used as a way to vector hostile executable code in the past. It
    confused end users no end since they have .JPG files that the decoder
    refuses to decode and in some cases for older codecs actually crashes.

    Relevant prior art is the JPEG-LS sceme called LOCO by HP
    http://www.hpl.hp.com/loco/

    Full paper at http://www.hpl.hp.com/loco/HPL-98-193R1.pdf

    I hope JPEG9 shows how it compares on the same test data.
    These are used for some scientific image telemetry

    http://www.hpl.hp.com/news/2004/jan-mar/hp_mars.html


    --
    Regards,
    Martin Brown
    Martin Brown, Jan 23, 2013
    #3
  4. In article <>,
    Alan Browne <> wrote:

    > On 2013.01.23 03:11 , Martin Brown wrote:
    > > On 22/01/2013 21:38, Alfred Molon wrote:
    > >> There is a new lossless JPEG standard released just now:
    > >> http://www.infai.org/jpeg
    > >>
    > >> Does anybody know more (performance, compression etc.)?

    > >
    > > Performance will be better than the original lossless JPEG (which was
    > > pretty terrible and in practice almost never used outside a handful of
    > > niche markets). PsPro8 will write a JPEG lossless file and give it the
    > > .JPG extension thus crashing almost every other JPEG decoder.
    > >
    > > JPEG came to always mean lossy JPEG in common usage and I hope that IJG
    > > are giving their new format a distinctive name like .JPGL to avoid
    > > codecs crashed by a format that they can't make sense of a la PsP8.
    > >
    > > The new standard probably gives compression for 24bit rgb images broadly
    > > comparable with or if they have done it right slightly better than PNG.
    > > I have not had time to play with the new release yet.

    >
    > Frankly, I don't care if JPG is slightly lossy. If it's important I
    > have it in another lossless (and higher DR) format (tif, raw, dng ...).
    >
    > Hopefully a tool to turn the JPG-9 encoded files to lossy JPG files will
    > soon emerge. A simple line command would be fine...


    Most lossless compression algorithms only work on data words that are
    about 8 bits. That's why high efficiency lossless compression on high
    dynamic range images is uncommon. A lot of work has to be done to
    convert the 16, 24, or 32 bit data into fewer bits in a way that
    enhances compression rather than hinders it.
    --
    I will not see posts from Google because I must filter them as spam
    Kevin McMurtrie, Jan 26, 2013
    #4
  5. Kevin McMurtrie <> wrote:

    > Most lossless compression algorithms only work on data words that are
    > about 8 bits. That's why high efficiency lossless compression on high
    > dynamic range images is uncommon.


    Logic failure. UCS16 can easily be losslessly compressed by
    common lossless compressors, for example.

    > A lot of work has to be done to
    > convert the 16, 24, or 32 bit data into fewer bits in a way that
    > enhances compression rather than hinders it.


    Or one simply uses a compression algorithm that has no
    problems if words are larger than an octet. (The "typical"
    image is 24bit btw. if it has colour.) Not to mention that a
    compressor would only care about how large a data word is if
    they need to understand the data.

    -Wolfgang
    Wolfgang Weisselberg, Jan 27, 2013
    #5
  6. Martin Brown

    Martin Brown Guest

    On 26/01/2013 20:23, Kevin McMurtrie wrote:
    > In article <>,
    > Alan Browne <> wrote:
    >
    >> On 2013.01.23 03:11 , Martin Brown wrote:
    >>> On 22/01/2013 21:38, Alfred Molon wrote:
    >>>> There is a new lossless JPEG standard released just now:
    >>>> http://www.infai.org/jpeg
    >>>>
    >>>> Does anybody know more (performance, compression etc.)?
    >>>
    >>> Performance will be better than the original lossless JPEG (which was
    >>> pretty terrible and in practice almost never used outside a handful of
    >>> niche markets). PsPro8 will write a JPEG lossless file and give it the
    >>> .JPG extension thus crashing almost every other JPEG decoder.
    >>>
    >>> JPEG came to always mean lossy JPEG in common usage and I hope that IJG
    >>> are giving their new format a distinctive name like .JPGL to avoid
    >>> codecs crashed by a format that they can't make sense of a la PsP8.
    >>>
    >>> The new standard probably gives compression for 24bit rgb images broadly
    >>> comparable with or if they have done it right slightly better than PNG.
    >>> I have not had time to play with the new release yet.

    >>
    >> Frankly, I don't care if JPG is slightly lossy. If it's important I
    >> have it in another lossless (and higher DR) format (tif, raw, dng ...).
    >>
    >> Hopefully a tool to turn the JPG-9 encoded files to lossy JPG files will
    >> soon emerge. A simple line command would be fine...


    The JPEG9 codec still includes all the original JPEG standard stuff
    *and* in addition a new lossless encoder and colourspace it calls RGB1
    that allows better lossless compression RGB images. I haven't tried it
    out yet. Roundtuit problem.
    >
    > Most lossless compression algorithms only work on data words that are
    > about 8 bits. That's why high efficiency lossless compression on high
    > dynamic range images is uncommon. A lot of work has to be done to
    > convert the 16, 24, or 32 bit data into fewer bits in a way that
    > enhances compression rather than hinders it.


    That is somewhat misleading. The original draft lossy JPEG standard
    provided for images using 8bit or 12bit input data and the IJG codec can
    be compiled for the latter case. 12bit lossy JPEG is seldom seen.

    The original lossless JPEG standard also allowed for lossless encoding
    of any data of bit length 2 through 16 bits. The problem was that there
    were already other lossless encoders about that were as good or better
    whereas the lossy JPEG high compression encoding was new and extremely
    useful with almost no perceptual losses and *much* smaller file sizes.

    IJG making a free implementation publicly available made it the defacto
    standard for (pre)web images in the days when a really fast dialup modem
    could manage up to 2kb/s on a good day with a trailing wind.

    Variations on the theme of JPEG-LS extended by HP and other researchers
    are used in the lossless compression of image data from space probes and
    archiving digital X-rays but seldom (never?) seen in consumer kit.

    The problem for lossless algorithms in general is that they generally
    spend an inordinate amount of their space and time budget faithfully
    preserving exactly the thermal noise from the imaging system.

    --
    Regards,
    Martin Brown
    Martin Brown, Jan 28, 2013
    #6
  7. Martin Brown

    Martin Brown Guest

    On 28/01/2013 18:30, Alfred Molon wrote:

    > Will JPEG still be widespread in 50 years?


    Impossible to say, but there is no reason why it should not survive.

    The IJG JPEG codec is freely available in sourcecode form and the nasty
    blocking patents on things that would improve it will time out.

    Wavelets could in principal do slightly better in terms of higher
    fidelity at a smaller size but JPEG is basically good enough for all
    consumer grade imaging. The extent that JPEG is spread across the web
    pretty much ensures that there will be decoders for the foreseeable
    future - although 50 years is perhaps a bit of a stretch.

    My instinct is that if J2k was going to take off on the web it would
    have done so by now. If you look back in time I was an advocate for it.

    http://www.nezumi.demon.co.uk/photo/j2k/j2k_v_jpeg.htm

    J2k works significantly better than JPEG at highest quality but the
    gains were not sufficient to overcome the inertia and various patent
    litigation barriers. Various image apps have J2k codec in today.

    --
    Regards,
    Martin Brown
    Martin Brown, Jan 28, 2013
    #7
  8. In article <>,
    Wolfgang Weisselberg <> wrote:

    > Kevin McMurtrie <> wrote:
    >
    > > Most lossless compression algorithms only work on data words that are
    > > about 8 bits. That's why high efficiency lossless compression on high
    > > dynamic range images is uncommon.

    >
    > Logic failure. UCS16 can easily be losslessly compressed by
    > common lossless compressors, for example.
    >
    > > A lot of work has to be done to
    > > convert the 16, 24, or 32 bit data into fewer bits in a way that
    > > enhances compression rather than hinders it.

    >
    > Or one simply uses a compression algorithm that has no
    > problems if words are larger than an octet. (The "typical"
    > image is 24bit btw. if it has colour.) Not to mention that a
    > compressor would only care about how large a data word is if
    > they need to understand the data.
    >
    > -Wolfgang


    The final compression stage is usually something simple like 'deflate'.
    It does very much care what the bytes look like. If you were to dump
    out an interleaved RGB image with 16 bits per pixel per channel to a
    file and compress it with bzip2 or gzip, you'd find that not much
    happens. It might even get a few bytes larger. PNG puts a simple
    predictive filter in front of deflate so that typical images produce
    simpler patterns at the byte level. Lossless JPEG attempts to create
    simple patterns representing error correction for the lossy conversion.

    Deflate and bzip2 only work well at reducing 8 bit words. Getting a 16
    or 24 bit per pixel per channel image down to clean patterns of 8 bits
    takes some work that's very specific to image processing.
    --
    I will not see posts from Google because I must filter them as spam
    Kevin McMurtrie, Jan 29, 2013
    #8
  9. Kevin McMurtrie <> wrote:
    > Wolfgang Weisselberg <> wrote:
    >> Kevin McMurtrie <> wrote:


    >> > Most lossless compression algorithms only work on data words that are
    >> > about 8 bits. That's why high efficiency lossless compression on high
    >> > dynamic range images is uncommon.


    >> Logic failure. UCS16 can easily be losslessly compressed by
    >> common lossless compressors, for example.


    >> > A lot of work has to be done to
    >> > convert the 16, 24, or 32 bit data into fewer bits in a way that
    >> > enhances compression rather than hinders it.


    >> Or one simply uses a compression algorithm that has no
    >> problems if words are larger than an octet. (The "typical"
    >> image is 24bit btw. if it has colour.) Not to mention that a
    >> compressor would only care about how large a data word is if
    >> they need to understand the data.


    > The final compression stage is usually something simple like 'deflate'.
    > It does very much care what the bytes look like.


    Deflate doesn't care at all. Only the archivable compression
    rate may be suboptimal.

    > If you were to dump
    > out an interleaved RGB image with 16 bits per pixel per channel to a
    > file and compress it with bzip2 or gzip, you'd find that not much
    > happens. It might even get a few bytes larger. PNG puts a simple
    > predictive filter in front of deflate so that typical images produce
    > simpler patterns at the byte level. Lossless JPEG attempts to create
    > simple patterns representing error correction for the lossy conversion.


    And?

    > Deflate and bzip2 only work well at reducing 8 bit words.


    So we are not at "only work well" from your previous "only
    work". That's at least the right direction.

    For example deflate (the algorithm) is nowhere dependent on
    "8 bit words". The characters can be of arbitrary size.

    The same is true for the bzip2 algorithm.


    > Getting a 16
    > or 24 bit per pixel per channel image down to clean patterns of 8 bits
    > takes some work that's very specific to image processing.


    What work would that be?

    > I will not see posts from Google because I must filter them as spam


    Tell the guy who's pointing a pistol at you, forcing you to
    filter posts from Google to go away. Then it will be *your*
    choice if you want to filter posts from Google.

    -Wolfgang
    Wolfgang Weisselberg, Feb 4, 2013
    #9
  10. In article <>,
    Wolfgang Weisselberg <> wrote:

    > Kevin McMurtrie <> wrote:
    > > Wolfgang Weisselberg <> wrote:
    > >> Kevin McMurtrie <> wrote:

    >
    > >> > Most lossless compression algorithms only work on data words that are
    > >> > about 8 bits. That's why high efficiency lossless compression on high
    > >> > dynamic range images is uncommon.

    >
    > >> Logic failure. UCS16 can easily be losslessly compressed by
    > >> common lossless compressors, for example.

    >
    > >> > A lot of work has to be done to
    > >> > convert the 16, 24, or 32 bit data into fewer bits in a way that
    > >> > enhances compression rather than hinders it.

    >
    > >> Or one simply uses a compression algorithm that has no
    > >> problems if words are larger than an octet. (The "typical"
    > >> image is 24bit btw. if it has colour.) Not to mention that a
    > >> compressor would only care about how large a data word is if
    > >> they need to understand the data.

    >
    > > The final compression stage is usually something simple like 'deflate'.
    > > It does very much care what the bytes look like.

    >
    > Deflate doesn't care at all. Only the archivable compression
    > rate may be suboptimal.
    >
    > > If you were to dump
    > > out an interleaved RGB image with 16 bits per pixel per channel to a
    > > file and compress it with bzip2 or gzip, you'd find that not much
    > > happens. It might even get a few bytes larger. PNG puts a simple
    > > predictive filter in front of deflate so that typical images produce
    > > simpler patterns at the byte level. Lossless JPEG attempts to create
    > > simple patterns representing error correction for the lossy conversion.

    >
    > And?
    >
    > > Deflate and bzip2 only work well at reducing 8 bit words.

    >
    > So we are not at "only work well" from your previous "only
    > work". That's at least the right direction.
    >
    > For example deflate (the algorithm) is nowhere dependent on
    > "8 bit words". The characters can be of arbitrary size.
    >
    > The same is true for the bzip2 algorithm.


    OK, you should call up the GIF, PNG, JPEG, MPEG, and FLAC folks to tell
    them of your brilliant discovery. I bet they'll feel silly for all the
    work they did coming up with algorithms to prepare data for compression.
    Thanks for saving the Internet.


    >
    > > Getting a 16
    > > or 24 bit per pixel per channel image down to clean patterns of 8 bits
    > > takes some work that's very specific to image processing.

    >
    > What work would that be?
    >
    > > I will not see posts from Google because I must filter them as spam

    >
    > Tell the guy who's pointing a pistol at you, forcing you to
    > filter posts from Google to go away. Then it will be *your*
    > choice if you want to filter posts from Google.
    >
    > -Wolfgang


    Refresh your meds.
    --
    I will not see posts from Google because I must filter them as spam
    Kevin McMurtrie, Feb 5, 2013
    #10
  11. Martin Brown

    Martin Brown Guest

    On 04/02/2013 20:04, Wolfgang Weisselberg wrote:
    > Kevin McMurtrie <> wrote:
    >> Wolfgang Weisselberg <> wrote:
    >>> Kevin McMurtrie <> wrote:

    >
    >>>> Most lossless compression algorithms only work on data words that are
    >>>> about 8 bits. That's why high efficiency lossless compression on high
    >>>> dynamic range images is uncommon.

    >
    >>> Logic failure. UCS16 can easily be losslessly compressed by
    >>> common lossless compressors, for example.

    >
    >>>> A lot of work has to be done to
    >>>> convert the 16, 24, or 32 bit data into fewer bits in a way that
    >>>> enhances compression rather than hinders it.

    >
    >>> Or one simply uses a compression algorithm that has no
    >>> problems if words are larger than an octet. (The "typical"
    >>> image is 24bit btw. if it has colour.) Not to mention that a
    >>> compressor would only care about how large a data word is if
    >>> they need to understand the data.

    >
    >> The final compression stage is usually something simple like 'deflate'.
    >> It does very much care what the bytes look like.

    >
    > Deflate doesn't care at all. Only the archivable compression
    > rate may be suboptimal.


    It cares about the patterns in the source data if you want to actually
    get useful compression. If you don't mind the file getting bigger then
    the algorithm works but it does not compress the image.

    Some patterns necessarily grow in size when compressed with a given
    lossless compression algorithm and that problem is more likely to be
    encountered if you feed RGB interleaved image data or YCC for that
    matter into a simple lossless encoder.

    Shuffling the data to be RRRRR...GGGGG...BBBBB either physically or in
    practice by altering the indexing and then using a simple forward
    predictor is the most common solution for lossless these days.

    Your claim that the "compression rate may be suboptimal" needs replacing
    with the statement that in the worst case the file size will grow. 24bit
    colour interleaved noisy photographic image data is not well suited to
    the sorts of lossless compression that were originally heavily optimised
    for text and binary executables. Both cases where lossless is absolutely
    essential. In many photographic images you can afford to drop the least
    significant bit or quantise JPEG coefficients to gain extra compression
    and still have adequate signal to noise.
    (this would be disastrous for executable binaries)

    >> I will not see posts from Google because I must filter them as spam

    >
    > Tell the guy who's pointing a pistol at you, forcing you to
    > filter posts from Google to go away. Then it will be *your*
    > choice if you want to filter posts from Google.


    It isn't a bad idea unless you are interested in forged copy watches and
    other fashion dross. Google inject far too much spam into Usenet.

    --
    Regards,
    Martin Brown
    Martin Brown, Feb 5, 2013
    #11
  12. Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
    > On 04/02/2013 20:04, Wolfgang Weisselberg wrote:
    >> Kevin McMurtrie <> wrote:
    >>> Wolfgang Weisselberg <> wrote:
    >>>> Kevin McMurtrie <> wrote:


    >>>>> Most lossless compression algorithms only work on data words that are
    >>>>> about 8 bits. That's why high efficiency lossless compression on high
    >>>>> dynamic range images is uncommon.


    >>>> Logic failure. UCS16 can easily be losslessly compressed by
    >>>> common lossless compressors, for example.


    >>>>> A lot of work has to be done to
    >>>>> convert the 16, 24, or 32 bit data into fewer bits in a way that
    >>>>> enhances compression rather than hinders it.


    >>>> Or one simply uses a compression algorithm that has no
    >>>> problems if words are larger than an octet. (The "typical"
    >>>> image is 24bit btw. if it has colour.) Not to mention that a
    >>>> compressor would only care about how large a data word is if
    >>>> they need to understand the data.


    >>> The final compression stage is usually something simple like 'deflate'.
    >>> It does very much care what the bytes look like.


    >> Deflate doesn't care at all. Only the archivable compression
    >> rate may be suboptimal.


    > It cares about the patterns in the source data if you want to actually
    > get useful compression.


    Any compression only works when there are patterns that the
    compressor can exploit. You can't compress truly random noise.

    But you knew that, didn't you?

    > If you don't mind the file getting bigger then
    > the algorithm works but it does not compress the image.


    So if I can show that Deflate reduces the image size, what
    then?

    > Some patterns necessarily grow in size when compressed with a given
    > lossless compression algorithm


    True, though 'pattern' usually implies a sort of regular
    structure, not random noise as here.

    > and that problem is more likely to be
    > encountered if you feed RGB interleaved image data or YCC for that
    > matter into a simple lossless encoder.


    More likely than what? Than a long string like 'aaaaaaa...'
    or '123123123123...'? Yep. However, how likely is that in
    absolute terms?

    Let's try something, shall we? Let's examine some photograps using:

    for i in `find -type f -name *.jpg` ; do
    j=$(basename $i)
    raw=$(cat $i | djpeg -bmp | wc -c);
    gzipped=$(cat $i | djpeg -bmp | gzip -9 | wc -c);
    bzipped=$(cat $i | djpeg -bmp | bzip2 -9 | wc -c);
    echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw - $bzipped));
    done | sort

    # filename BMP size gzipped smaller bzip2 smaller
    # than raw BMP by: than raw BMP by:

    img_7982.jpg 3240054 1203452 1626737
    img_7989.jpg 3240054 607967 1098620
    img_7989.jpg 919734 91485 195421
    img_7990.jpg 3240054 509360 985195
    img_7990.jpg 919734 101032 189440
    img_7995.jpg 3240054 496028 972555
    img_7995.jpg 919734 105659 190792
    img_7996.jpg 3240054 497543 982905
    img_7996.jpg 919734 105771 193190
    img_7999.jpg 3240054 512897 1005469
    img_7999.jpg 919734 110504 202331
    img_8003.jpg 3240054 562936 1065404
    img_8003.jpg 919734 108650 209202
    img_8006.jpg 3240054 632929 1155963
    img_8006.jpg 919734 111182 226208
    img_8008.jpg 3240054 719276 1249507
    img_8008.jpg 919734 122050 250593
    img_8014.jpg 3240054 575955 1079262
    img_8019.jpg 3240054 517690 1001829
    img_8021.jpg 3240054 498457 974703
    img_8024.jpg 3240054 517907 999721
    img_8028.jpg 3240054 540416 1024054
    img_8030.jpg 3240054 657819 1106021
    img_8033.jpg 3240054 737935 1172748
    img_8036.jpg 3240054 791260 1282280
    img_8042.jpg 3240054 675388 1146118
    img_8046.jpg 3240054 571756 1053363
    img_8050.jpg 3240054 563599 1059376
    img_8053.jpg 3240054 556195 1054057
    img_8055.jpg 3240054 572070 1070261
    img_8058.jpg 3240054 616748 1122422
    img_8060.jpg 3240054 688297 1194691
    img_8065.jpg 3240054 799523 1292761
    img_8069.jpg 3240054 793158 1265319
    img_8073.jpg 3240054 640697 1055733
    img_8075.jpg 3240054 723194 1224798
    img_8080.jpg 3240054 737214 1252286
    img_8082.jpg 3240054 692043 1209835
    img_8085.jpg 3240054 734807 1246824
    img_8089.jpg 3240054 782972 1287342
    img_8092.jpg 3240054 938450 1417059
    img_8096.jpg 3240054 636948 1146065
    img_8099.jpg 3240054 535988 1054566
    img_8103.jpg 3240054 527232 1058664
    img_8105.jpg 3240054 565579 1111619
    img_8110.jpg 3240054 612162 1153905
    img_8112.jpg 3240054 697712 1230004
    img_8115.jpg 3240054 801503 1323389
    img_8119.jpg 3240054 974447 1463168
    img_8123.jpg 3240054 637312 1059207
    img_8126.jpg 3240054 588159 999118
    img_8130.jpg 3240054 567768 977774
    img_8132.jpg 3240054 572802 983765
    img_8137.jpg 3240054 595534 1018112
    img_8140.jpg 3240054 674741 1106665
    img_8142.jpg 3240054 696033 1135734
    img_8145.jpg 3240054 819444 1260933
    img_8153.jpg 3240054 678660 1112909
    img_8154.jpg 3240054 641381 1069688
    img_8157.jpg 3240054 563236 973643
    img_8160.jpg 3240054 470213 927025
    img_8164.jpg 3240054 482806 948243
    img_8166.jpg 3240054 537124 1004635
    img_8169.jpg 3240054 579673 1064495
    img_8173.jpg 3240054 672162 1166744
    img_8181.jpg 3240054 821861 1229624
    img_8185.jpg 3240054 541668 959781
    img_8188.jpg 3240054 534623 959323
    img_8195.jpg 3240054 767356 1182668
    img_8197.jpg 3240054 544802 965161
    img_8200.jpg 3240054 500791 916249
    img_8205.jpg 3240054 548571 1040353
    img_8207.jpg 3240054 503218 992450
    img_8209.jpg 3240054 512284 1004421
    img_8214.jpg 3240054 547932 1051291
    img_8216.jpg 3240054 603154 1105454
    img_8219.jpg 3240054 605039 1111745
    img_8221.jpg 3240054 703410 1223241
    img_8226.jpg 3240054 762456 1280689
    img_8231.jpg 3240054 669082 1111096
    img_8234.jpg 3240054 435718 852849
    img_8238.jpg 3240054 565904 1021106
    img_8244.jpg 3240054 673010 1203658
    img_8246.jpg 3240054 632836 1145510
    img_8250.jpg 3240054 657032 1170895
    img_8252.jpg 3240054 699824 1213975
    img_8255.jpg 3240054 715290 1228881
    img_8258.jpg 3240054 797310 1307704
    img_8261.jpg 3240054 893517 1401405
    img_8269.jpg 3240054 1020897 1517872
    img_8274.jpg 3240054 713331 1167826
    img_8277.jpg 3240054 628594 1089871
    img_8281.jpg 3240054 664644 1129664
    img_8287.jpg 3240054 1179361 1659459
    img_8288.jpg 3240054 1127805 1610415
    img_8291.jpg 3240054 1191657 1659452
    img_8294.jpg 3240054 1176294 1648331
    img_8299.jpg 3240054 1175449 1623956
    img_8301.jpg 3240054 1349885 1752673
    img_8304.jpg 3240054 1239055 1662562
    img_8306.jpg 3240054 1394347 1819757
    img_8313.jpg 3240054 636114 1067869
    img_8318.jpg 3240054 682434 1120210
    img_8320.jpg 3240054 729418 1172669
    img_8325.jpg 3240054 1038585 1562675
    img_8328.jpg 3240054 1019874 1554056
    img_8332.jpg 3240054 1116905 1620486
    img_8335.jpg 3240054 1174538 1665633
    img_8338.jpg 3240054 1033995 1566612
    img_8340.jpg 3240054 1307571 1789141
    img_8344.jpg 3240054 1326174 1780323
    img_8348.jpg 3240054 1475567 1889463
    img_8353.jpg 2430054 747712 1127855
    img_8353.jpg 24556086 6045419 8876848
    img_8356.jpg 2430054 697604 1066953
    img_8356.jpg 24556086 5755141 8498689
    img_8360.jpg 2430054 707638 1075947
    img_8360.jpg 24556086 5534996 8185023
    img_8364.jpg 2430054 589010 868577
    img_8364.jpg 24556086 12079422 14851013
    img_8366.jpg 24556086 10815729 13591347
    img_8369.jpg 2430054 402620 703745
    img_8369.jpg 24556086 9618823 12631977
    img_8372.jpg 2430054 393050 701142
    img_8372.jpg 24556086 9143959 12283021
    img_8374.jpg 2430054 385652 696135
    img_8374.jpg 24556086 8797262 12031707
    img_8378.jpg 2430054 386923 695825
    img_8378.jpg 24556086 8615533 11905375
    img_8382.jpg 2430054 396748 710954
    img_8382.jpg 24556086 8609142 11939699
    img_8383.jpg 2430054 430888 746548
    img_8383.jpg 24556086 8811938 12209607
    img_8387.jpg 2430054 486942 807262
    img_8387.jpg 24556086 9260819 12701608
    img_8391.jpg 2430054 576635 869827
    img_8391.jpg 24556086 9800618 13094088
    img_8393.jpg 2430054 528472 814917
    img_8393.jpg 24556086 9364251 12639778
    img_8397.jpg 24556086 9173119 12554427
    img_8399.jpg 2430054 560572 853579
    img_8399.jpg 24556086 9264783 12741725
    img_8402.jpg 2430054 593069 891822
    img_8402.jpg 24556086 9480618 12987397
    img_8404.jpg 2430054 654252 954943
    img_8404.jpg 24556086 9977371 13503881
    img_8408.jpg 2430054 840497 1102911
    img_8408.jpg 24556086 9830924 13427218
    img_8410.jpg 2430054 804210 1063564
    img_8410.jpg 24556086 9523527 13154598
    img_8413.jpg 2430054 784215 1045822
    img_8413.jpg 24556086 9253845 12886229
    img_8416.jpg 2430054 810048 1074248
    img_8416.jpg 24556086 9447423 13091329
    img_8419.jpg 2430054 925743 1154154
    img_8419.jpg 24556086 9523897 13032157
    img_8420.jpg 2430054 912326 1154188
    img_8420.jpg 24556086 9272509 12846203
    img_8425.jpg 2430054 930669 1169339
    img_8425.jpg 24556086 9168958 12778571
    img_8427.jpg 2430054 956224 1196074
    img_8427.jpg 24556086 9401121 13023296
    img_8430.jpg 2430054 989934 1229710
    img_8430.jpg 24556086 9767028 13424624
    img_8432.jpg 2430054 1035750 1271366
    img_8432.jpg 24556086 10223756 13873760
    img_8435.jpg 2430054 881529 1132523
    img_8435.jpg 24556086 9962471 13534872
    img_8436.jpg 2430054 863487 1114143
    img_8436.jpg 24556086 9720262 13340653
    img_8437.jpg 2430054 876100 1129649
    img_8437.jpg 24556086 9946131 13527719
    img_8438.jpg 2430054 875714 1128542
    img_8438.jpg 24556086 9671811 13274825
    img_8439.jpg 2430054 877305 1128733
    img_8439.jpg 24556086 9667881 13270123
    img_8440.jpg 24556086 9660421 13258144
    img_8441.jpg 2430054 876673 1131012
    img_8441.jpg 24556086 9632001 13238365
    img_8442.jpg 2430054 882515 1133814
    img_8442.jpg 24556086 9676843 13269083
    img_8443.jpg 2430054 880058 1132008
    img_8443.jpg 24556086 9658507 13253560
    img_8444.jpg 2430054 898751 1151986
    img_8444.jpg 24556086 9651639 13291110
    img_8445.jpg 2430054 901498 1152910
    img_8445.jpg 24556086 9725872 13338745
    img_8446.jpg 2430054 898827 1151798
    img_8446.jpg 24556086 9659500 13290213
    img_8447.jpg 24556086 10023891 13631158
    img_8448.jpg 2430054 942839 1193382
    img_8448.jpg 24556086 10015123 13616944
    img_8449.jpg 2430054 952426 1204064
    img_8449.jpg 24556086 10026363 13655466
    img_8450.jpg 2430054 1004502 1252368
    img_8450.jpg 24556086 10515211 14101313
    img_8451.jpg 2430054 1007568 1256233
    img_8451.jpg 24556086 10545604 14143348
    img_8452.jpg 2430054 1013746 1261265
    img_8452.jpg 24556086 10626215 14191135
    img_8453.jpg 2430054 1030254 1274530
    img_8453.jpg 24556086 10789547 14340923
    img_8454.jpg 2430054 1017535 1263092
    img_8454.jpg 24556086 10666279 14236505
    img_8455.jpg 2430054 1030031 1274988
    img_8455.jpg 24556086 10749147 14311783
    img_8456.jpg 2430054 997535 1240500
    img_8456.jpg 24556086 10651959 13977844
    img_8457.jpg 2430054 996595 1241239
    img_8457.jpg 24556086 10601959 13947232
    img_8458.jpg 2430054 999070 1243133
    img_8458.jpg 24556086 10670335 13998639
    img_8459.jpg 2430054 1003759 1246918
    img_8459.jpg 24556086 10507185 13837222
    img_8460.jpg 2430054 997928 1242818
    img_8460.jpg 24556086 10444806 13792300
    img_8461.jpg 2430054 996530 1241884
    img_8461.jpg 24556086 10451119 13790468
    img_8462.jpg 2430054 1000935 1243363
    img_8462.jpg 24556086 10352347 13679873
    img_8463.jpg 2430054 995032 1239781
    img_8463.jpg 24556086 10308864 13651747
    img_8464.jpg 2430054 1000348 1242194
    img_8464.jpg 24556086 10366274 13688614
    img_8465.jpg 2430054 1004647 1245563
    img_8465.jpg 24556086 10430154 13736308
    img_8466.jpg 2430054 1006011 1246599
    img_8466.jpg 24556086 10445752 13756202
    img_8467.jpg 2430054 999658 1243700
    img_8467.jpg 24556086 10420177 13736793
    img_8468.jpg 2430054 1029145 1269392
    img_8468.jpg 24556086 10677155 13984035
    img_8469.jpg 2430054 1029513 1271272
    img_8469.jpg 24556086 10701299 14010750
    img_8470.jpg 2430054 1030149 1274296
    img_8470.jpg 24556086 10732358 14037330
    img_8471.jpg 2430054 1068892 1310499
    img_8471.jpg 24556086 11105964 14416756
    img_8472.jpg 2430054 1070661 1313421
    img_8472.jpg 24556086 11068861 14400088
    img_8473.jpg 2430054 1090052 1330386
    img_8473.jpg 24556086 11374029 14672746
    img_8474.jpg 2430054 1140800 1372869
    img_8474.jpg 24556086 11757890 15021576
    img_8475.jpg 2430054 1138795 1373950
    img_8475.jpg 24556086 11778238 15038641
    img_8476.jpg 2430054 1140861 1374756
    img_8476.jpg 24556086 11787852 15053906
    [...]

    Weeeell ... looks like the chance that these '8 bit
    only'-lossless encoders grows a RGB raw file in size is
    really small. Experiment tops theory.

    > Shuffling the data to be RRRRR...GGGGG...BBBBB either physically or in
    > practice by altering the indexing and then using a simple forward
    > predictor is the most common solution for lossless these days.


    There are lots of methods, some better, some worse.
    Using Bayer-pattern RAW instead of a deinterlaced RGB file is
    also common and very clever, since a deinterlaced RGB file
    doesn't have additional information that can't be regenerated
    knowing the deinterlacer.

    > Your claim that the "compression rate may be suboptimal" needs replacing
    > with the statement that in the worst case the file size will grow.


    a) That is true even for a dedicated 24-bit RGB image
    compressor.
    b) Stop painting everything pitch black, reality doesn't
    agree with you. See above.

    > 24bit
    > colour interleaved noisy photographic image data is not well suited to
    > the sorts of lossless compression that were originally heavily optimised
    > for text and binary executables. Both cases where lossless is absolutely
    > essential. In many photographic images you can afford to drop the least
    > significant bit or quantise JPEG coefficients to gain extra compression
    > and still have adequate signal to noise.
    > (this would be disastrous for executable binaries)


    We *were* talking about lossless compression.


    >>> I will not see posts from Google because I must filter them as spam


    >> Tell the guy who's pointing a pistol at you, forcing you to
    >> filter posts from Google to go away. Then it will be *your*
    >> choice if you want to filter posts from Google.


    > It isn't a bad idea unless you are interested in forged copy watches and
    > other fashion dross. Google inject far too much spam into Usenet.


    That was not the point at all.

    -Wolfgang
    Wolfgang Weisselberg, Feb 8, 2013
    #12
  13. Kevin McMurtrie <> wrote:
    > Wolfgang Weisselberg <> wrote:
    >> Kevin McMurtrie <> wrote:


    >> > Deflate and bzip2 only work well at reducing 8 bit words.


    >> So we are not at "only work well" from your previous "only
    >> work". That's at least the right direction.


    >> For example deflate (the algorithm) is nowhere dependent on
    >> "8 bit words". The characters can be of arbitrary size.


    >> The same is true for the bzip2 algorithm.


    > OK, you should call up the GIF, PNG, JPEG, MPEG, and FLAC folks to tell
    > them of your brilliant discovery.


    I'll leave the carrying of coal to Newcastle to you.

    > I bet they'll feel silly for all the
    > work they did coming up with algorithms to prepare data for compression.


    Why should they?

    > Thanks for saving the Internet.


    Thank me for what I have done: broadened your horizon and set
    your 8-bit-fixation straight.

    >> > Getting a 16
    >> > or 24 bit per pixel per channel image down to clean patterns of 8 bits
    >> > takes some work that's very specific to image processing.


    >> What work would that be?


    Well?


    >> > I will not see posts from Google because I must filter them as spam


    >> Tell the guy who's pointing a pistol at you, forcing you to
    >> filter posts from Google to go away. Then it will be *your*
    >> choice if you want to filter posts from Google.


    > Refresh your meds.


    Personal experience speaking?

    -Wolfgang
    Wolfgang Weisselberg, Feb 8, 2013
    #13
  14. In article <>,
    Wolfgang Weisselberg <> wrote:

    > Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
    > > On 04/02/2013 20:04, Wolfgang Weisselberg wrote:
    > >> Kevin McMurtrie <> wrote:
    > >>> Wolfgang Weisselberg <> wrote:
    > >>>> Kevin McMurtrie <> wrote:

    >
    > >>>>> Most lossless compression algorithms only work on data words that are
    > >>>>> about 8 bits. That's why high efficiency lossless compression on high
    > >>>>> dynamic range images is uncommon.

    >
    > >>>> Logic failure. UCS16 can easily be losslessly compressed by
    > >>>> common lossless compressors, for example.

    >
    > >>>>> A lot of work has to be done to
    > >>>>> convert the 16, 24, or 32 bit data into fewer bits in a way that
    > >>>>> enhances compression rather than hinders it.

    >
    > >>>> Or one simply uses a compression algorithm that has no
    > >>>> problems if words are larger than an octet. (The "typical"
    > >>>> image is 24bit btw. if it has colour.) Not to mention that a
    > >>>> compressor would only care about how large a data word is if
    > >>>> they need to understand the data.

    >
    > >>> The final compression stage is usually something simple like 'deflate'.
    > >>> It does very much care what the bytes look like.

    >
    > >> Deflate doesn't care at all. Only the archivable compression
    > >> rate may be suboptimal.

    >
    > > It cares about the patterns in the source data if you want to actually
    > > get useful compression.

    >
    > Any compression only works when there are patterns that the
    > compressor can exploit. You can't compress truly random noise.
    >
    > But you knew that, didn't you?
    >
    > > If you don't mind the file getting bigger then
    > > the algorithm works but it does not compress the image.

    >
    > So if I can show that Deflate reduces the image size, what
    > then?
    >
    > > Some patterns necessarily grow in size when compressed with a given
    > > lossless compression algorithm

    >
    > True, though 'pattern' usually implies a sort of regular
    > structure, not random noise as here.
    >
    > > and that problem is more likely to be
    > > encountered if you feed RGB interleaved image data or YCC for that
    > > matter into a simple lossless encoder.

    >
    > More likely than what? Than a long string like 'aaaaaaa...'
    > or '123123123123...'? Yep. However, how likely is that in
    > absolute terms?
    >
    > Let's try something, shall we? Let's examine some photograps using:
    >
    > for i in `find -type f -name *.jpg` ; do
    > j=$(basename $i)
    > raw=$(cat $i | djpeg -bmp | wc -c);
    > gzipped=$(cat $i | djpeg -bmp | gzip -9 | wc -c);
    > bzipped=$(cat $i | djpeg -bmp | bzip2 -9 | wc -c);
    > echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw -
    > $bzipped));
    > done | sort
    >
    > # filename BMP size gzipped smaller bzip2 smaller
    > # than raw BMP by: than raw BMP by:
    >
    > img_7982.jpg 3240054 1203452 1626737
    > img_7989.jpg 3240054 607967 1098620


    The topic was images with greater precision than 8 bits per channel per
    pixel and here you are with a test on 8 bit per channel per pixel
    images. Nice fail. You also excluded PNG, which would have worked
    better.

    With 16 and 24 bit per channel per pixel images, 8 bit compression
    algorithms see the least significant byte as a mostly random number. It
    makes simple compression relatively inefficient.
    --
    I will not see posts from Google because I must filter them as spam
    Kevin McMurtrie, Feb 9, 2013
    #14
  15. Kevin McMurtrie <> wrote:
    >> Let's try something, shall we? Let's examine some photograps using:


    >> for i in `find -type f -name *.jpg` ; do
    >> j=$(basename $i)
    >> raw=$(cat $i | djpeg -bmp | wc -c);
    >> gzipped=$(cat $i | djpeg -bmp | gzip -9 | wc -c);
    >> bzipped=$(cat $i | djpeg -bmp | bzip2 -9 | wc -c);
    >> echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw -
    >> $bzipped));
    >> done | sort


    >> # filename BMP size gzipped smaller bzip2 smaller
    >> # than raw BMP by: than raw BMP by:


    >> img_7982.jpg 3240054 1203452 1626737
    >> img_7989.jpg 3240054 607967 1098620


    > The topic was images with greater precision than 8 bits per channel per
    > pixel and here you are with a test on 8 bit per channel per pixel
    > images. Nice fail.


    Fine ...

    $ wget http://www.pauldebevec.com/Research/HDR/memorial.exr
    $ identify memorial.exr
    memorial.exr EXR 512x768 512x768+0+0 16-bit DirectClass 1.275MB 0.000u 0:00.000
    $ convert memorial.exr memorial.tiff
    $ identify memorial.tiff
    memorial.tiff TIFF 512x768 512x768+0+0 16-bit DirectClass 3.149MB 0.000u 0:00.000
    $ cat memorial.tiff | wc -c
    3149068
    $ cat memorial.tiff | gzip -9 | wc -c
    1495440
    $ cat memorial.tiff | bzip2 -9 | wc -c
    1000379

    $ wget http://www.pauldebevec.com/Research/HDR/rosette.hdr
    $ identify rosette.hdr
    rosette.hdr HDR 720x480 720x480+0+0 16-bit DirectClass 1.206MB 0.000u 0:00.000
    $ convert rosette.hdr rosette.tiff
    $ identify rosette.tiff
    rosette.tiff TIFF 720x480 720x480+0+0 16-bit DirectClass 1.994MB 0.000u 0:00.010
    $ cat rosette.tiff | wc -c
    1993688
    $ cat rosette.tiff | gzip -9 |wc -c
    1253365
    $ cat rosette.tiff | bzip2 -9 |wc -c
    1008238



    for i in *.tif ; do
    j=$(basename $i)
    raw=$(cat $i | wc -c);
    gzipped=$(cat $i | gzip -1 | wc -c); # NOTE: -1, not -9
    bzipped=$(cat $i | bzip2 -1 | wc -c); # NOTE: -1, not -9
    echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw - $bzipped));
    done
    >> # filename BMP size gzipped smaller bzip2 smaller
    >> # than raw BMP by: than raw BMP by:

    img_7989.tif 1845308 102314 110777
    img_7990.tif 1845306 136175 151548
    img_7995.tif 1845306 146296 161794
    img_7996.tif 1845306 145761 161077
    img_7999.tif 1845304 147134 158180
    img_8003.tif 1845304 135966 142766
    img_8006.tif 1845304 120031 122494
    img_8008.tif 1845304 113785 110353
    img_8364.tif 49135740 4046161 5182123
    img_8366.tif 49135740 6378014 7158338
    img_8369.tif 49135740 6434191 7187128
    img_8372.tif 49135740 6740377 7452299
    img_8374.tif 49135740 6746995 7485683
    img_8378.tif 49135738 6888844 7605149
    img_8382.tif 49135738 6823600 7534790
    img_8383.tif 49135738 6637156 7337317
    img_8387.tif 49135736 6141025 6893984
    img_8391.tif 49135740 3280325 4921019
    img_8393.tif 49135740 5391465 6870081
    img_8397.tif 49135738 5917166 7323711
    img_8399.tif 49135738 5143967 6592149
    img_8402.tif 49135738 5262113 6615646
    img_8404.tif 49135736 4655653 6021226
    img_8456.tif 49135740 3187314 5605733
    img_8457.tif 49135740 3168362 5591221
    img_8458.tif 49135740 3187660 5609055
    img_8459.tif 49135740 3267691 5531202
    img_8460.tif 49135740 3251903 5523974
    img_8461.tif 49135740 3246751 5518001
    img_8462.tif 49135740 3376322 5667275
    img_8463.tif 49135740 3357725 5651220
    img_8464.tif 49135740 3373621 5669392
    img_8465.tif 49135738 3356851 5666359
    img_8466.tif 49135738 3355841 5668496
    img_8467.tif 49135738 3349221 5672803
    img_8468.tif 49135738 3284232 5615183
    img_8469.tif 49135738 3283381 5632982
    img_8470.tif 49135738 3276690 5649802
    img_8471.tif 49135738 3150816 5513121
    img_8472.tif 49135738 3086458 5484817
    img_8473.tif 49135738 3138706 5508049
    img_8474.tif 49135736 3009784 5432774
    img_8475.tif 49135736 3010173 5443917
    img_8476.tif 49135736 3007676 5439904

    $ identify *.tif 2>/dev/null
    img_7989.tif TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_7990.tif[1] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_7995.tif[2] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_7996.tif[3] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_7999.tif[4] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_8003.tif[5] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_8006.tif[6] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_8008.tif[7] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u 0:00.000
    img_8364.tif[8] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8366.tif[9] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8369.tif[10] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8372.tif[11] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8374.tif[12] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8378.tif[13] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8382.tif[14] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.009
    img_8383.tif[15] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8387.tif[16] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.010u 0:00.000
    img_8391.tif[17] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8393.tif[18] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8397.tif[19] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8399.tif[20] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8402.tif[21] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8404.tif[22] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8456.tif[23] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8457.tif[24] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8458.tif[25] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8459.tif[26] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8460.tif[27] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8461.tif[28] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8462.tif[29] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8463.tif[30] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8464.tif[31] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8465.tif[32] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8466.tif[33] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8467.tif[34] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8468.tif[35] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8469.tif[36] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8470.tif[37] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8471.tif[38] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8472.tif[39] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8473.tif[40] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8474.tif[41] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8475.tif[42] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000
    img_8476.tif[43] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB 0.000u 0:00.000

    Any questions?

    And if you HAVE questions, FIRST try yourself if Deflate and
    friends do or do not create larger files than the original.


    > You also excluded PNG, which would have worked
    > better.


    Irrelevant.

    Your claims were:
    | Most lossless compression algorithms only work on data words that are
    | about 8 bits.


    > With 16 and 24 bit per channel per pixel images, 8 bit compression
    > algorithms see the least significant byte as a mostly random number. It
    > makes simple compression relatively inefficient.


    In the real world it seems that is not as large a problem as
    you seem to think it is ...

    -Wolfgang
    Wolfgang Weisselberg, Feb 11, 2013
    #15
  16. In article <>,
    Wolfgang Weisselberg <> wrote:

    > Kevin McMurtrie <> wrote:
    > >> Let's try something, shall we? Let's examine some photograps using:

    >
    > >> for i in `find -type f -name *.jpg` ; do
    > >> j=$(basename $i)
    > >> raw=$(cat $i | djpeg -bmp | wc -c);
    > >> gzipped=$(cat $i | djpeg -bmp | gzip -9 | wc -c);
    > >> bzipped=$(cat $i | djpeg -bmp | bzip2 -9 | wc -c);
    > >> echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw -
    > >> $bzipped));
    > >> done | sort

    >
    > >> # filename BMP size gzipped smaller bzip2 smaller
    > >> # than raw BMP by: than raw BMP by:

    >
    > >> img_7982.jpg 3240054 1203452 1626737
    > >> img_7989.jpg 3240054 607967 1098620

    >
    > > The topic was images with greater precision than 8 bits per channel per
    > > pixel and here you are with a test on 8 bit per channel per pixel
    > > images. Nice fail.

    >
    > Fine ...
    >
    > $ wget http://www.pauldebevec.com/Research/HDR/memorial.exr
    > $ identify memorial.exr
    > memorial.exr EXR 512x768 512x768+0+0 16-bit DirectClass 1.275MB 0.000u
    > 0:00.000
    > $ convert memorial.exr memorial.tiff
    > $ identify memorial.tiff
    > memorial.tiff TIFF 512x768 512x768+0+0 16-bit DirectClass 3.149MB 0.000u
    > 0:00.000
    > $ cat memorial.tiff | wc -c
    > 3149068
    > $ cat memorial.tiff | gzip -9 | wc -c
    > 1495440
    > $ cat memorial.tiff | bzip2 -9 | wc -c
    > 1000379
    >
    > $ wget http://www.pauldebevec.com/Research/HDR/rosette.hdr
    > $ identify rosette.hdr
    > rosette.hdr HDR 720x480 720x480+0+0 16-bit DirectClass 1.206MB 0.000u
    > 0:00.000
    > $ convert rosette.hdr rosette.tiff
    > $ identify rosette.tiff
    > rosette.tiff TIFF 720x480 720x480+0+0 16-bit DirectClass 1.994MB 0.000u
    > 0:00.010
    > $ cat rosette.tiff | wc -c
    > 1993688
    > $ cat rosette.tiff | gzip -9 |wc -c
    > 1253365
    > $ cat rosette.tiff | bzip2 -9 |wc -c
    > 1008238
    >
    >
    >
    > for i in *.tif ; do
    > j=$(basename $i)
    > raw=$(cat $i | wc -c);
    > gzipped=$(cat $i | gzip -1 | wc -c); # NOTE: -1, not -9
    > bzipped=$(cat $i | bzip2 -1 | wc -c); # NOTE: -1, not -9
    > echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw -
    > $bzipped));
    > done
    > >> # filename BMP size gzipped smaller bzip2 smaller
    > >> # than raw BMP by: than raw BMP by:

    > img_7989.tif 1845308 102314 110777
    > img_7990.tif 1845306 136175 151548
    > img_7995.tif 1845306 146296 161794
    > img_7996.tif 1845306 145761 161077
    > img_7999.tif 1845304 147134 158180
    > img_8003.tif 1845304 135966 142766
    > img_8006.tif 1845304 120031 122494
    > img_8008.tif 1845304 113785 110353
    > img_8364.tif 49135740 4046161 5182123
    > img_8366.tif 49135740 6378014 7158338
    > img_8369.tif 49135740 6434191 7187128
    > img_8372.tif 49135740 6740377 7452299
    > img_8374.tif 49135740 6746995 7485683
    > img_8378.tif 49135738 6888844 7605149
    > img_8382.tif 49135738 6823600 7534790
    > img_8383.tif 49135738 6637156 7337317
    > img_8387.tif 49135736 6141025 6893984
    > img_8391.tif 49135740 3280325 4921019
    > img_8393.tif 49135740 5391465 6870081
    > img_8397.tif 49135738 5917166 7323711
    > img_8399.tif 49135738 5143967 6592149
    > img_8402.tif 49135738 5262113 6615646
    > img_8404.tif 49135736 4655653 6021226
    > img_8456.tif 49135740 3187314 5605733
    > img_8457.tif 49135740 3168362 5591221
    > img_8458.tif 49135740 3187660 5609055
    > img_8459.tif 49135740 3267691 5531202
    > img_8460.tif 49135740 3251903 5523974
    > img_8461.tif 49135740 3246751 5518001
    > img_8462.tif 49135740 3376322 5667275
    > img_8463.tif 49135740 3357725 5651220
    > img_8464.tif 49135740 3373621 5669392
    > img_8465.tif 49135738 3356851 5666359
    > img_8466.tif 49135738 3355841 5668496
    > img_8467.tif 49135738 3349221 5672803
    > img_8468.tif 49135738 3284232 5615183
    > img_8469.tif 49135738 3283381 5632982
    > img_8470.tif 49135738 3276690 5649802
    > img_8471.tif 49135738 3150816 5513121
    > img_8472.tif 49135738 3086458 5484817
    > img_8473.tif 49135738 3138706 5508049
    > img_8474.tif 49135736 3009784 5432774
    > img_8475.tif 49135736 3010173 5443917
    > img_8476.tif 49135736 3007676 5439904
    >
    > $ identify *.tif 2>/dev/null
    > img_7989.tif TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_7990.tif[1] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_7995.tif[2] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_7996.tif[3] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_7999.tif[4] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_8003.tif[5] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_8006.tif[6] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_8008.tif[7] TIFF 639x479 639x479+0+0 16-bit DirectClass 1.845MB 0.000u
    > 0:00.000
    > img_8364.tif[8] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8366.tif[9] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8369.tif[10] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8372.tif[11] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8374.tif[12] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8378.tif[13] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8382.tif[14] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.009
    > img_8383.tif[15] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8387.tif[16] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.010u 0:00.000
    > img_8391.tif[17] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8393.tif[18] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8397.tif[19] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8399.tif[20] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8402.tif[21] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8404.tif[22] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8456.tif[23] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8457.tif[24] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8458.tif[25] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8459.tif[26] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8460.tif[27] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8461.tif[28] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8462.tif[29] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8463.tif[30] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8464.tif[31] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8465.tif[32] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8466.tif[33] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8467.tif[34] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8468.tif[35] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8469.tif[36] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8470.tif[37] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8471.tif[38] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8472.tif[39] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8473.tif[40] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8474.tif[41] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8475.tif[42] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    > img_8476.tif[43] TIFF 3504x2336 3504x2336+0+0 16-bit DirectClass 49.14MB
    > 0.000u 0:00.000
    >
    > Any questions?
    >
    > And if you HAVE questions, FIRST try yourself if Deflate and
    > friends do or do not create larger files than the original.
    >
    >
    > > You also excluded PNG, which would have worked
    > > better.

    >
    > Irrelevant.
    >
    > Your claims were:
    > | Most lossless compression algorithms only work on data words that are
    > | about 8 bits.
    >
    >
    > > With 16 and 24 bit per channel per pixel images, 8 bit compression
    > > algorithms see the least significant byte as a mostly random number. It
    > > makes simple compression relatively inefficient.

    >
    > In the real world it seems that is not as large a problem as
    > you seem to think it is ...
    >
    > -Wolfgang



    Thank you for proving my point that 8 bit compression algorithms don't
    work well on 16 bit images. Those compression ratios are so low that
    they're a waste of CPU time.

    Compression algorithms for 16 and 24 bit per channel per pixel images
    aren't easy and that's why they're not common. They usually have layers
    of filtering that adapt typical image data into patterns more easily
    seen by common 8 bit lossless compression algorithms. One such filter
    tries to predict future pixels from past pixels, then only stores the
    difference between the predicted values and actual values. This
    technique produces streams of small, easily compressed, numbers when
    prediction is good. Another filter may regroup bits to create areas of
    seldom changing values, like splitting 16 bit numbers into a group of
    high bytes and a group of low bytes. The high bytes might not change
    frequently and compress well. JPEG2K and more advanced algorithms go
    further to separate data as 2D frequencies. As frequency data, visual
    patterns, and even deficiencies in the camera, convert to repeating data
    patterns that may compress.

    No compression ratio is guaranteed for lossless algorithms but
    understanding the data makes the difference between averaging 5% and 50%
    in savings.
    --
    I will not see posts from Google because I must filter them as spam
    Kevin McMurtrie, Feb 12, 2013
    #16
  17. Kevin McMurtrie <> wrote:
    > Wolfgang Weisselberg <> wrote:
    >> Kevin McMurtrie <> wrote:


    >> >> Let's try something, shall we? Let's examine some photograps using:


    >> >> for i in `find -type f -name *.jpg` ; do
    >> >> j=$(basename $i)
    >> >> raw=$(cat $i | djpeg -bmp | wc -c);
    >> >> gzipped=$(cat $i | djpeg -bmp | gzip -9 | wc -c);
    >> >> bzipped=$(cat $i | djpeg -bmp | bzip2 -9 | wc -c);
    >> >> echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw -
    >> >> $bzipped));
    >> >> done | sort


    >> >> # filename BMP size gzipped smaller bzip2 smaller
    >> >> # than raw BMP by: than raw BMP by:


    >> >> img_7982.jpg 3240054 1203452 1626737
    >> >> img_7989.jpg 3240054 607967 1098620


    >> > The topic was images with greater precision than 8 bits per channel per
    >> > pixel and here you are with a test on 8 bit per channel per pixel
    >> > images. Nice fail.


    >> Fine ...


    >> $ wget http://www.pauldebevec.com/Research/HDR/memorial.exr
    >> $ identify memorial.exr
    >> memorial.exr EXR 512x768 512x768+0+0 16-bit DirectClass 1.275MB 0.000u
    >> 0:00.000
    >> $ convert memorial.exr memorial.tiff
    >> $ identify memorial.tiff
    >> memorial.tiff TIFF 512x768 512x768+0+0 16-bit DirectClass 3.149MB 0.000u
    >> 0:00.000
    >> $ cat memorial.tiff | wc -c
    >> 3149068
    >> $ cat memorial.tiff | gzip -9 | wc -c
    >> 1495440
    >> $ cat memorial.tiff | bzip2 -9 | wc -c
    >> 1000379


    >> $ wget http://www.pauldebevec.com/Research/HDR/rosette.hdr
    >> $ identify rosette.hdr
    >> rosette.hdr HDR 720x480 720x480+0+0 16-bit DirectClass 1.206MB 0.000u
    >> 0:00.000
    >> $ convert rosette.hdr rosette.tiff
    >> $ identify rosette.tiff
    >> rosette.tiff TIFF 720x480 720x480+0+0 16-bit DirectClass 1.994MB 0.000u
    >> 0:00.010
    >> $ cat rosette.tiff | wc -c
    >> 1993688
    >> $ cat rosette.tiff | gzip -9 |wc -c
    >> 1253365
    >> $ cat rosette.tiff | bzip2 -9 |wc -c
    >> 1008238


    >> for i in *.tif ; do
    >> j=$(basename $i)
    >> raw=$(cat $i | wc -c);
    >> gzipped=$(cat $i | gzip -1 | wc -c); # NOTE: -1, not -9
    >> bzipped=$(cat $i | bzip2 -1 | wc -c); # NOTE: -1, not -9
    >> echo -e $j "\t" $raw "\t" $(($raw - $gzipped)) " \t" $(($raw -
    >> $bzipped));
    >> done
    >> >> # filename BMP size gzipped smaller bzip2 smaller
    >> >> # than raw BMP by: than raw BMP by:

    >> img_7989.tif 1845308 102314 110777
    >> img_7990.tif 1845306 136175 151548

    [...]
    >> img_8474.tif 49135736 3009784 5432774
    >> img_8475.tif 49135736 3010173 5443917
    >> img_8476.tif 49135736 3007676 5439904


    >> Any questions?


    >> And if you HAVE questions, FIRST try yourself if Deflate and
    >> friends do or do not create larger files than the original.

    [...]

    >> Your claims were:
    >> | Most lossless compression algorithms only work on data words that are
    >> | about 8 bits.


    >> > With 16 and 24 bit per channel per pixel images, 8 bit compression
    >> > algorithms see the least significant byte as a mostly random number. It
    >> > makes simple compression relatively inefficient.


    >> In the real world it seems that is not as large a problem as
    >> you seem to think it is ...


    > Thank you for proving my point that 8 bit compression algorithms don't
    > work well on 16 bit images. Those compression ratios are so low that
    > they're a waste of CPU time.


    "only work on data words that are about 8 bits" --- your claim
    --- has been completely shattered.

    "don't work well" is a different claim.

    > Compression algorithms for 16 and 24 bit per channel per pixel images
    > aren't easy and that's why they're not common.


    Please show me where the deflate *algorithm* (not a specific
    implementation) is in any way not able to be set to 16, 24 or
    any other number of bits per 'data word'.

    > They usually have layers
    > of filtering that adapt typical image data into patterns more easily
    > seen by common 8 bit lossless compression algorithms.


    They have filters that make the compression easier for a
    given compression algorithm, true. Look up what bzip2 does:
    reordering to faciliate exactly that. Finding a smart way
    to write the data is the hard work --- and THAT part is now
    sensitive to specific patterns. (Try JPEG-lossless compression
    on a text file!)

    However, which "common 8 bit lossless compression algorithms"
    ^^^^^
    are you referring to? Please show me any compression algorithm
    (not an implementation of one!) that's intrinsically 8 bit
    only --- one that *can't* be used for other than 8 bit patterns!

    Guess you can't.

    Guess you can't even admit you can't.

    That's the part I'm trying to get you to understand.


    > One such filter
    > tries to predict future pixels from past pixels, then only stores the
    > difference between the predicted values and actual values. This
    > technique produces streams of small, easily compressed, numbers when
    > prediction is good. Another filter may regroup bits to create areas of
    > seldom changing values, like splitting 16 bit numbers into a group of
    > high bytes and a group of low bytes. The high bytes might not change
    > frequently and compress well. JPEG2K and more advanced algorithms go
    > further to separate data as 2D frequencies. As frequency data, visual
    > patterns, and even deficiencies in the camera, convert to repeating data
    > patterns that may compress.


    True, and granted, that is the part that takes a lot of
    smarts to pull off and where the payoff comes from.

    > No compression ratio is guaranteed for lossless algorithms but
    > understanding the data makes the difference between averaging 5% and 50%
    > in savings.


    True. Though bzip2 -1 (i.e. fastest, least compression)
    averages 8.5% savings in my tiffs, which is about 60% better
    than your 5%.

    However bzip2 -9 for memorial.tiff yields 68%, and 50.6%
    for rosette.tiff ... does it understand the data?

    -Wolfgang
    Wolfgang Weisselberg, Feb 13, 2013
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Garrison

    ImageMagick and lossless JPEG rotation?

    Jim Garrison, Sep 30, 2003, in forum: Digital Photography
    Replies:
    8
    Views:
    11,411
    C0mdrData
    Oct 1, 2003
  2. Bob & Anni

    JPEG lossless re-sizing?

    Bob & Anni, Dec 7, 2003, in forum: Digital Photography
    Replies:
    18
    Views:
    7,963
    Guido Vollbeding
    Dec 10, 2003
  3. nick c

    Re: JPEG 9 new lossless JPEG standard

    nick c, Jan 22, 2013, in forum: Digital Photography
    Replies:
    0
    Views:
    158
    nick c
    Jan 22, 2013
  4. David Dyer-Bennet

    Re: JPEG 9 new lossless JPEG standard

    David Dyer-Bennet, Jan 23, 2013, in forum: Digital Photography
    Replies:
    0
    Views:
    142
    David Dyer-Bennet
    Jan 23, 2013
  5. Joe Kotroczo

    Re: JPEG 9 new lossless JPEG standard

    Joe Kotroczo, Jan 23, 2013, in forum: Digital Photography
    Replies:
    0
    Views:
    136
    Joe Kotroczo
    Jan 23, 2013
Loading...

Share This Page