fastcrush=1 and dc-scan-opt=0 are incompatible and cause crash/error

[lambdapioneer]

Hi, if I'm both enabling fastcrush (disabling scan optimization) and setting scan-opt-mode to 0, the cjpeg tool ends in an error state. The same is true when trying to set this setting combination in code.

Observed behaviour and repro:

Setting both options crashes the cjpeg CLI tool and results in an error. The output file is empty.

[user:mozjpeg]$ ./cjpeg -fastcrush -dc-scan-opt 0 testimages/nightshot_iso_100.bmp > foo.jpg
Invalid progressive parameters at scan script entry 10

[user:mozjpeg]$ echo $?
1

[user:mozjpeg]$ ./cjpeg -version
mozjpeg version 3.2 (build 20170421)

Expected behaviour:

• The cjpeg tool creates a valid JPG output file
• The encoding runs faster than without setting the -fastcrush option
• The created output file only has one scan for the DC scans for all components (ensures compatibility)

Alternative expected behaviour:

• The cjpeg tools produces an output that both options are not supported at the same time
• This is reflected in the --help summary

However, I don't think that there should be a hard technical reason why the two options cannot be used together.

More information:

OS: MAC OS 10.12.3
MozJpeg: version3.2 (fresh from the pre-release page) - also tried the variant that's served via brew (version3.1)

Related code settings:

The behavior can also be triggered with the following code in a call-site:

jpeg_c_set_bool_param(cinfo, JBOOLEAN_OPTIMIZE_SCANS, FALSE);
jpeg_c_set_int_param(cinfo, JINT_DC_SCAN_OPT_MODE, 0);

[kornelski]

Indeed, these options don't make sense together.

Would you like to make a pull request that fixes it?

I suppose the best way to fix it would be not to attempt DC scan optimizations if progressive rendering is not enabled.

[lambdapioneer]

Thanks for the quick reply @pornel!

I might be just looking at this too long, but I think both flags should result in progressive outputs. Afaict, the -fastcrush flag just makes the code default to a given distribution of the DC/AC bands among scans without optimizing for the current input. And the -dc-scan-opt 0 results in merging the first three scans (DC scans) for compatibility.

This is what I get from running the output through exiftool (// comments are by me).

[user:mozjpeg]$ ./cjpeg testimages/nightshot_iso_100.bmp > foo.jpg && exiftool -v3 foo.jpg | grep -e SOS -e SOF
JPEG SOF2 (15 bytes):
JPEG SOS // DC1
JPEG SOS // DC2
JPEG SOS // DC3
JPEG SOS
JPEG SOS
JPEG SOS
JPEG SOS

[user:mozjpeg]$ ./cjpeg -fastcrush testimages/nightshot_iso_100.bmp > foo.jpg && exiftool -v3 foo.jpg | grep -e SOS -e SOF
JPEG SOF2 (15 bytes):
JPEG SOS // DC1
JPEG SOS // DC2
JPEG SOS // DC3
JPEG SOS
JPEG SOS
JPEG SOS
JPEG SOS
JPEG SOS
JPEG SOS
JPEG SOS

[user:mozjpeg]$ ./cjpeg -dc-scan-opt 0 testimages/nightshot_iso_100.bmp > foo.jpg && exiftool -v3 foo.jpg | grep -e SOS -e SOF
JPEG SOF2 (15 bytes):
JPEG SOS // DC1 DC2 DC3
JPEG SOS
JPEG SOS
JPEG SOS
JPEG SOS

Maybe I'm just misinterpreting the results, but it seems to me that they all have multiple scans and the SOF2 start tag.

So when setting both flags I'd expect the 2nd output, but with the first three ones merged. Resulting in 8 scans in the resulting JPEG. Or is there another way to ensure to have all DC bands in one scan for JBOOLEAN_OPTIMIZE_SCANS=false? Otherwise, I'd try with the "-scans file" option.

[lambdapioneer]

I've found the bug and the fix :) hopefully send you the pull-request soon