As https://github.com/image-rs/image is getting more mature it would make sense to add mozjpeg as an full featured jpegencoder.
What do you think?

Hi.

I got following error when running wasm-pack build --scope xxx . Could you please give me some tips?

......
cargo:warning=In file included from vendor/jcmainct.c:17:
cargo:warning=In file included from /Users/ma/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd/mozjpeg-sys-0.10.5/vendor/jinclude.h:42:
cargo:warning=In file included from /usr/include/stdlib.h:66:
cargo:warning=In file included from /usr/include/sys/wait.h:109:
cargo:warning=In file included from /usr/include/sys/signal.h:150:
cargo:warning=In file included from /usr/include/sys/_types/_sigaltstack.h:40:
cargo:warning=/usr/include/machine/types.h:37:2: error: architecture not supported
cargo:warning=#error architecture not supported
cargo:warning= ^
cargo:warning=fatal error: too many errors emitted, stopping now [-ferror-limit=]
cargo:warning=20 errors generated.
exit code: 1
cargo:warning=20 errors generated.
exit code: 1
cargo:warning=20 errors generated.
exit code: 1

--- stderr


error occurred: Command "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/Users/ma/CLionProjects/jpegcompressor/target/wasm32-unknown-unknown/release/build/mozjpeg-sys-d9ed3fe7b39facb5/out/include" "-I" "/Users/ma/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd/mozjpeg-sys-0.10.5/vendor" "-o" "/Users/ma/CLionProjects/jpegcompressor/target/wasm32-unknown-unknown/release/build/mozjpeg-sys-d9ed3fe7b39facb5/out/vendor/jcapimin.o" "-c" "vendor/jcapimin.c" with args "clang" did not execute successfully (status code exit code: 1).



Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit code: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

system infomation

macOS Catalina 10.15.4

clang infomation

Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.4.0
Thread model: posi

rustc infomation

rustc 1.43.1 (8d69840ab 2020-05-04)

Cargo.toml

[package]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2.64"
mozjpeg = { version = "0.8.19", default-features = false }

I want to optionally embed mozjpeg as an alternative to calling out to jpegtran.

It would be great to have an example for doing the equivalent of jpegtran -optimize with code.

I assume I have to first decompress, then compress with Compress::set_optimize_scans(true), but it would be great to get some confirmation from someone familiar with the library.

Hello, I am the author of the nokhwa crate. First of all, I would like to thank you for making this since it has saved me from decoding MJPEG myself.
One of our PRs are blocked due to the PR we need #25 not being on crates.io yet.
It would be greatly appreciated if there was a new version published.
Thank you.

I'm working on a rendering utility that can save images as JPEGs with specified quality. For a weird reason, I need the images saved by my utility to look the same as the ones produced by libjpeg's cjpeg. As there is no convenient libjpeg bindings for Rust, I'm using mozjpeg-rust, but the output looks very different for the same quality. Is it possible to configure the compressor in mozjpeg-rust to make it look similar in terms of the amount of artefacts? This is an example of what the output images currently look like:

libjpeg

mozjpeg

It's easy to notice that the mozjpeg one has much more artefacts than libjpeg.

The libjpeg image was produced by converting the image saved with 100 quality:

djpeg original.jpg | cjpeg -quality 30 > libjpeg_30.jpg

Original

And this is how I call mozjpeg-rust from my code:

    let mut compressor = Compress::new(ColorSpace::JCS_EXT_RGBA);
    compressor.set_quality(30.0);
    compressor.set_size(320, 240);
    compressor.set_mem_dest();
    compressor.start_compress();
    compressor.write_scanlines(&scanlines);
    compressor.finish_compress();

PS: if it's currently not possible in mozjpeg-rust, but possible in mozjpeg, that might help too.

This extern "C" fn explicitly unwinds:

Additionally, it seemingly intentionally makes my program silently exit with an error status, without printing the actual error to stderr. Why? 😆

Feature Request

Is it possible to select the subsampling mode when encoding? eg. from YUV444 to YUV422.

Apologies if this is known. Decoding doesn't report decode failures. The library internally prints:
Corrupt JPEG data: premature end of data segment

But this doesn't appear to be available to the rust client - there's no indication of this after accessing, e.g., read_raw_data or calling finish_decompress.

Happy to supply a corrupted image example if it's useful.

I could not build staticlib for ios target using command cargo lipo --release.
It told me that failed to run custom build command for mozjpeg-sys v2.0.3.
I really appreciate for your help.

I'm creating my own image optimization tool. Currently my implementation sets the default error message to: "Something went wrong." How can I extract the error message from catch_unwind? This function returns Any and this can be used to determine the type of a variable. What exactly is the type of error message?

I found that the mozjpeg library has the ability to write the icc profile to the encoded image, but neither mozjpeg-rust nor mozjpeg-sys provide this functionality. How can I achieve similar results using this wrapper or mozjpeg-sys crate?

Or is the better alternative to apply the icc profile using lcms2 or a similar tool?

Hi, I'm working on an HDR-to-SDR conversion utility and am using mozjpeg to write output JPEGs; it's working well on most systems I've tested including macOS x86_64 and Linux arm64, but fails with a "bus error" at runtime on macOS arm64 (MacBook Air with M1 processor, running macOS 11.3.1).

Here's my calling code, which seems fairly straightforward:

// mozjpeg is much faster than image crate's encoder
std::panic::catch_unwind(|| {
    use mozjpeg::{Compress, ColorSpace};
    let mut c = Compress::new(ColorSpace::JCS_EXT_RGB);
    c.set_size(data.width, data.height);
    c.set_quality(95.0);
    c.set_mem_dest(); // can't write direct to file?
    c.start_compress();
    if !c.write_scanlines(data.bytes()) {
        panic!("error writing scanlines");
    }
    c.finish_compress();
    let mut writer = File::create(filename).expect("error creating output file");
    let data = c.data_as_mut_slice().expect("error accessing JPEG output buffer");
    writer.write_all(data).expect("error writing output file");
}).map_err(|_| JpegWriteFailure)

For now I'm working around it by using the image crate's much slower encoder if building on macOS or iOS arm64, but this isn't ideal. :)

As someone who isn't familiar with libjpeg, it would be nice to have some encoding examples as well as some better documentation on the related functions.

https://docs.rs/mozjpeg/0.8.17/mozjpeg/decompress/struct.DecompressStarted.html#method.read_scanlines

This method will write arbitrary, user controlled bytes into a slice of T: Copy. This can lead to invalid instances of T to be returned. Same reason as rgb but without the 'static bound so a little different. This can be used to decode scanlines into a Vec<&'static u8> or something along those lines and dereference some arbitrary memory with a crafted input file. No writable variant this time.

Compress::set_quality calls jpeg_set_quality with force_baseline parameter as FALSE, which is not an issue as long as a decoder capable of reading non-baseline JPEG, like the IJG decoder, is used. For example, optimised JPEG decoder on macOS and iOS can not decode 16-bit quantization table entries which could be generated when force_baseline parameter is FALSE. While iOS does use libjpeg as a fallback, it is slower and causes performance regressions. (This was an issue a year ago, it is possible that it has been fixed in latest versions of iOS and macOS).

Would it be possible to add the ability to set this parameter as TRUE? Simply adding another parameter to Compress::set_quality would be a breaking change, so adding another method like Compress::set_quality_and_force_baseline could be a viable solution.

Relevant section in libjpeg manual:
https://github.com/mozilla/mozjpeg/blob/master/libjpeg.txt#L903