Results 1 to 9 of 9

Thread: Knusperli — a better JPEG decoder

  1. #1
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts

    Knusperli — a better JPEG decoder

    Ruud van Asseldonk —a software engineering intern at Google Research's Zurich-based compression team— has opensourced a new jpeg decoder, Knusperli. It shows a new approach that decodes JPEGs in a way that remains true to the original but creates less block error boundaries.

    The boundary continuity is imposed in DCT space within the quantization boundaries, i.e., the properties of the image are not changed into something that would produce a different DCT quantization results. It doesn't solve all problems of jpeg compression, but would mitigate the artefacts in quality range 50-85 nicely.

    Knusperli builds on our previous work with Guetzli and PIK.

  2. The Following 3 Users Say Thank You to Jyrki Alakuijala For This Useful Post:

    JamesB (9th March 2018),SolidComp (10th March 2018),zubzer0 (9th March 2018)

  3. #2
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Deblocking JPEGs is actually quite an old art, you'll find first algorithms for this even in the standard itself, or at least in the Pink Book. Not saying that this is the best possible approach that is provided there. Now, what would be interesting to see is whether this decoder actually passes the conformance tests. Has this been attempted? Currently, there are two tests for JPEG: JPEG part 2 (10918-2) is the original test, but it is not very critical. What you have to do for it is to decode the test streams (but without upsampling and conversion to RGB, both are not part of JPEG), then take the DCT, quantize them, and compare these coefficients with the original DCT coefficients. The difference shall not be larger than one quantization bucket. Then, we have a newer (and more critical) test in 18477-4 that requires decoding of reference streams and comparison in the spatial domain with reference images. Decoders then have to pass a PSNR bound.

  4. The Following 3 Users Say Thank You to thorfdbg For This Useful Post:

    encode (10th March 2018),Jyrki Alakuijala (9th March 2018),khavish (11th March 2018)

  5. #3
    Member
    Join Date
    Dec 2011
    Location
    Cambridge, UK
    Posts
    437
    Thanks
    137
    Thanked 152 Times in 100 Posts
    If like me you don't have bazel installed (blergh! The world doesn't need more build systems!) then you can build with:

    git clone git@github.com:lvandeve/lodepng.git; # I did this as a subdirectory of knusperli
    g++ -g -O -I lodepng -o knusperli *.cc lodepng/lodepng.cpp

    Although it then failed to decode one of my JPGs sadly (I can provide an example).

    It looks to work well on some others I tried.

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

    Jyrki Alakuijala (9th March 2018)

  7. #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
    Deblocking JPEGs is actually quite an old art
    Thank you for the advice! I believe that this approach is bringing something new, namely the interpolation of the continuity by sums and alternating sums in the DCT space (instead of pixel space). The approach should produce an image that indeed produces the same jpeg coefficients, i.e., is doing well within a generation loss and jpeg tests.

  8. The Following User Says Thank You to Jyrki Alakuijala For This Useful Post:

    khavish (11th March 2018)

  9. #5
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by JamesB View Post
    Although it then failed to decode one of my JPGs sadly (I can provide an example).
    Please file a bug on the respective github repository!

  10. #6
    Member
    Join Date
    Jul 2016
    Location
    Russia
    Posts
    21
    Thanks
    13
    Thanked 7 Times in 6 Posts
    If JPEG to consider in the form of "MozJpeg" + "Lepton" (or PackJPG) + "Knusperli decoder" to grips with negligible loss (50-90), it is very interesting. And maybe even superior to other modern formats.
    But this is a sandwich/crutches. It is interesting to compare this sandwich with "pik" on the same file size

  11. #7
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    222
    Thanks
    89
    Thanked 46 Times in 30 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Ruud van Asseldonk —a software engineering intern at Google Research's Zurich-based compression team— has opensourced a new jpeg decoder, Knusperli. It shows a new approach that decodes JPEGs in a way that remains true to the original but creates less block error boundaries.

    The boundary continuity is imposed in DCT space within the quantization boundaries, i.e., the properties of the image are not changed into something that would produce a different DCT quantization results. It doesn't solve all problems of jpeg compression, but would mitigate the artefacts in quality range 50-85 nicely.

    Knusperli builds on our previous work with Guetzli and PIK.
    Maybe this is implied by what you've said, but I don't know JPEG that well – can Knusperli decode arithmetic-coded JPEGs?

    How is the performance on memory, CPU, MiB/sec, etc? Can it be parallelized or accelerated with OpenMP, OpenCL, or CUDA?

    By the way, did you see Charles' notes on a JPEG2? I've republished them here since his "rants" blog doesn't have distinct URLs for posts.

  12. #8
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by SolidComp View Post
    Maybe this is implied by what you've said, but I don't know JPEG that well – can Knusperli decode arithmetic-coded JPEGs?
    There is no arithmetic coding support.

    Knusperli is an attempt at improving image quality with compatibility. Since current support in browsers is only for prefix-coded JPEGs, that is what knusperli supports.

    Quote Originally Posted by SolidComp View Post
    How is the performance on memory, CPU, MiB/sec, etc? Can it be parallelized or accelerated with OpenMP, OpenCL, or CUDA?
    We didn't measure nor optimize it. Knusperli is currently more at a level of proof-of-concept than something that could actually be deployed as is. By just thinking about how it can be done, I believe a simple software only solution (possibly with SIMD) will be fast enough for practical deployments. In my anticipation a well-optimized implementation of knusperli is possibly 10-25 % slower than a traditional jpeg decoder.

    Quote Originally Posted by SolidComp View Post
    By the way, did you see Charles' notes on a JPEG2? I've republished them here since his "rants" blog doesn't have distinct URLs for posts.
    Thanks for sharing. He has solid arguments on this.

  13. #9
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by zubzer0 View Post
    It is interesting to compare this sandwich with "pik" on the same file size
    Yes indeed! PIK is not using the knusperli approach, at least not yet.

Similar Threads

  1. Replies: 0
    Last Post: 6th February 2015, 06:57
  2. Replies: 1
    Last Post: 17th February 2014, 23:05
  3. Replies: 7
    Last Post: 6th September 2012, 03:23
  4. Code generation in LZ decoder / Branchless LZ77 Decoder
    By Shelwien in forum Data Compression
    Replies: 1
    Last Post: 30th September 2010, 20:48
  5. UNZ - minimal LZW decoder + source
    By encode in forum Forum Archive
    Replies: 7
    Last Post: 29th January 2008, 15:54

Posting Permissions

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