jpegmini.com

[Black_Fox]

JPEGmini is a patent-pending photo recompression technology, which significantly reduces the size of photographs without affecting their perceptual quality. The technology works in the domain of baseline JPEG, resulting in files that are fully compatible with any browser, photo software or device that support the standard JPEG format.

JPEGmini is capable of reducing the file size of standard JPEG photos by up to 80% (5X), while the resulting photos are visually identical to the original photos. The JPEGmini algorithm imitates the perceptual qualities of the human visual system, ensuring that each photo is compressed to the maximum extent possible by removing redundancies, without creating any visual artifacts in the process. This enables fully automatic, maximal compression of photos with no human intervention required.

JPEGmini can be implemented in end-user devices such as cellular phones, cameras, and personal computers, to reduce storage requirements for photos, and reduce the time and bandwidth required for uploading the photos to online services. It can also be implemented in image-centric data centers, to reduce Total Cost of Ownership (TCO), including storage, bandwidth, electricity, and floor space.

http://www.jpegmini.com/main/home
http://www.jpegmini.com/main/technology

[Biozynotiker]

I tried jpegmini.com with some pics and this works well.
But I get a way smaller filesize with RIOT.

[Intrinsic]

The examples i checked are 100%/PS save as qual 12 jpegs with no huffman optimisation or progressive encoding. All they do is reduce the quality level to around 83%, enable huffman optimisation and use some custom quantization tables(which is where they gain their size, just like PS uses custom tables too). They don't even bother to try progressive encoding which 99% of the time on photo images will reduce the size further. They don't even tailor the quant tables to the individual table they all use the same ones, on the examples i checked anyways.

[Black_Fox]

Would you mind posting the quant tables here?

[Black_Fox]

The quantization tables are not the same neither for their own examples downloadable from the web, nor for my test imagery.

[Karhunen]

I mess around with AWK to make such tables, I know that the following works with cjpeg "-qtables" parameter:
BEGIN{print "# ((2*(y==x))+(y%x)+((y<7)*(y*x)*(y<7))+(50*(y>6))+( x*2)+((x%7)*2)+(x%(10-y)))\n# Generates Table 0\n\n# Table 0 ( Y channel )"}
END { for (y=1; y<9; y++) {printf "\n";for(x=1;x<9; x++) printf ((2*(y==x))+(y%x)+((y<7)*(y*x)*(y<7))+(50*(y>6))+( x*2)+((x%7)*2)+(x%(10-y))) OFS};
printf "\n\n# Table 1 (Cr channel)\n\n7 9 18 28 43 63 91 128\n9 8 17 23 33 48 68 94\n18 17 31 34 43 58 78 105\n28 23 34 55 63 77 98 126\n43 33 43 63 98 108 128 157";
printf "\n63 48 58 77 108 154 174 204\n91 68 78 98 128 174 239 255\n128 94 105 126 157 204 255 255\n\n#Table 2 (Cb channel)\n\n14 18 46 71 109 161 232 255";
printf "\n18 17 43 59 85 122 173 240\n46 43 80 87 111 148 200 255\n71 59 87 142 160 196 249 255\n109 85 111 160 251 255 255 255\n161 122 148 196 255 255 255 255";
printf "\n232 173 200 249 255 255 255 255\n255 240 255 255 255 255 255 255\n"
}
I invoke this with GNU gawk in my Win32 box in a command shell by gawk -f file.awk NUL where file.awk contains that text above. Obviously I am just messing around with Y channel, the other coeficients were taken from http://x264dev.multimedia.cx/archives/541#more-541

[Intrinsic]

Hmm tables were the same on the few i saw(just their examples you could download, didn't try any of my own files)

I was thinking they could use tricks with custom scans files, i guess you are referring to jpgcrush Karhunen? i've used it's scans files before but just for testing, it can gain you a few more % but haven't examined it extensively, i think it was in python and i don't know much about python

[Karhunen]

http://x264dev.multimedia.cx/archives/541#more-541[/URL]

Basically, I use GNU AWK ( gawk ) as a command line C language, as Aho,Weiner,Kernigan developed as a filter for shell scripts. Works great on DOS 2.0 -> Win7
Not to mention *NIX. That horrible script I used from the command line generates a Quant table and I can randomly mess with the numbers. The only entropy I understand is thermodynamical

[Sebastian W]

@Biozynotiker
Riot (internaly cjpeg) works better here too. Higher quality at the same size with high quality source images.



There is a windows trial version of JPEGmini with 20 free conversations per day. Nice for testing. http://www.jpegmini.com/windows

To feed it, it's best to convert an image that has never been JPEG-compressed before to JPEG-format with quantization tables full of ones (almost lossless). I use the command line cjpeg.exe -quality 100 in.pnm out.jpg.

JPEGmini keeps the sample factor of the input jpeg files. I tested with 1x1 and 2x2. So the user has to decide about color subsampling.

In my tests, JPEGs compressed with cjpeg, with the same tables that jpegMINI used, are between 1.3% and 3.3% bigger. jpegMINI loses most of the fine details and texture, but also smoothes out a few JPEG compression artefacts here and there.

It generates a quantization table, that changes with the content of the image. But it doesn't change with color-subsampling. It stays the same with 1x1 and 2x2, which is bad idea. An upsampled, lower resolution color channel has to be less compressed than a full color channel. Ether they are wasting space or having too low quality.


Here are two example tables that JPEGmini creates.

Image 1, 1x1 and 2x2:

Luminance
7 5 5 7 11 17 22 26
6 6 6 9 11 25 26 24
6 6 7 11 17 25 30 24
6 8 10 13 22 37 34 27
8 10 16 24 29 47 44 33
11 15 24 28 35 44 48 39
21 28 33 37 44 52 51 43
31 39 41 42 48 43 44 42

Chrominance
8 8 11 20 42 42 42 42
8 9 11 28 42 42 42 42
11 11 24 42 42 42 42 42
20 28 42 42 42 42 42 42
42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42

JPEGsnoop (http://www.impulseadventure.com/photo/) guesses "Apple Quicktime" @ Quality 0501 as the comressor.


Image 2, 1x1 and 2x2:

Luminance
3 3 1 3 5 8 10 12
3 3 3 4 5 11 11 10
3 3 3 5 8 11 13 11
3 4 5 6 10 16 15 12
4 5 7 11 13 20 19 14
5 7 10 12 15 19 21 17
9 12 15 16 19 22 22 19
14 17 18 18 21 19 19 18

Chrominance
4 4 5 9 18 18 18 18
4 4 5 12 18 18 18 18
5 5 11 18 18 18 18 18
9 12 18 18 18 18 18 18
18 18 18 18 18 18 18 18
18 18 18 18 18 18 18 18
18 18 18 18 18 18 18 18
18 18 18 18 18 18 18 18

No JPEGsnoop guess here


My conclusion up to now: JPEGmini kills most of the details and texture of an image. Open source cjpeg with the same tables is sharper with a lot more texture and the files are only about 1% to 3% bigger. If I lower the quality to hit the same filesize as JPEGmini, quality is still better with cjpeg.

The better the quality of the original images, the lower the filesize-advantage of JPEGmini and the bigger the loss of details. My lower quality images are from a good compact camera, my better ones from cheap to medium priced DLSRs. All of them lose a lot of details, independent of their size (1000px to 4000px width). I think, the loss of details should scale with the image size in such an automatic tool.

On the other hand, a low quality image from a mobile phone hardly includes any details worth to preserve. The high frequency image content on these devices is noise mostly. So here JPEGmini might act as an (average quality) noise filter and make files smaller without harming the real image content too much. I have not checked that yet. But the quality of denoising in my pictures is not very good but not too bad also. Specialized image denoisers do a better job to preserve details. So if I need to compress my images very strong, I would denoise them first. Compressability is boosted by this step a lot.

What I like about JPEGmini is its guess quality about the right amount of lossy compression. It looks really good and raises or lowers the loss in the right way in all images I testet yet. In my opinion I can let JPEGmini chose the compression level and then use another tool to compress the image to the filesize that the JPEGmini compressed file would have, plus 10% or more.

My feeling is, that the jpegMINI-guess +10% on the luminance-channel looks good. The chrominance table is fine for me if I disable color subsampling.

A compromise might be to compress an image twice. Once with JPEGmini, once with cjpeg with the same tables. And then merge both JPEGs by taking the cjpeg-version and putting in some blocks from the jpegMINI-version to smooth areas. But who would do this for half a percent smaller files by hand?

Each image I have tested, showed a few blocks with too strong compression artefacts in the cjpeg-version. It would be nice to change only those few blocks with the blocks from the same position from the JPEGmini-version. Changing is easy but finding those blocks might be less easy for a computer program.

[thorfdbg]

I believe I have an older SPIE publication on how jpegmini actually works. It is the usual visual masking & visual weighting game by which the encoder modifies the quantization matrix as long as it can detect that the quantization error is right at the JNB within the model used by it. Frequency weighting works of course nicely in JPEG, masking is a bit harder to reach.

[porneL]

Do you know any open-source JPEGMini-like encoder?

[thorfdbg]

Do you know any open-source JPEGMini-like encoder?

I afraid no. There is the predicessor, dctune, and you find an executable you can try, plus publications that tell you how it works, but I don't remember seeing sources. There is a bit for JPEG 2000 in terms of sources.

[Sebastian W]

I found the source code of a command line tool for finding "optimal" quantization matrix, just like dctune but with more options and different results, in 2012.

Dctune seems to fill the top left of the matrix with low values and the rest with very high values, and a small, steep border between. For me it looks like it tries to preserve lower frequencies, that are very visible at a given viewers distance and resolution, and drops the rest.

Here is an example:

2 2 2 2 4 8 22 255
2 2 2 2 4 6 16 255
2 2 4 6 8 22 255 255
4 2 6 12 34 68 255 255
4 4 6 28 255 255 255 255
8 6 16 78 255 255 255 255
86 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255


14 16 255 255 255 255 255 255
22 118 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255


6 8 22 255 255 255 255 255
8 22 255 255 255 255 255 255
36 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255

You can see that dctune has command line switches for the resolution (pixel per degree of angle or dpi and viewing distance). Btw, dctune allways creates jpegs with 2x2 chroma subsampling. Of cause you can compress a jpeg with the matrix from dctune without subsampling usind cjpeg or other tools.
Edit: Here is a description of dcrtunes approach from 1993: http://vision.arc.nasa.gov/publications/sid93/sid93.pdf

The other tool for finding a custom matrix for an image - I don't remember the name - created a matrix that seemd to fit to the whole image and all details within. For images with high frequency content, it created smaller numbers in the lower right side of the matrix to preserve the fine details.
It was plain C sourcecode. The configuration was done in a command line area within the program itself.

Something like: running "tool.exe" => load image.jpg => process current image => scale processing results for filesize 130kb by iteration => save resulting matrtix to image.txt => exit "tool.exe"

I should be able to find it on an old hard disk.

[Sebastian W]

The tool for finding an optimized, custom matrix, I was writing about, is RDOPT
http://pages.cs.wisc.edu/~ratnakar/rdopt.tar.gz

Here is the paper
http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf

[caveman]

Do you know any open-source JPEGMini-like encoder?

There's the ADEPT JPEG compressor, it compares itself to JPEGmini but from what I've understood it tries to replicate the JPEG2000 ROI (Regions Of Interest) feature by applying two different "quality" settings based on how detailed small tiles (macroblocks, MCU) are, which is odd since JPEG has only one quantization table per YCbCr component, I suppose the same could be done by enforcing more zeroes or smaller values into the high frequency AC components of the DCT matrices when this operation has a negligible impact on visual quality since more zeroes means better compression. ADEPT does not build quantizations tables from scratch since it relies on IJG libjpeg, I have now idea if it handles chroma subsampling at all, it looks like a high level tool rather than a low level one that would directly fiddle the quantizations tables.

https://github.com/technopagan/adept-jpg-compressor

[porneL]

I've tested DCTune 2.0, compared to ImageMagick, and it doesn't seem any better (tried dctune -kbytes with approx sizes of imagemagick results)

1-SSIM      filesize
0.002800    583513  barbara-100
0.033700    233156  barbara-095
0.045300    269827  barbara-100-dctune
0.053200    159568  barbara-090
0.074300    218529  barbara-095-dctune
0.114300    97960   barbara-085
0.116700    158596  barbara-090-dctune
0.126100    145461  barbara-090-dctune
0.128100    84035   barbara-080
0.139500    73947   barbara-075
0.148300    67581   barbara-070
0.156900    61869   barbara-065
0.165100    57061   barbara-060
0.166900    97171   barbara-085-dctune
0.172100    53293   barbara-055
0.180300    50134   barbara-050
0.184200    84003   barbara-080-dctune
0.187700    47002   barbara-045
0.189700    79977   barbara-080-dctune
0.197900    43509   barbara-040
0.207300    68985   barbara-075-dctune
0.208400    40251   barbara-035
0.219300    62755   barbara-070-dctune
0.223400    36342   barbara-030
0.228500    58433   barbara-065-dctune
0.237600    54916   barbara-060-dctune
0.244400    32109   barbara-025
0.245300    51563   barbara-055-dctune
0.245300    51563   barbara-060-dctune
0.261300    45925   barbara-045-dctune
0.261300    45925   barbara-050-dctune
0.275800    27372   barbara-020
0.285700    41121   barbara-040-dctune
0.285700    41121   barbara-045-dctune
0.308500    36822   barbara-035-dctune
0.308500    36822   barbara-040-dctune
0.326900    33394   barbara-030-dctune
0.329100    22041   barbara-015
0.354800    30106   barbara-025-dctune
0.354800    30106   barbara-030-dctune
0.382300    27315   barbara-025-dctune
0.403900    25015   barbara-020-dctune
0.433900    16044   barbara-010
0.447100    20595   barbara-020-dctune
0.471100    18578   barbara-015-dctune
0.489100    16356   barbara-015-dctune
0.574000    11589   barbara-010-dctune
0.629500    9800    barbara-010-dctune
0.691600    8834    barbara-005
0.967400    5382    barbara-005-dctune

[thorfdbg]

I've tested DCTune 2.0, compared to ImageMagick, and it doesn't seem any better (tried dctune -kbytes with approx sizes of imagemagick results)

The problem is that you here just compare the DCTune vision model with the SSIM vision model, thus what do you expect? DCTune is mostly driven by frequency weighting and a very coarse model of visual masking, SSIM (in its single-scale version) has no CSF model whatsoever, and the masking model is quite a bit off. A real test would require you to run subjective tests in a vision lab to get really meaningful results. However, if you're looking for a better quality index, I would highly recommend VDP instead of SSIM.