It's poorly named. Not very useful. Not orthogonal with other options.

"moz defaults" doesn't really mean anything (the real functionality is related to enabling more expensive encoding features, but you can't guess that from the name of the parameter). Now that moz defaults are in fact the default, this option became a way to switch to default settings of libjpeg 6b, so a better name would be JBOOLEAN_USE_LIBJPEG6B_DEFAULTS.

libjpeg 6b default settings are a bit outdated now, so I wouldn't even encourage use of them by having such option. If somebody needs exact legacy defaults for compatibility, it's unlikely they'd take effort to use mozjpeg and then disable mozjpeg's features. If somebody needs them for specific purpose, e.g. single-pass encoding, there should be more specific settings to enable that.

Overall I think it would be better to have a set of clearer, more specific options and not include a vague concept of "moz defaults" as part of the API.

Currently the encoder switches between "JPEG default" and flat quantization tables based on the metric it is tuning for. There ought to be better tables, including tables tuned for each individual image.

Hi,

we have noticed that mozjpeg compiled with clang-3.8.0 causes many segfaults i.e. firefox, dolphin. https://issues.openmandriva.org/show_bug.cgi?id=1560 https://issues.openmandriva.org/show_bug.cgi?id=1559

Sources for uour mozjpeg package can be found here https://github.com/OpenMandrivaAssociation/mozjpeg

The Windows binaries generated from the 3.0 release source by following the instructions in BUILDING.txt does not appear to have PNG support enabled.

When a PNG file is passed as input to cjpeg.exe, the following error message is displayed: Unrecognized input file format --- perhaps you need -targa

I have manually compiled libpng and modified INCLUDE and LIBPATH, but that did not enable PNG support.

I have also tried manually editing jconfig.h to set PNG_SUPPORTED macro, but this approach did not work either.

Background: I'm trying to compress images at a specific DSSIM quality, and for that I need to try a few different JPEG quality levels, as quickly as possible.

I wanted to enable trellis quantization (because it visibly affects the output), but disable all other slow optimizations, since I don't look at the file size when only measuring quality.

However, using just trellis is tricky and I didn't find documentation for it.

I've tried:

jpeg_set_defaults(&cinfo);
jpeg_c_set_bool_param(&cinfo, JBOOLEAN_OPTIMIZE_SCANS, FALSE);
cinfo.optimize_coding = FALSE;

but there appears to be non-obvious coupling between trellis and progressive scan optimization:

Invalid progressive parameters at scan script entry 4

An alternative approach doesn't work either:

jpeg_c_set_bool_param(&cinfo, JBOOLEAN_USE_MOZ_DEFAULTS, FALSE); 
jpeg_set_defaults(&cinfo);
jpeg_c_set_bool_param(&cinfo, JBOOLEAN_TRELLIS_QUANT, TRUE);

Bogus buffer control mode

I think the current settings are too low-level and don't hide implementation details of the library. I shouldn't be required to know that one setting depends on some other, seemingly unrelated settings. Flipping a single option on or off should do just that — not crash the library.

So if I just execute jpeg_c_set_bool_param(&cinfo, JBOOLEAN_TRELLIS_QUANT, TRUE) I expect that to automatically enable everything that trellis depends on behind the scenes, and not crash.

Some parameters (like "${CMAKE_SOURCE_DIR}" and "${CMAKE_CURRENT_BINARY_DIR}") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like spaces.

I would recommend to apply advices from a Wiki article.

This improves compression of black-on-white text and line art with sharp edges as mentioned in #7

The trick is essentially based on making white areas even whiter, so that ringing artefacts mostly remain above the maximum level of white, and are hidden by clipping done in the decoder (all JPEG decoders must perform clipping, because even standard encoding accidentally creates overshoot values).

I've described it in more detail: https://pornel.net/deringing/

This implementation works for black-on-white details (positive overshoot) only, and doesn't attempt to do anything for white-on-black details (negative overshoot). This is because sRGB gamma makes ringing artefacts much more visible on white background than on black background.

This JPEG has the same file size as well-optimized PNG source. Notice how area around black lines is cleaner on white background than on color background:

I am using mozjpeg for a few months (and I like it !). Recently, I compared with jpegoptim on simple images (typically one object on white background). I successfully target the same low size, achieving good quality (like low quality in https://imageoptim/online).

For non-specialists, is there general simple rules to help choose between mozjpeg and jpegoptim ?

Please write in usage.txt how to perform resize 50% in.jpg out.jpg

don`t work:

jpegtran.exe -scale 1/2 in.jpg -outfile out.jpg
djpeg.exe -scale 1/2 in.jpg > out.jpg

Original comment containing links to test images: https://news.ycombinator.com/item?id=8807536

Problem spotted: https://news.ycombinator.com/item?id=8807554

Images: http://i.imgur.com/DTxTcLp.jpg http://i.imgur.com/jVESWGS.jpg

There is a trick used when compressing images for high-DPI ("Retina") displays: because details are less visible in higher resolution (or when resampled on lower-resolution displays), the image can tolerate higher level of compression.

http://filamentgroup.com/lab/compressive-images.html http://gogrowstrategies.com/compressive-images/

Unfortunately in libjpeg the quantization tables are derived from default tables by proportionally scaling all coefficients.

The problem with that is that very low quality settings cause DC to be quantized too heavily, virtually guaranteeing that the image will look blocky and posterized. Giving bits to ACs can't help if the DC is awful.

My suggestion is:

• Tweak the algorithm in jpeg_add_quant_table to quantize DC and the first few ACs less when the quality is very low.
• Add a switch to cjpeg for optimization for high-dpi displays. It'd adjust quality scale (lower the quality), quantization tables (protect DC from getting too blocky) and perhaps adjust the lambda for trellis.

The implementation I've done https://github.com/pornel/mozjpeg/commit/615652b81a8e93c50d5ec72a0f1a29e5af71ee1e just increases DC and the first few ACs. It does work, but maybe an even more elegant approach would be to devise quantization tables optimized for low and high qualities and crate final quantization table from interpolation between these tables.

I have created a program that loops through a given folder and runs jpegtran on every jpg file it finds. If I get an output file and it is smaller than the input jpg, then it overwrites the input file. Below are the arguments that I use for which I expect lossless reduction

-optimize -progressive -copy none -outfile "F:\pictures\optimised.tmp" "F:\pictures\Image00.jpg"

I ran it on files that had been optimised by that older version, actually only one file which came out larger than the input jpg. Very unexpected, I thought it would be same size. I haven’t tested if this true for the other files as well. I know for sure that I ran the older version for rhe files in this particular folder.

Therefore, I wonder if I’m doing something wrong or if it’s normal to sometimes get optimised pictures that are larger. After all it could be so if jpegtran repairs the file if it doesn’t have a marker that it should in which case I should accept the output file as better albeit larger. If jpegtran repairs files then I think the return value should indicate success and repaiired.

Btw I have noticed that some jpg files lack the marker that indicates height and width which van be opened anyway. Is ther any open source programs that takes can fix this and similar problems?

The docs say default quality is 75.

When using stock cjpeg, both these commands result in identical output:

cjpeg -sample 1x1
cjpeg -sample 1x1 -q 75

However, with mozjpeg these two commands result in very different output. What exactly is going on here?

https://ci.appveyor.com/project/kornel/mozjpeg-4ekrx/builds/44465987

Creating "v4.1.1" release for repository "mozilla/mozjpeg" tag "v4.1.1" commit "a2d2907ff023227e80c1e4efa809812410275a12"...Error creating GitHub release: Error reading repository 'mozilla/mozjpeg' releases: 401 - Unauthorized

Hi, I repaired some jpeg encrypted jpeg by ransomware ( encrypted 150kb of header ) but when i move the good header to corrupt jpeg, how can i fix the color of this jpeg: