CODEWITHSUNDEEP
gojpeglibjpegmozjpeg
borellini
borellini

Reputation: 422

Using mozjpeg with its cjpeg has superior quality to using it as a library

I have been trying to use mozjpeg in my Go application for JPEG compression, since it seems to have very good quality when used through the cjpeg command-line utility it provides.

However, pictures compressed with my application have inferior quality - a lot more JPEG artefacts with the same quality level.

I am using go bindings for libjpeg-turbo / mozjpeg from https://github.com/subuk/go-mozjpeg/blob/master/jpeg/compress.go

My own code does not seem to be too complex:

    libjpegOptions := jpeg.EncoderOptions{
        Quality:         92,
        OptimizeCoding:  true,
        ProgressiveMode: true,
    }

    err = jpeg.Encode(buf, m, &libjpegOptions)
    if err != nil {
        return nil, err
    }

Both applications seem to link to the same version of mozjpeg library, installed with Homebrew:

$ otool -L /opt/mozjpeg/bin/cjpeg
/opt/mozjpeg/bin/cjpeg:
    /opt/mozjpeg/lib/libjpeg.62.dylib (compatibility version 65.0.0, current version 65.0.0)
    /usr/local/opt/libpng/lib/libpng16.16.dylib (compatibility version 51.0.0, current version 51.0.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

$ otool -L /Users/fabio/Code/go/bin/imageproxy
/Users/fabio/Code/go/bin/imageproxy:
    /opt/mozjpeg/lib/libjpeg.62.dylib (compatibility version 65.0.0, current version 65.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1451.0.0)
    /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.41.2)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

What could I try next to ensure that my application is using the same settings as cjpeg?

Upvotes: 1

Views: 1809

Answers (1)

borellini
borellini

Reputation: 422

Got to answer my own question, since I found a fix to the issue by going through mozjpeg's commit history. cjpeg has an implicit default for chroma subsampling on JPEG quality ratings above 80 in its argument parsing code, and boundaries of solid areas of certain colour look quite bad with the library default for chroma subsampling.

/*
    Disable chroma subsampling for good quality ratings, that's what cjpeg command does as well.
    That seems to cause some issues with red color.
*/
if opt.Quality >= 80 {
    compInfo := (*[3]C.jpeg_component_info)(unsafe.Pointer(cinfo.comp_info))
    compInfo[Y].h_samp_factor, compInfo[Y].v_samp_factor = 1, 1
    compInfo[Cb].h_samp_factor, compInfo[Cb].v_samp_factor = 1, 1
    compInfo[Cr].h_samp_factor, compInfo[Cr].v_samp_factor = 1, 1
}

Upvotes: 3

Related Questions