Why does set_scan_optimization_mode() call jpeg_set_defaults()?

[lilith]

I noticed set_scan_optimization_mode() calls jpeg_set_defaults() after setting the scan mode parameter. Is there a reason for this?

Looking at the mozjpeg C code, jpeg_c_set_int_param() for JINT_DC_SCAN_OPT_MODE just sets one field and doesn't call jpeg_set_defaults(). The official cjpeg tool also doesn't call it when setting this parameter.

The side effect is that jpeg_set_defaults() resets a bunch of other settings (subsampling, smoothing_factor, raw_data_in, pixel density, etc), which causes ordering-dependent behavior:

comp.set_smoothing_factor(50);
comp.set_scan_optimization_mode(ScanMode::Auto);
// smoothing_factor just got reset to 0

I tried removing the jpeg_set_defaults() call and tests still pass. Is there some mozjpeg-specific reason it needs to be there, or was this maybe copied from set_fastest_defaults() where it might make more sense?

Thanks!

[lilith]

For now, I made a PR documenting current behavior. I've addressed the class of issues with a new API that makes most mutually exclusive configs inexpressible. #48

[kornelski]

libjpeg requires calling set_defaults to apply some of the public settings to its private fields. Otherwise internal scan script can be invalid for the number of components.

I think the best solution would be to collect all the settings in a Rust-native struct, and then apply them all at once when encoding is started.

[lilith]

It would be a breaking change, want a PR tho?

[lilith]

This one does lazy evaluation and applies deltas of changed settings before and after access to .components() and .cinfo_mut() etc, so probably as non-breaking as you can get, but still technically a major semver bump.

#51