Lovely topic about JPEG algorithms
From JPEG Group we have:
1. JPEG (JPG/JPEG) or ITU T.81 standard that specifies LOSSLESS compression.
But JPEG LOSSLESS compression it's not so good compared to the other "state-of-art" compression algorithms.
2. JPEG-LS (JLS) or ITU T.87 standard with somewhat very good compression level (8-bit to 20~30% of original) vs CPU computation power.
Where JPEG-LS also support both LOSSLESS and NEAR-LOSSLESS compression (with NEAR factor set to 3 I get very good images with only 1.5% in size of original).
3. JPEG 2000 (J2K) or ITU T.8(00~15), that has awesome compression levels, but is very CPU computation extensive "state-of-art" (not sure what "art" stands for there. They have named it like that, not me).
This time surprise comes from Microsoft:
4. JPEG XR (JXR) or ITU T.8(30-49), very recent and very fast, also good compression levels.
Unfortunately many developers opt to implement only first (as many libraries support JPEG baseline, and not lossless encoding ie: just part of it.
Many do not implement higher bit depths support, or bigger documents support : int instead of short for width and heights and so on.
But so far I have seen that impossible is possible, so very slow algorithms can be improved to work faster.
I've managed to reassemble JPEG-LS encoder/decoder for 16-bit/8-bit grayscale images supporting both LOSSLESS and NEAR-LOSSLESS in pure .NET (well using unsafe and a little of native heap, but all code is actually C# ). And outrun on performances test both, free opensource lib CharLS (C/C++) (beaten by 40%), and payed Leadtools JLS Codec (C/C++ native+managed) (beaten by 70%). So I am guessing someone out there probably has very fast J2K/JXR codec that we need only to discover. Jpeg-Turbo is nice choice, but they tend to loose quality of image for the speed, so if task is best image quality I would avoid JpegTurbo (but is nice start for optimizations).
Recently I have discovered some article on subject of image lossless algorithms, and comparison test results that might interest you all: https://res.mdpi.com/d_attachment/electronics/electronics-09-00360/article_deploy/electronics-09-00360-v2.pdf
JPEG-LS tends to be among fastest with average compression, but surprise MS JXR beats him for 16-bit images in encoding/decoding speed.
Where compression level of both is very similar with 8-bit images, 16-bit images are compresses better by JXR, so JXR wins also this time.
So the table at the end of document states results for different matching between compression ratio, encoding, and decoding times that might be useful to everyone.
JXR is next on my list to try, only to figure out how to implement and measure it's speed.
So if anyone is voting what to implement in paint.net I would suggest both JXR and JLS
