Page 1 of 4 123 ... LastLast
Results 1 to 30 of 95

Thread: Psychovisual analysis on modern lossy image codecs

  1. #1
    Member
    Join Date
    Aug 2017
    Location
    Mauritius
    Posts
    59
    Thanks
    67
    Thanked 22 Times in 16 Posts

    Lightbulb Psychovisual analysis on modern lossy image codecs

    I have performed an study on image compression concentrating on lossy formats taking into account the psychovisual differences between original and compressed image.I would like to extend my gratitude to members for their valuable feedback in a previous thread.

    For the study i have used butteraugli and ssimulacra to perform the psychovisual analysis.

    Note :

    Compression Rate(%) - Difference in % between the compression image and the original test image

    Reference Compression Rate(%) - Difference in % between the compression image and a reference jpeg(i.e libjpeg encoded image of original image @ quality = 93).

    Test images used in the image were from Jyrki Alakuijala image corpus : https://goo.gl/cmHIkl

    The attachments include the data in csv files + plots + a bash script to automate the test.

    Awaiting your feedback...

    Kind Regards,
    Khavish
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	bench.png-butteraugli-plot.png 
Views:	555 
Size:	18.7 KB 
ID:	5155   Click image for larger version. 

Name:	bench.png-ssimulacra-plot.png 
Views:	365 
Size:	18.3 KB 
ID:	5156   Click image for larger version. 

Name:	red-room.png-butteraugli-plot.png 
Views:	352 
Size:	18.8 KB 
ID:	5157   Click image for larger version. 

Name:	red-room.png-ssimulacra-plot.png 
Views:	324 
Size:	20.0 KB 
ID:	5158  
    Attached Files Attached Files

  2. Thanks (2):

    Jyrki Alakuijala (25th August 2017),load (26th August 2017)

  3. #2
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Beautiful graphs!! That's a very nice way to show the differences.

    Hacker news discussion:

    https://news.ycombinator.com/item?id=15100946

    Just some more context to make the graphs easier to understand: both butteraugli and ssimulacra are error metrics. A score of 0.0 means no error, and a higher score is of worse quality. Butteraugli specifies 1.0 level as psychovisually good quality. Ssimulacra doesn't specify such an absolute level.

    In rough terms: the closer a graph is to origin, the better the codec. Or the smaller the file size at butteraugli score 1.0, the better the codec.
    Last edited by Jyrki Alakuijala; 25th August 2017 at 23:18.

  4. Thanks:

    khavish (26th August 2017)

  5. #3
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,977
    Thanks
    296
    Thanked 1,304 Times in 740 Posts
    Uh, let's not use weird results for jpeg? (like embedded thumbnails and other metainfo)
    Code:
    [q 95]
    691,120 bench.png
    909,018 bench.tga   // convert.exe bench.png bench.tga (cjpeg can't parse .bmp produced by imagemagick)
    276,998 // libjpeg-bench.png.csv 
    209,517 bench.jpg   // cjpeg -targa -optimize -quality 95 -outfile -progressive bench-p.jpg bench.tga
    197,162 bench-p.jpg // cjpeg -targa -optimize -quality 95 -progressive -outfile bench-p.jpg bench.tga
    179,734 bench.pjg
    179,906 bench-p.pjg
    174,999 bench.jpg.paq8px
    
    [q 99]
    475,758 // libjpeg-bench.png.csv 
    315,775 bench.jpg   // cjpeg -targa -optimize -quality 99 -outfile -progressive bench-p.jpg bench.tga
    310,153 bench-p.jpg // cjpeg -targa -optimize -quality 99 -progressive -outfile bench-p.jpg bench.tga
    289,103 bench.pjg
    289,331 bench-p.pjg
    277,704 bench.jpg.paq8px

  6. Thanks (2):

    Jyrki Alakuijala (26th August 2017),khavish (26th August 2017)

  7. #4
    Member
    Join Date
    Aug 2017
    Location
    Mauritius
    Posts
    59
    Thanks
    67
    Thanked 22 Times in 16 Posts
    Thanks for your insightful comment Shelwien.I believe i need to clarify some choices that i made during the study.
    For JPEG i choose not to use chroma-subsampling as it degrades the quality of images further.

    cjpeg
    CAUTION: For this setting to be useful, be sure to pass an argument of -sample 1x1 to cjpeg to disable chrominance subsampling. Otherwise, the default subsampling level (2x2, AKA "4:2:0") will be used.
    Progressive JPEGs are slow to decode and it would be unfair to compare it with other libraries that don't support it.

    From Guetzli Paper

    Although progressive JPEGs are 2-5% smaller,they are 17-200% slower to decode .

    I hope that the results not now not as weird as you would think

    Regards

  8. #5
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,977
    Thanks
    296
    Thanked 1,304 Times in 740 Posts
    1. In your plots (especially ssim) jpegs have higher quality than pik. I think it makes sense to test more options with smaller size there.

    2. Progressive jpegs are only slow comparing to default jpeg. 2x slower decoding is not actually that bad comparing to some other codecs.
    They are also smaller in size, so we can treat it like a different compression level, rather than mode for displaying partially downloaded images.
    Note that "progressive" is just one specific scan script - its not like I'm suggesting to optimize the scan script for each image.

    3. As to unfair, I think that we shouldn't push for a new incompatible lossy formats, unless they're actually much smaller at the same perceptible quality.
    This means squeezing maximum possible out of jpegs, including lossless recompression.
    Speed is a technical problem, while replacing all the software that exists for jpegs is not.

  9. Thanks (2):

    Jyrki Alakuijala (26th August 2017),khavish (26th August 2017)

  10. #6
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    There are many things you can still play with, and I would also present the results in a somewhat more standard form. First, concerning JPEG: Get a more complete JPEG codec from here: https://github.com/thorfdbg/libjpeg There are many different quantization matrices to select from you can play with (the -qt option does this) and many encoder tricks you can play with (just read the readme, or ask here), iincluding a "dynamic programming" approach to improve R/D curves. JPEG 2000, jpeg xr? Are these missing from the study? You'll find links to example and reference implementations on www.jpeg.org. Same as JPEG, JPEG 2000 offers a variety of tricks to play with to improve performance, including visual optimizations. Check for "visual weighting" in the software you'll find there. Presentation: It is customary to plot "visual quality" (however this is defined) over "bits per pixel" (not absolute size).

  11. #7
    Member
    Join Date
    Feb 2016
    Location
    Luxembourg
    Posts
    546
    Thanks
    203
    Thanked 796 Times in 322 Posts
    Well, let's make this as unbiased as possible. To my understanding, the best possible score for JPEG when using butteraugli as a metric is to create them with guetzli, so in the paq8px thread you'll find a new version of paq8px that can compress those JPEGs.

    Code:
    [q 95]
    177,956 bench.jpg //guetzli --quality 95 --nomemlimit bench.png
    155,112 bench.jpg.paq8px
    
    267,268 red-room.jpg //guetzli --quality 95 --nomemlimit red-room.png
    226.383 red-room.jpg.paq8px

  12. #8
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    325
    Thanks
    18
    Thanked 6 Times in 5 Posts
    This has always concerned me:
    https://github.com/google/guetzli/is...ment-276295265

    "Guetzli is the worst on SSIM and PSNR, but best on butteraugli scoring. This is really not a miracle nor a proof of its superiority since guetzli is just a complex optimizer for butteraugli rating.
    Note, that butteraugli only looks at the worst area of the image, where as ssim and psnr aggregate errors from everywhere in the image."

    Does Pix do the same thing and optimise for butteraugli?

    Personally i always found the output of Guetzli to be less visually pleasing to my eye :/ And when you zoom in to an image optimised for butteraugli you can see many changes to improve the score instead of trying to accurately reproduce the source image. Now the tests i did on this were earlier on this year and i know butteraugli was updated recently so maybe some of these displeasing(to me) operations performed on an image before compression are improved.

    thorfdbg made a good post on it: https://encode.su/threads/2738-jpegr...ll=1#post52583

  13. #9
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Quote Originally Posted by mpais View Post
    Well, let's make this as unbiased as possible. To my understanding, the best possible score for JPEG when using butteraugli as a metric is to create them with guetzli, so in the paq8px thread you'll find a new version of paq8px that can compress those JPEGs.

    Code:
    [q 95]
    177,956 bench.jpg //guetzli --quality 95 --nomemlimit bench.png
    155,112 bench.jpg.paq8px
    
    267,268 red-room.jpg //guetzli --quality 95 --nomemlimit red-room.png
    226.383 red-room.jpg.paq8px
    Opensourced guetzli uses an older version of butteraugli, so there will be some disagreement if one uses the latest butteraugli for measuring the errors. If we would use the same version of butteraugli on guetzli and the tests, we would see this kind of byte counts at 1.0 butteraugli score.

    Looing at PIK graphs the respective sizes are around 110 kB and 150 kB at butteraugli score 1.0 -- and this is without paq8px. PIK is designed as a practical format that decodes very fast, faster than progressive JPEGs and only slightly slower than sequential JPEGs.

  14. #10
    Member
    Join Date
    Aug 2017
    Location
    Mauritius
    Posts
    59
    Thanks
    67
    Thanked 22 Times in 16 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Opensourced guetzli uses an older version of butteraugli, so there will be some disagreement if one uses the latest butteraugli for measuring the errors. If we would use the same version of butteraugli on guetzli and the tests, we would see this kind of byte counts at 1.0 butteraugli score.

    Looing at PIK graphs the respective sizes are around 110 kB and 150 kB at butteraugli score 1.0 -- and this is without paq8px. PIK is designed as a practical format that decodes very fast, faster than progressive JPEGs and only slightly slower than sequential JPEGs.
    Yup i used latest butteraugli to perform the tests

  15. #11
    Member
    Join Date
    Feb 2016
    Location
    Luxembourg
    Posts
    546
    Thanks
    203
    Thanked 796 Times in 322 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Opensourced guetzli uses an older version of butteraugli, so there will be some disagreement if one uses the latest butteraugli for measuring the errors. If we would use the same version of butteraugli on guetzli and the tests, we would see this kind of byte counts at 1.0 butteraugli score.
    At q95, the butteraugli scores listed are 1.4 and 1.6, but if you're saying we could get guetzli to produce JPEGs of around the same size but near a 1.0 score, wouldn't that make PIK's results much less impressive (from a compression ratio perspective, ignoring decoding speed)?

    The files I got from guetzli have identical filesizes to the ones listed in the results, so I'm guessing I used the same version. Wouldn't that imply that these results are useless, if guetzli can do much better on the butteraugli metric?

    Quote Originally Posted by Jyrki Alakuijala View Post
    Looing at PIK graphs the respective sizes are around 110 kB and 150 kB at butteraugli score 1.0 -- and this is without paq8px. PIK is designed as a practical format that decodes very fast, faster than progressive JPEGs and only slightly slower than sequential JPEGs.
    PIK is quite interesting, don't get me wrong, I'm all for improving practical image compression. I'm just not so sure about the butteraugli metric. Looking at the graphs, what I see is an unstable metric.
    Apart from PIK, most other formats have score degradations at higher bits-per-pixel, which make no sense, especially at such high qualities, and aren't present in ssimulacra.

  16. #12
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Quote Originally Posted by Shelwien View Post
    1. In your plots (especially ssim) jpegs have higher quality than pik. I think it makes sense to test more options with smaller size there.
    I never saw a difference in a flip test between images that have butteraugli scores of 0.5 or lower. Both jpeg and pik exceed to that area. Please show an actual image where there is observable degradation. Ssimulacra doesn't model the masking of high frequency blue signal by yellow/white environments and this is one thing that pik and guetzli use extensively for savings, but it fully upsets ssimulacra.

    Quote Originally Posted by Shelwien View Post
    2. Progressive jpegs are only slow comparing to default jpeg. 2x slower decoding is not actually that bad comparing to some other codecs.
    They are also smaller in size, so we can treat it like a different compression level, rather than mode for displaying partially downloaded images.
    Note that "progressive" is just one specific scan script - its not like I'm suggesting to optimize the scan script for each image.
    Progressive jpegs are slower than PIK in decoding.

    Quote Originally Posted by Shelwien View Post
    3. As to unfair, I think that we shouldn't push for a new incompatible lossy formats, unless they're actually much smaller at the same perceptible quality.
    This means squeezing maximum possible out of jpegs, including lossless recompression.
    Speed is a technical problem, while replacing all the software that exists for jpegs is not.
    Yeah, we should be pushing the best option. Now the some organizations are trying to converge around HEIF which is not the best option, and will possibly cause humanity to pay unknown amounts (possibly tens of billions per year) for the IP holders. I wouldn't want to see the MP3 licensing situation again.

    My understanding is that PIK is about 20 % of the bytesize of BPG at the same psychovisual maximum error, and about 35 % of the sequential JPEG. If you throw everything possible at JPEG (guetzli, paq8px) you get a format that is 50 % more bytes than PIK and decodes 30x ? slower.

  17. Thanks:

    khavish (26th August 2017)

  18. #13
    Member
    Join Date
    Nov 2011
    Location
    france
    Posts
    72
    Thanks
    8
    Thanked 39 Times in 29 Posts
    Hi,

    Quote Originally Posted by khavish View Post
    For the study i have used butteraugli and ssimulacra to perform the psychovisual analysis.
    a baseline with 'classic' MS-SSIM would have been helpful.

    Quote Originally Posted by khavish View Post

    Test images used in the image were from Jyrki Alakuijala image corpus : https://goo.gl/cmHIkl
    Am i the only one worried by the fact that this corpus has a lot of uncommon frequency aliasing? e.g:

    Click image for larger version. 

Name:	station.png 
Views:	163 
Size:	73.9 KB 
ID:	5164
    Last edited by skal; 26th August 2017 at 11:30. Reason: missing /

  19. #14
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Quote Originally Posted by mpais View Post
    At q95, the butteraugli scores listed are 1.4 and 1.6, but if you're saying we could get guetzli to produce JPEGs of around the same size but near a 1.0 score, wouldn't that make PIK's results much less impressive (from a compression ratio perspective, ignoring decoding speed)?
    Yes, these 1.4 and 1.6 constitute a difference between the old and the new butteraugli. Most likely it is the improvements in ridge detection, i.e., guetzli removes an very slight ridge somewhere in the image and new butteraugli is upset.

    Also, the new butteraugli is more sensitive in keeping the noise levels the same.

    Seems like it is about time to start upgrading the butteraugli within guetzli...

    Quote Originally Posted by mpais View Post
    The files I got from guetzli have identical filesizes to the ones listed in the results, so I'm guessing I used the same version. Wouldn't that imply that these results are useless, if guetzli can do much better on the butteraugli metric?
    Guetzli using the latest butteraugli is always worse than PIK. PIK is heavily based on the ideas of guetzli, recompression, and making the format more compatible with the concepts of butteraugli so that simple quantization would give more guetzli-like savings.

    Quote Originally Posted by mpais View Post
    PIK is quite interesting, don't get me wrong, I'm all for improving practical image compression. I'm just not so sure about the butteraugli metric. Looking at the graphs, what I see is an unstable metric.
    Apart from PIK, most other formats have score degradations at higher bits-per-pixel, which make no sense, especially at such high qualities, and aren't present in ssimulacra.
    True, butteraugli is more unstable than others -- as it only looks at maximum degradation in the image. The maximum degradation is by definition less stable than the average. However, the next best (for high quality image compression artefacts) opensourced metric, ssimulacra, even thinks that guetzli images are worse than libjpeg images. This we proved to be the opposite in our arxiv paper https://arxiv.org/abs/1703.04416

    The maximum metric is still a pretty good idea: it stops the encoder fallacy of "Hey, I got that large blue wall perfectly correct, now I can make a lot of errors in the small facial detail in the middle to save some bytes."

  20. Thanks (3):

    khavish (26th August 2017),mpais (26th August 2017),SerGen (1st September 2017)

  21. #15
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Quote Originally Posted by skal View Post
    a baseline with 'classic' MS-SSIM would have been helpful.
    ssimulacra contains a very high quality implementation of MS-SSIM and additional metrics that are necessary to get decent results on images constructed from blocked transforms, and DSSIM is a living proof that there are day-and-night kind of differences between MS-SSIM implementations (at least based TID2013 scoring results)

    Using a vanilla MS-SSIM (or a homebrewed variation) will be necessarily worse than Ssimulacra (at least in the TID2013 benchmark sense).

    Quote Originally Posted by skal View Post
    Am i the only one worried by the fact that this corpus has a lot of uncommon frequency aliasing? e.g:
    Yes, the two photos chosen are heavy on red, and particularly BPG seems to be failing on red. Perhaps you have a good high quality test photo from the WebP lossy tests so that Khavish can run his comparison on more images?

    I don't see aliasing on that image, but I do see a lot of detail, much more than is typical for photos.

    But it is true that I tried to add such photos in the corpus that produce difficulties on modern image codecs. Also, I wasn't particularly interested on how well the codec stores or emulates a noise pattern, so that is why the images are relatively heavy on details and low on noise.

  22. Thanks:

    khavish (26th August 2017)

  23. #16
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Intrinsic View Post
    Personally i always found the output of Guetzli to be less visually pleasing to my eye :/ And when you zoom in to an image optimised for butteraugli you can see many changes to improve the score instead of trying to accurately reproduce the source image.
    This, however, does not surprise me. Any visual improvement needs to take the CSF into account, and this is of course dependent on the distance of the observer - or similarly, on the size of the pixels. If you zoom in, you ruin the physiological model the optimization is based on, so it will certainly look worse.

    It would now be interesting to know for which viewing distance Guetzli has been optimized.

  24. Thanks:

    Jyrki Alakuijala (27th August 2017)

  25. #17
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    [QUOTE=Intrinsic;53947]This has always concerned me:
    https://github.com/google/guetzli/is...ment-276295265

    Quote Originally Posted by Intrinsic View Post
    "Guetzli is the worst on SSIM and PSNR, but best on butteraugli scoring. This is really not a miracle nor a proof of its superiority since guetzli is just a complex optimizer for butteraugli rating.
    Note, that butteraugli only looks at the worst area of the image, where as ssim and psnr aggregate errors from everywhere in the image."
    One of the most basic reasons for this is visualized in the guetzli arxiv paper: https://arxiv.org/pdf/1703.04421.pdf in Figure 5.

    Figure 5 demonstrates a non-linearity of the human visual system that is not accounted by sRGB colorspace, and a linear transform in these spaces (such as RGB->YUV or RGB->YUV420) cannot model this non-linearity, since the effect is modulated by a simple superposition in axes that are separated for the existing nonlinearity (gamma) -- it shouldn't have any affect by such color models. However, Figure 2 shows that the data from Figure 5 cannot be observed as thought by common color models. The color spaces are relatively complicated concepts so people usually fail to reason about such non-linearities as they progress through the colorspace transforms.

    The plausibility of the butteraugli being more correct than other metrics is demonstrated in another paper: https://arxiv.org/pdf/1703.04416.pdf ... In that paper, no butteraugli/ssim etc. were used -- just humans stared at the images, and at the same file size and near lossless quality (guetzli quality 94), humans liked guetzli's results more at 75 % rate. At such high qualities, both images (guetzli and libjpeg) look awesome, and it is generally difficult to figure out differencies, so a 75 % rate can be considered significant.

    Quote Originally Posted by Intrinsic View Post
    Does Pix do the same thing and optimise for butteraugli?
    PIK has two modes, fast mode that doesn't optimize for butteraugli, and a slow mode that iterates like guetzli and is using butteraugli.

    Quote Originally Posted by Intrinsic View Post
    Personally i always found the output of Guetzli to be less visually pleasing to my eye :/
    This is very interesting and potentially very useful, too. Would you help us -- could we borrow your eyes for some simple tests?

    Quote Originally Posted by Intrinsic View Post
    And when you zoom in to an image optimised for butteraugli you can see many changes to improve the score instead of trying to accurately reproduce the source image. Now the tests i did on this were earlier on this year and i know butteraugli was updated recently so maybe some of these displeasing(to me) operations performed on an image before compression are improved.
    Guetzli has been designed and evaluated to be used at quality setting 93-96. If you use it at quality 84 -- the lowest it allows, it can perform worse than another codec.

    Guetzli drives every area of the image down to the specified quality even if the bit savings are not significant there. Because of this, when you move down from good quality, your image becomes bad everywhere, even in simple low-entropy areas -- whereas with other codecs, it only gets spoiled somewhere. This is probably not a good design decision in guetzli, just a description of the current state of affairs.

  26. #18
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    The plausibility of the butteraugli being more correct than other metrics is demonstrated in another paper: https://arxiv.org/pdf/1703.04416.pdf ... In that paper, no butteraugli/ssim etc. were used -- just humans stared at the images, and at the same file size and near lossless quality (guetzli quality 94), humans liked guetzli's results more at 75 % rate. At such high qualities, both images (guetzli and libjpeg) look awesome, and it is generally difficult to figure out differencies, so a 75 % rate can be considered significant.
    For this paper, do you have any more detailed statistical analysis to offer? In particular, did you have the chance to evaluate in how far differences are statistically significant?

    This being said, it would have been great to have you at ICIP 2016.

  27. #19
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Guetzli, Butteraugli and PIK are optimized to be viewed roughly 900 pixels away. We deliberately have relatively large pixels (== close viewing distance) so that the psychovisual model is more resistant to zooming.

  28. #20
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Quote Originally Posted by thorfdbg View Post
    For this paper, do you have any more detailed statistical analysis to offer? In particular, did you have the chance to evaluate in how far differences are statistically significant?
    Which hypothesis would you like to have tested?

    There were 614 ranking events, and 75 % of them were pointing guetzli as the better of the two. All the 23 participants found guetzli better than libjpeg. We list all the measurement results in the arxiv paper.

    I think much more hanky-panky can be in the selection of corpus and the test setup than in the statistical interpretation of these results. There, we chose to measure 2.6 bits/pixels, and our corpus is less noisy/grainy than some images and more dense with details. If we had used images that were jpegs originally, or had very high image sensor noise levels, or strange reconstruction artefacts, we might have had different results.

    Quote Originally Posted by thorfdbg View Post
    This being said, it would have been great to have you at ICIP 2016.
    Thank you for the kind words!! We were really in an early stage with our work back then

  29. #21
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Khavish, could you choose pictures from another corpus, too. For example from https://github.com/WyohKnott/image-f...omparisonfiles -- and run your scripts on them?

  30. #22
    Member
    Join Date
    Aug 2017
    Location
    Mauritius
    Posts
    59
    Thanks
    67
    Thanked 22 Times in 16 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Khavish, could you choose pictures from another corpus, too. For example from https://github.com/WyohKnott/image-f...omparisonfiles -- and run your scripts on them?
    Okay....i will rerun the script on these two images and then post the results

    https://github.com/WyohKnott/image-f...1670u_edit.png
    https://github.com/WyohKnott/image-f...lAmsterdam.png

  31. #23
    Member
    Join Date
    Aug 2017
    Location
    Mauritius
    Posts
    59
    Thanks
    67
    Thanked 22 Times in 16 Posts
    well i am done for GrimburgwalAmsterdam.png

    MozJPEG v3.2 has been added as new codecs.Note: No sub-sampling has been used so as not to affect the quality of the image
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	GrimburgwalAmsterdam.png_butteraugli_plot.png 
Views:	192 
Size:	20.2 KB 
ID:	5168   Click image for larger version. 

Name:	GrimburgwalAmsterdam.png_ssimulacra_plot.png 
Views:	166 
Size:	21.5 KB 
ID:	5169  

  32. #24
    Member
    Join Date
    Jul 2016
    Location
    Russia
    Posts
    26
    Thanks
    15
    Thanked 10 Times in 7 Posts
    Pls add "libjpeg + lepton" (or packjpg) and heif (new image format will be supported iOS11)

  33. #25
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    Quote Originally Posted by zubzer0 View Post
    Pls add "libjpeg + lepton" (or packjpg)
    I consider lepton and packjpg as unpractical codecs due to their slow decoding speed. Single-threaded lepton decompresses about 2.5 MB/s (compressed data). With a 1:10 compression, it is 25 MB/s uncompressed. That is about 10x slower than the image codecs that are already in the chart. Packjpg is likely 4x? slower than lepton, i.e, even more unpractical for this use case.

    Furthermore, I don't consider the curves from lepton and packjpg very exciting -- lepton and packjpg can be approximated as a libjpeg with 24 % less bytes, or guetzli with 14 % less bytes (guetzli-produced jpegs are less homogenous and re-compress slightly worse). If you look at the curves, a 24 % improvement is not going to make a big difference.

    I'd like to see HEIF and AV1 curves however. Don't know much about HEIF, perhaps it is the same as ffmpeg's x265? AV1 may be tricky to produce since AV1 traditionally doesn't support image formats (like PNG) and the 444 mode may need additional tuning. Probably somewhere within https://github.com/WyohKnott/image-formats-comparison/ there is a solution to that problem...
    Last edited by Jyrki Alakuijala; 28th August 2017 at 21:37.

  34. #26
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    I consider lepton and packjpg as unpractical codecs due to their slow decoding speed. Single-threaded lepton decompresses about 2.5 MB/s (compressed data). With a 1:10 compression, it is 25 MB/s uncompressed. That is about 10x slower than the image codecs that are already in the chart. Packjpg is likely 4x? slower than lepton, i.e, even more unpractical for this use case.
    I don't recall the figures, but if speed concerns you, I would believe that HEVC is in this respect also quite "unpractical". (-;
    Quote Originally Posted by Jyrki Alakuijala View Post
    I'd like to see HEIF and AV1 curves however. Don't know much about HEIF, perhaps it is the same as ffmpeg's x265?
    HEIF is just a file format wrapper around H.265 aka HEVC. So there is no difference in performance whatsoever. HEIF adds a couple of features you also find in the JPEG 2000 file format (compositing, fragmenting, color spaces...)

  35. #27
    Member
    Join Date
    Aug 2017
    Location
    Mauritius
    Posts
    59
    Thanks
    67
    Thanked 22 Times in 16 Posts
    Results for Mural_in_Northeast_Pavillion__Thomas_Jefferson_Bui lding_by_Elmer_E._Garnsey_11670u_edit.png have been added in attachments
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	mural.png_butteraugli_plot.png 
Views:	172 
Size:	20.8 KB 
ID:	5170   Click image for larger version. 

Name:	mural.png_ssimulacra_plot.png 
Views:	163 
Size:	21.3 KB 
ID:	5171  

  36. #28
    Member
    Join Date
    Oct 2015
    Location
    Belgium
    Posts
    41
    Thanks
    10
    Thanked 30 Times in 15 Posts
    FLIF results are incorrect, you are showing the size of the decompressed PNG, not the FLIF files
    Not that FLIF performs that well as a lossy codec (it's a lossless format after all), but it should do significantly better than what those graphs show
    Also note that the FLIF command line tool accepts qualities below 0 (you can go as far negative as you want); I made it so that the 'useful' range is in 0..100, but if you really want to get small files with lots of artifacts, you can try e.g. -Q-1000 and see what happens

    Other remarks: It's a bit unfair to disable chroma subsampling for JPEG and BPG, while WebP forces it (I don't know about Pik and Guetzli). Why not show curves for both 4:4:4 and 4:2:0? Also BPG will perform better with the jctvc encoder and with the default colorspace transform.

  37. Thanks (3):

    Jyrki Alakuijala (29th August 2017),khavish (29th August 2017),Mike (29th August 2017)

  38. #29
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    876
    Thanks
    242
    Thanked 325 Times in 198 Posts
    That's a good finding about decompressed sizes and explains a lot! Looking forward to better curves. Pik doesn't have 420, and guetzli uses it very rarely (1 % of cases). 420 with DCT makes the ringing (on chromacity planes) proceed twice as far as with 444. Also, under certain conditions (like red-green boundary, or an image that has mostly blue component activation in it) 420 cannot replicate the image faithfully and significant errors are introduced.
    Last edited by Jyrki Alakuijala; 29th August 2017 at 14:31.

  39. #30
    Member
    Join Date
    Aug 2017
    Location
    Mauritius
    Posts
    59
    Thanks
    67
    Thanked 22 Times in 16 Posts
    Quote Originally Posted by Jon Sneyers View Post
    FLIF results are incorrect, you are showing the size of the decompressed PNG, not the FLIF files
    Not that FLIF performs that well as a lossy codec (it's a lossless format after all), but it should do significantly better than what those graphs show
    Also note that the FLIF command line tool accepts qualities below 0 (you can go as far negative as you want); I made it so that the 'useful' range is in 0..100, but if you really want to get small files with lots of artifacts, you can try e.g. -Q-1000 and see what happens

    Other remarks: It's a bit unfair to disable chroma subsampling for JPEG and BPG, while WebP forces it (I don't know about Pik and Guetzli). Why not show curves for both 4:4:4 and 4:2:0? Also BPG will perform better with the jctvc encoder and with the default colorspace transform.
    My sincere and deepest apologies Jon.As you correctly pointed out i was showing the size of PNG files instead of flif. This was due to a very embarrassing typo on my part and kudos for taking such a mistake with good humor.

    Guys kindly ignore flif results on the graphs, i will rerun the tests and publish an updated bash script soon.

  40. Thanks (4):

    Jon Sneyers (29th August 2017),Jyrki Alakuijala (29th August 2017),Mike (29th August 2017),schnaader (1st September 2017)

Page 1 of 4 123 ... LastLast

Similar Threads

  1. WebP (lossy image compression)
    By Arkanosis in forum Data Compression
    Replies: 62
    Last Post: 12th April 2019, 18:45
  2. Psychovisual measurements on modern image codecs
    By khavish in forum Data Compression
    Replies: 28
    Last Post: 28th August 2017, 02:41
  3. DLI ? Other top level lossy image compressors?
    By cbloom in forum Data Compression
    Replies: 49
    Last Post: 11th September 2014, 10:07
  4. Lossy image compression article
    By nburns in forum Data Compression
    Replies: 1
    Last Post: 20th October 2013, 19:20
  5. Modern BWT speed
    By GerryB in forum Data Compression
    Replies: 4
    Last Post: 5th May 2009, 17:28

Posting Permissions

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