Faster Jpeg Huffman Scan Decoding

[JimBobSquarePants]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

Description

With #571 now included in the codebase we have an opportunity to further enhance the performance of our jpeg decoder.

There is one obvious candidate for improvement within the decoder: The decoding of the SOS (Start of Scan) segment.

Our approach works but is naïve. We only read/decode one byte at a time and do not use optimized tables for Huffman code lookup. There are further optimizations available with AC Huffman decoding that we also do not do.

I believe that with the correct implementation we can reduce our decoding time by at least 10ms when compared to our current benchmarks.

Inspiration for better code

• MozJpeg - (LibJpeg-Turbo port)
• StbImage - (https://github.com/nothings/stb/blob/e6afb9cbae4064da8c3e69af3ff5c4629579c1d2/stb_image.h#L1680)
• Rust Jpeg Decoder

I'm looking for help here. I've made several attempts to port from both sources but have failed miserably so far.

Update

@bitbank2 Has kindly written some information with pointers to demonstrate how to optimise entropy decoding.

http://bitbanksoftware.blogspot.com/2018/06/optimizing-jpeg-entropy-decoding.html

[hypeartist]

@JimBobSquarePants As of StbImage, take a look at this:
StbSharp
May be it could be of help.

[JimBobSquarePants]

@hypeartist Very useful indeed! I've got something I can debug against now. Thanks!

[JimBobSquarePants]

I had another look at StbImage and managed to decode our Calliphora jpeg. It's a lot faster but there's inaccuracy in the spectral output compared to our current implementation. I think it might be better to try to improve our existing decoder instead of attempting a new port.

[hypeartist]

@JimBobSquarePants I could give a try and port mozjpeg to C# if you like. What do you think?

[JimBobSquarePants]

If you could pull the off I would be blown away! Have a look at our code, it should just be the huffman decoder you need to port.

[hypeartist]

@JimBobSquarePants It's much easier to me to port the whole stuff so you can strip off unneeded bits. :)

[JimBobSquarePants]

It’s totally up to you but we’ve already got all the marker parsing code in place plus we have SIMD optimized IDCT and colorspace conversion code.

As far as I understand the Mozjpeg source it’s only two jdhuff files to port

[hypeartist]

@JimBobSquarePants Ok. I got you. Already grabbed the source and started to examine. Will write you back asap.

[JimBobSquarePants]

Brilliant thanks!

[antonfirsov]

@JimBobSquarePants isn't "Faster Jpeg Huffman Decoding" a better title for this?

Gonna post some up-to-date profiler results tonight, but TryDecodeHuffman() and TryReadBit() are our major Jpeg Decoder bottlenecks as far as I remember.

@hypeartist in my opinion the fastest way to look for improvement opportunities is doing a comparative debug/analysis against other decoders. Doing a full port is very time consuming + having something fast in languages like C, C++, go, rust etc. doesn't guarantee the same code will be fast in C#. (We've been there several times!)
If you can figure out something, please let us know! Any help is appreciated.

[JimBobSquarePants]

@antonfirsov Perhaps, yeah... Naming is hard, it's the Scan segment we're decoding but it's Huffman encoded.

Those two sections will definitely be slowing us down.

• TryReadBit() We should be working with a 4-byte buffer that gets cleared out when we hit a restart marker.

• TryDecodeHuffman should be using a LUT for most of the returned results. Something like 95% of the code values should hit that LUT.

There's established practises that we should definitely be trying to adapt from MozJpeg, I just haven't managed to get it working with restart markers.