Page 1 of 2 12 LastLast
Results 1 to 30 of 33

Thread: JPEG on Steroids

  1. #1
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts

    JPEG on Steroids

    Hi folks,

    one of the participants for the "ICIP 2016 Grand Challenge" was "JPEG on Steroids", an improved JPEG encoder that includes optimized quantization tables and a soft-threshold quantizer. The tools presented there are not new, they are pretty much equivalent to what you find in "mozjpeg" as well, problably somewhat simplified and streamlined. Also included is an improved deringing tool that works best on black on white / white on black images.


    Thus, nothing particularly new, but since this codec performed so nicely in the evaluation, I want to share the source, hoping that other people may find this useful as well.


    As usual, you find the lastest version of libjpeg on github:


    https://github.com/thorfdbg/libjpeg


    Greetings, Thomas

  2. The Following User Says Thank You to thorfdbg For This Useful Post:

    lorents17 (13th November 2016)

  3. #2
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    What was the reason not to perform these tests with mozjpeg itself?

  4. #3
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    What was the reason not to perform these tests with mozjpeg itself?
    Nothing particular, really. mozjpeg did not enter the competition - or rather, the mozilla team arrived with Daala, which performs indeed better (no surprise, really, it's a much more modern design), but I also wanted to see JPEG to complete the picture. I, quite honestly, wanted to understand what mozjpeg was doing anyhow and wanted to learn how it performs. Now I'm one of the guys that only understand a technology fully after having implemented it myself. (-: So I took the chance.

    Indeed, the applause should go to mozjpeg. I'm not claiming this for myself.

  5. #4
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by thorfdbg View Post
    Indeed, the applause should go to mozjpeg. I'm not claiming this for myself.
    I am familiar how mozjpeg performs and I'm wondering if I should check out jpeg-on-steroids or not.

    Is jpeg-on-steroids just a rename and a compatible reimplementation of mozjpeg to make it possible to enter the competition you held?

    I'm assuming that the 'jpeg-on-steroids' was called 'jpeg (visual)' in your presentation. Is this correct?

  6. #5
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    I am familiar how mozjpeg performs and I'm wondering if I should check out jpeg-on-steroids or not.
    Question is - what do you expect - or what do you want to find?
    Quote Originally Posted by Jyrki Alakuijala View Post
    Is jpeg-on-steroids just a rename and a compatible reimplementation of mozjpeg to make it possible to enter the competition you held?
    No, it's not a rename. It's a completely different codec, and it is not *exactly* the mozjpeg algorithm either. So while mozjpeg is based on Tom Lane's work, mine is a C++ codec that also includes JPEG LS and the complete JPEG standard.

    What I attempted to do here is to find a good compromize between complexity and performance. You find a couple of indicators in the paper. For example, mozjpeg has a very similar dynamic programming implementation for the soft-threshold quantizer (there called "Trellis-Quantization", but that is in my world something different, a word I would reserve for the JPEG 2000 TCQ), though they test extensively through all possible quantizer buckets. I considered this as "too complex" and tried to cut it down the "trellis" to just two quantizers per stage - which is really good enough as you see.

    Other things I just "stole", like the quantization tables, which were also "stolen" from existing publications (of course, credits and sources are given).

    Other things are new: "JPEG on steroids" includes a simple deadzone quantizer, which unfortunately we could not test visually, but it should approximately perform mid-way between the standard quantizer and the soft-threshold quantization in the code. Also new is the de-ringing operation. mozjpeg has a different filter, though I have reasons to believe that mine works more reliable and robust. Unfortunately, we could not test it here either, there were no compound images in the dataset. One example is in my slides I made for ICIP.

    There are a couple of tricks in mozjpeg I did not want to copy, for example the optimization of the progression modes: It's just too complex, and gains are too low to make this worthwhile. The scan pattern selected by the "-qv" switch works very well in most cases, so I left it as such.

    I also tried a couple of other tricks, but they did not make it into the final code. There is an extended soft-threshold algorithm published by the University of Waterloo that jointly also optimizes the quantization matrix. I tried this, but while it improved the PSNR, it did this mostly by "flattening" the matrix. This is known to be PSNR-optimal (i.e. a flat matrix), but its bad visually. So their research result is correct, but not helpful for the applications I had in mind, so this code went away. It's still living in a side branch somewhere.

    Hence, I hope that I have convinced you that while "JPEG on steroids" is really to a large degree based on mozjpeg, it is not exactly the same and there is (hopefully) a minimum set of original work in it. Anyhow, yes, mozjpeg was clearly quoted in the presentation and in the paper as I have to thank the folks having implemented this first in a practical way, and providing their work to the public.

    Mozjpeg is, of course, also standing on the shoulders of giants, and when talking to their scientific partner a while ago in Valencia, it was also clear that they knew their job very well of finding the right publications.

    That's all how science works: From research to application. You find a very long list of papers on JPEG improvements in my ICIP paper - it was more a literature survey than a scientific work this year.
    Quote Originally Posted by Jyrki Alakuijala View Post
    I'm assuming that the 'jpeg-on-steroids' was called 'jpeg (visual)' in your presentation. Is this correct?
    Correct.

  7. #6
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Which flags are the ideal configuration for the JPEG on Steroids?

    $ ./jpeg -q 89 x.pnm x89.jpg

    Does this give the best performance (assuming that I wanted a file size that was best matched with quality 89)?

  8. #7
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Here is one image (bees.png) with four different jpeg encoders to the same size. https://drive.google.com/drive/u/1/f...k1VQU9nTGh3NGs

    I shot the photo using a Canon EOS 600D DSLR, stored initially as a high quality jpeg, and applied 4x4 subsampling using gimp before storing as a png.

    To the extent possible under law, Jyrki Alakuijala has waived all copyright and related or neighboring rights to these photos. This work is published from: Switzerland.

  9. #8
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Which flags are the ideal configuration for the JPEG on Steroids?
    The settings I used for the test are on github. (-:
    Code:
     jpeg -oz -h -qt 3 -v -s 1x1,2x2,2x2 -q  in.ppm out.jpg
    "-qt 3" selects the ImageMagick quantizer. "-v" selects the progressive mode, "-h" optimizes the Huffman tables, "-oz" is the soft-threshold quantizer, "-s 1x1,2x2,2x2" selects 420 subsampling, and -q selects the quality. Note well: Enabling all the nice add-ons does not improve the quality, it lowers the rate. So, IOWs, "-q 89" means a somewhat lower quality *with* the addons than without them, but this is overcompensated by the rate reduction.
    Quote Originally Posted by Jyrki Alakuijala View Post
    $ ./jpeg -q 89 x.pnm x89.jpg
    That just gives just the Annex K quantization with no further tricks.
    Quote Originally Posted by Jyrki Alakuijala View Post
    Does this give the best performance (assuming that I wanted a file size that was best matched with quality 89)?
    No. (-: "JPEG on steroids" is first and foremost a reference, so you have to ask for all the nice tricks.

  10. #9
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by thorfdbg View Post
    The settings I used for the test are on github. (-:
    Code:
     jpeg -oz -h -qt 3 -v -s 1x1,2x2,2x2 -q  in.ppm out.jpg
    "-qt 3" selects the ImageMagick quantizer. "-v" selects the progressive mode, "-h" optimizes the Huffman tables, "-oz" is the soft-threshold quantizer, "-s 1x1,2x2,2x2" selects 420 subsampling, and -q selects the quality. Note well: Enabling all the nice add-ons does not improve the quality, it lowers the rate. So, IOWs, "-q 89" means a somewhat lower quality *with* the addons than without them, but this is overcompensated by the rate reduction. That just gives just the Annex K quantization with no further tricks. No. (-: "JPEG on steroids" is first and foremost a reference, so you have to ask for all the nice tricks.
    Would it be possible to put the currently known best practice as the defaults? Conservative and uninitiated users will stick to defaults, and it is sad if they get worse behavior.

    In Guetzli we rather consistently see worse behavior with yuv420 than with yuv444, and guetzli rarely chooses to use yuv420 even when asked (because the 444 is just smaller for the given quality). How sure are you about the usefulness of -s 1x1,2x2,2x2 ?

    I will regenerate the image in bees test tomorrow using the command line you sent (with and without yuv420).

  11. #10
    Member
    Join Date
    Oct 2016
    Location
    mumbai
    Posts
    7
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by thorfdbg View Post
    Nothing particular, really. mozjpeg did not enter the competition - or rather, the mozilla team arrived with Daala, which performs indeed better (no surprise, really, it's a much more modern design), but I also wanted to see JPEG to complete the picture. I, quite honestly, wanted to understand what mozjpeg was doing anyhow and wanted to learn how it performs. Now I'm one of the guys that only understand a technology fully after having implemented it myself. (-: So I took the chance.

    Indeed, the applause should go to mozjpeg. I'm not claiming this for myself.
    Thanks for a information.....

  12. #11
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Would it be possible to put the currently known best practice as the defaults? Conservative and uninitiated users will stick to defaults, and it is sad if they get worse behavior.
    At this time, I would prefer not to. This is actually a (subset of) the JPEG XT reference software, and I would prefer to remain consistent what the tools for XT reference testing do. That's currently the Annex K matrix in the reference tests.

    Quote Originally Posted by Jyrki Alakuijala View Post
    In Guetzli we rather consistently see worse behavior with yuv420 than with yuv444, and guetzli rarely chooses to use yuv420 even when asked (because the 444 is just smaller for the given quality). How sure are you about the usefulness of -s 1x1,2x2,2x2 ?
    Honestly, not at all. It's the option that was selected for the ICIP Grand Challenge, more or less because it is what most other codecs did as well, including HEVC and Daala. I made a PSNR test upfront which showed that 420 works better for lower bitrates, and worse for higher bitrates, but to be really sure, one would need to make a subjective test - and we (Qualinet) didn't have the capacity for such a pre-test.

    So the current set of options is "known good", but probably not yet the ideal selection.

  13. #12
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by arjupraja143 View Post
    Thanks for a information.....
    I'm sorry - how can I help you?

  14. #13
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    I have now run the 'bees' with jpeg -oz -h -qt 3 -v -s 1x1,2x2,2x2 -q 95 (-q 95 is only 35.7 kB, -q 96 was already 42.2 kB) and jpeg -oz -h -qt 3 -v -s 1x1,1x1,1x1 -q 90.

    I interleaved the compressed files with copies of the original. This makes viewing easier.

    I believe this is already high enough bitrate where yuv420 is rather harmful, and the reduction of color detail even on the relatively 'bleach' bees picture is disturbing. For example, the pistils of the flowers lose color and definition in yuv420.

    My eyes rank the quality (= lack of artefacts, preservation of detail, preservation of feel of materials, preservation of colors) of these images as follows:

    1. Original
    2. Guetzli
    3. Mozjpeg with yuv444 and jpeg-on-steroids yuv444 -- minor differences, but equally good to my eyes.
    4. jpeg-on-steroids yuv420 q95 and imagemagick convert yuv444 -- yuv420 spoils colors and specific details of flowers, but image is less artefacty; imagemagick yuv444 is more artefacty than mozjpeg, jpeg-on-steroids and guetzli.

    https://drive.google.com/drive/u/1/f...k1VQU9nTGh3NGs

    Disclaimer: this kind of testing is subjective.
    Last edited by Jyrki Alakuijala; 3rd November 2016 at 16:39.

  15. #14
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    https://drive.google.com/drive/u/1/f...k1VQU9nTGh3NGs

    Added WebP lossy, BPG, Daala, and FLIF versions with similar sizes.

    Just for reference WebP -near_lossless 40 was around 89 kB, and lossless codecs at 142 kB (FLIF), 146 kB (WebP) and 174 kB (ZopfliPNG).

    Personal visual quality ranking (subjective testing) and respective butteraugli scores in []:

    1. Original [0.0]
    2. Daala [?] There is some gamma re-interpretation in png2yuv-daala-examples pipeline, changing the colors radically. Other than that, daala does a wonderful job with this image.
    3. PBG [1.07]
    4. Guetzli [1.05]
    5. FLIF [1.42]
    6. Mozjpeg with yuv444 and jpeg-on-steroids yuv444 [1.52,1.50] -- minor differences, but equally good to my eyes.
    7. WebP lossy 420 [1.21]
    8. jpeg-on-steroids yuv420 q95 and imagemagick convert yuv444 [1.29,1.36]-- yuv420 spoils colors and specific details of flowers, but image is less artefacty; imagemagick yuv444 is more artefacty than mozjpeg, jpeg-on-steroids and guetzli.
    9. pngquant-zopflipng (just for reference)

    The images here are
    2.65 bits per pixel, i.e., less lossy than what is typically used in compression comparisons.
    Last edited by Jyrki Alakuijala; 4th November 2016 at 17:14.

  16. #15
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    1. Original 2. Guetzli 3. Mozjpeg with yuv444 and jpeg-on-steroids yuv444 -- minor differences, but equally good to my eyes. 4. jpeg-on-steroids yuv420 q95 and imagemagick convert yuv444 -- yuv420 spoils colors and specific details of flowers, but image is less artefacty; imagemagick yuv444 is more artefacty than mozjpeg, jpeg-on-steroids and guetzli.
    I only made a very quick* test with guetzli, and on the image I tested (boats) and the quality I picked (-q 60) I agree with the ranking.

    *quick: Actually, except that I only tested with a single image, there is nothing "quick" about guetzli. (-; Could you guys please use a sane build system? I first had to install java8 (manually, Debian doesn't have it), then build bazel, then build guetzli. Anyhow, guetzli is not exactly fast either, but the results are nice.

  17. #16
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by thorfdbg View Post
    I only made a very quick* test with guetzli, and on the image I tested (boats) and the quality I picked (-q 60) I agree with the ranking.

    *quick: Actually, except that I only tested with a single image, there is nothing "quick" about guetzli. (-; Could you guys please use a sane build system? I first had to install java8 (manually, Debian doesn't have it), then build bazel, then build guetzli. Anyhow, guetzli is not exactly fast either, but the results are nice.
    Thanks for trying it out.

    Are you sure you used guetzli with quality 60? https://github.com/google/guetzli/bl...zli/quality.cc clamps guetzli's minimal quality to 70, but it shouldn't work very well below quality 80. The barely visible differences isosurface has very different shapes at quality 90-95 and at quality 75, and butteraugli doesn't try to model this yet.

    ... and yes, I fully agree that it is insanely slow (probably a lot more than 100x slower than jpeg-on-steroids or mozjpeg), and that bazel is complicated. Consider filing an issue in our github about the complications of bazel and we can point the bazel engineers to it.

  18. #17
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Thanks for trying it out. Are you sure you used guetzli with quality 60? https://github.com/google/guetzli/bl...zli/quality.cc clamps guetzli's minimal quality to 70, but it shouldn't work very well below quality 80. The barely visible differences isosurface has very different shapes at quality 90-95 and at quality 75, and butteraugli doesn't try to model this yet.
    Yes, I'm sure I tried at 60. I had to patch the source, of course, but I wanted to see which type of defects it picked up. Though the results were more pleasing than those of JPEG on Steroids. I tested on "Boats" (the image should be known, I believe) and the result was a bit sharper in the ropes (often a problem there) and less defects in the sky (often tends to accumulate some blockiness). Of course, when comparing with JPEG on Steroids, I had to adjust the compression parameter such that the output file size was more or less identical. I.e. I compare at constant bpp, not at constant "q" because the latter is not well-defined either.

    Quote Originally Posted by Jyrki Alakuijala View Post
    ... and yes, I fully agree that it is insanely slow (probably a lot more than 100x slower than jpeg-on-steroids or mozjpeg), and that bazel is complicated. Consider filing an issue in our github about the complications of bazel and we can point the bazel engineers to it.
    I really don't mind about speed when exploring scientific ideas, so no problem on my side. The results are convincing. I should have had this before ICIP.

    The problem with bazel is really its overall requirements. A build system should simply run instantly on a typical developer machine. Java8 is not exactly found on developer machines anymore, so the preconditions for the build system are larger than the preconditions for the actual build. That's the "insane" part about it. I wasted more times getting the build system to run than compiling the actual code. (-:

    Look at "autoconf": All it requires is a POSIX compliant shell and - of course - the compiler and -in the end -make. This is something you can expect to have. Or "cmake" also works nicely.

  19. #18
    Member
    Join Date
    Mar 2016
    Location
    Croatia
    Posts
    181
    Thanks
    74
    Thanked 10 Times in 10 Posts
    did anyone try to compare it with smallfry method?

  20. #19
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by dado023 View Post
    did anyone try to compare it with smallfry method?
    I did not try it. Smallfry didn't compile on my machine straight out of the github.

  21. #20
    Member
    Join Date
    Dec 2011
    Location
    Cambridge, UK
    Posts
    437
    Thanks
    137
    Thanked 152 Times in 100 Posts
    Quote Originally Posted by thorfdbg View Post
    I only made a very quick* test with guetzli, and on the image I tested (boats) and the quality I picked (-q 60) I agree with the ranking.

    *quick: Actually, except that I only tested with a single image, there is nothing "quick" about guetzli. (-; Could you guys please use a sane build system? I first had to install java8 (manually, Debian doesn't have it), then build bazel, then build guetzli. Anyhow, guetzli is not exactly fast either, but the results are nice.
    I notice the bazel system goes into detail about how to modify your apt repository and therefore has assumptions you have root access on your local system and also don't mind making changes that affect all users. This really shouldn't be a prerequisite to compile anything, especially wanting the latest bleeding edge Java just to compile C++! Looking at it, it looks like a basic Makefile is pretty trivial to construct instead and almost certainly this would be quicker to write than to install the prerequisites by hand (unless you happen to be on one of the supported systems with root access).

    I got most of the way there, but gave up and started my proper work again when I ran into issues with gflags refusing to accept a prefix=/blah option (I guess it's some arcane cmake syntax to do it instead. gah!)

    Anyway, something like this to start from (needs work):

    Code:
    GU_LIB=libguetzli.so
    GU_BIN=gueutzli
    
    all: $(GU_LIB) $(GU_BIN)
    CXX=g++
    CXXFLAGS=-g -O3 -Wno-sign-compare
    INCLUDES= -I. -I../butteraugli
    LIBS=     -L. -L../butteraugli
    
    LIB_OBJ=\
        guetzli/butteraugli_comparator.o \
        guetzli/dct_double.o \
        guetzli/debug_print.o \
        guetzli/entropy_encode.o \
        guetzli/fdct.o \
        guetzli/gamma_correct.o \
        guetzli/idct.o \
        guetzli/jpeg_data.o \
        guetzli/jpeg_data_decoder.o \
        guetzli/jpeg_data_encoder.o \
        guetzli/jpeg_data_reader.o \
        guetzli/jpeg_data_writer.o \
        guetzli/jpeg_huffman_decode.o \
        guetzli/output_image.o \
        guetzli/preprocess_downsample.o \
        guetzli/processor.o \
        guetzli/quality.o \
        guetzli/quantize.o \
        guetzli/score.o
    
    BIN_OBJ=guetzli/guetzli.o
    
    %.o: %.cc
        $(CXX) $(CFLAGS) -fPIC $(INCLUDES) -c $< -o $@
    
    $(GU_LIB): $(LIB_OBJ)
        $(CXX) -shared -o $@ $(LIB_OBJ) $(LDFLAGS)
    
    $(GU_BIN): $(GU_LIB) $(BIN_OBJ)
        $(CXX) -o $@ $(BIN_OBS) $(LDFLAGS) $(LIBS)
    
    clean:
        -rm *.o */*.o
        -rm $(GU_LIB) $(GU_BIN)
    But seriously, if it's less hassle to write the missing build system than use your provided one, then you've lost 99% of the audience.

  22. The Following User Says Thank You to JamesB For This Useful Post:

    Jyrki Alakuijala (8th November 2016)

  23. #21
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Thank you for the feedback.

  24. #22
    Member
    Join Date
    Dec 2011
    Location
    Cambridge, UK
    Posts
    437
    Thanks
    137
    Thanked 152 Times in 100 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Thank you for the feedback.
    Sorry if the tone came over a bit whingy. I just have a loathing for unnecessarily complex build environments, but I'm also a bit of a luddite stuck in my traditional C ways. (I was tortured by a buggy C++ compiler in my more formative years.)

    As for the program, I think I'll have to leave it to others to judge the subjective components better. My eyesight is rubbish and I find it hard to tell the images apart. (That's probably a good thing though!)

  25. #23
    Member
    Join Date
    Nov 2014
    Location
    California
    Posts
    122
    Thanks
    36
    Thanked 33 Times in 24 Posts
    With average PSNR over 40 for all images (except Daala), most people will not see any differences. I wonder why the quality was set up so high.

  26. #24
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by hexagone View Post
    With average PSNR over 40 for all images (except Daala), most people will not see any differences. I wonder why the quality was set up so high.
    Seven reasons for high quality:

    1) I personally like images that look good, so I want to put my efforts in making good looking images more economic. For example, from the bees image example I prefer the original over any of the compressed images.

    2) Our tests show that people actually can see these differences and have preferences that mostly match with butteraugli (and guetzli).

    3) If a recompression system doesn't require manual verification of its results, it can be tens of thousands of times cheaper to deploy -- cheap and safe enough that people will actually deploy it.

    4) Video compression field has advanced the dense image compression a lot -- and the high quality photo compression field has been more like a forgotten corner. So, more density gain opportunity exists for high visual quality compression.

    5) High quality settings in digital photography (including mobile phones) gives a competitive edge. I want to make digital photography cheaper and faster without losing the image quality.

    6) Sites like flickr providing high quality photos hints that high quality settings can be relevant.

    7) There is significant non-linearity in the human vision between high and medium quality. Particularly the balance of error perceived in red+green and red-green channels changes a lot. The red+green is much more over-weighted over red-green at the highest quality (think 10 : 1). At medium visual quality they are a lot more evenly weighted (think 3 : 1). If we aim for one, we can possibly perform badly at the other. We just choose to excel at high quality for now.

  27. #25
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Seven reasons for high quality:
    Actually, one should understand that compression to near-lossless is a different type of problem than compressing with loss. The first case - "near threshold compression" - is a matter of artifact detection. There are rather good models for this, implemented in VDP for example. The second - "super-threshold" - is a much harder problem because it also includes effects of how irritating or distorting a detectable defect is. So whether a particular viewer prefers "blocks" to "blur". This is hard to model, and also a matter of personal preference and personal experience. So if you say that persons detected q=85 quality defects, I wonder which type of test protocol you picked to assess this, and how significant the results are - statistically. I personally do not see much at this quality, at least not in single-stimulus tests. There are some images that pick up defects there ("tools" or "cafe" are two), but your average photograph will not show a significant difference.

  28. #26
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    [QUOTE=thorfdbg;50825]So if you say that persons detected q=85 quality defects, I wonder which type of test protocol you picked to assess this, and how significant the results are - statistically./QUOTE]

    We will publish something soon on this. It will be guetzli at quality 94 vs libjpeg at similar bytesize, typically quality 90.

  29. #27
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    The test protocol keeps a 400x400 original without flickering, and flips between two compressed images on top of each other. We show each image about 2.2 seconds and keep a 600 ms dark gray image in between. All within the same dark gray background frame.

    If one flips faster or doesn't show a gray frame in between, the rating results are different.

  30. #28
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    The test protocol keeps a 400x400 original without flickering, and flips between two compressed images on top of each other. We show each image about 2.2 seconds and keep a 600 ms dark gray image in between. All within the same dark gray background frame. If one flips faster or doesn't show a gray frame in between, the rating results are different.
    Yes, of course. If you just switch back and forth, you also make use of the temporal channel of the HVS which can amplify defects (to the better or worse) and makes them more detectable. That's a different test than what we did at ICIP which was absolute category ranking, i.e. only the distorted images were shown, but with a hidden reference (i.e. the test set to be ranked had both compressed and uncompressed images, but in an unpredictable order). If you want to evaluate lossy compression, this is a well-known method. The method you describe - without the gray screen - is close to the AIC-2 test protocol for "visually lossless image coding", a method we use here for the testing of JPEG XS. In the end, it depends what you want. For JPEG, I believe it is fair to just see the compressed image as you will not have the reference available in the typical use case anyhow. JPEG XS - which is a transmission protocol - the story is a bit different because it has to compete against a direct (uncompressed) IP link.

  31. #29
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by thorfdbg View Post
    Yes, of course. If you just switch back and forth, you also make use of the temporal channel of the HVS which can amplify defects (to the better or worse) and makes them more detectable. That's a different test than what we did at ICIP which was absolute category ranking, i.e. only the distorted images were shown, but with a hidden reference (i.e. the test set to be ranked had both compressed and uncompressed images, but in an unpredictable order). If you want to evaluate lossy compression, this is a well-known method. The method you describe - without the gray screen - is close to the AIC-2 test protocol for "visually lossless image coding", a method we use here for the testing of JPEG XS. In the end, it depends what you want. For JPEG, I believe it is fair to just see the compressed image as you will not have the reference available in the typical use case anyhow. JPEG XS - which is a transmission protocol - the story is a bit different because it has to compete against a direct (uncompressed) IP link.
    I agree with you that switching in-place without gray amplifies some effects when compared to having no gray in between. I think the small shifts in low frequency color are easier to see this way, but some (including the jpeg ringing artefacts) become more difficult to see, especially if the switching is fast (around 1.5 Hz).

    What kind of timings do you use in AIC-2 test protocol?

  32. #30
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    What kind of timings do you use in AIC-2 test protocol?
    IIRC, switching is somewhere at the peak level of the temporal channel sensitivity, which was around 5Hz? The observation time is limited to 4s per image because experiments showed that not much advantage can be gained by allowing observers to watch longer. However, images are shown multiple times in a subjective test run, so observers have more than one chance to detect defects. I would need to check the specs about the precise numbers.

Page 1 of 2 12 LastLast

Similar Threads

  1. JPEG XT Demo software available on jpeg.org
    By thorfdbg in forum Data Compression
    Replies: 40
    Last Post: 16th September 2015, 15:30
  2. Replies: 9
    Last Post: 11th June 2015, 23:28
  3. JPEG Compression
    By elty in forum Data Compression
    Replies: 2
    Last Post: 18th February 2015, 17:04
  4. Replies: 0
    Last Post: 6th February 2015, 06:57
  5. JPEG Metadata
    By lorents17 in forum Data Compression
    Replies: 13
    Last Post: 27th April 2014, 21:29

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •