Obscure features of JPEG

(This is a modified version of what I wrote up at work when I saw that progressive JPEGs could be nearly a drop-in replacement that offered some additional functionality and ran some tests on this.)

Introduction

The long-established JPEG standard contains a considerable number of features that are seldom-used and sometimes virtually unknown. This all is in spite of the widespread use of JPEG and the fact that every JPEG decoder I tested was compatible with all of the features I will discuss, probably because IJG libjpeg (or this) runs basically everywhere.

Progressive JPEG

One of the better-known features, though still obscure, is that of progressive JPEGs. Progressive JPEGs contain the data in a different order than more standard (sequential) JPEGs, enabling the JPEG decoder to produce a full-sized image from just the beginning portion of a file (at a reduced detail level) and then refine those details as more of the file is available.

This was originally made for web usage over slow connections. While it is rarely-used, most modern browsers support this incremental display and refinement of the image, and even those applications that do not attempt this support still are able to read the full image.

Interestingly, since the only real difference between a progressive JPEG and a sequential one is that the coefficients come in a different order, the conversion between progressive and sequential is lossless. Various lossless compression steps are applied to these coefficients and as this reordering may permit a more efficient encoding, a progressive JPEG often is smaller than a sequential JPEG expressing an identical image.

One command I’ve used pretty frequently before posting a large photo online is:

jpegtran -optimize -progressive -copy all input.jpg > output.jpg

This losslessly converts input.jpg to a progressive version and optimizes it as well. (jpegtran can do some other things losslessly as well – flipping, cropping, rotating, transposing, converting to greyscale.)

Multi-scan JPEG

More obscure still is that progressive JPEG is a particular case of something more general: a multi-scan JPEG.

Standard JPEGs are single-scan sequential: All of the data is stored top-to-bottom, with all of the color components and coefficients together and in full. This includes, per MCU (minimum coded unit, an 8×8 pixel square or some small multiple of it), 64 coefficients each for each one of the 3 color components (typically Y,Cb,Cr). The coefficients are from an 8×8 DCT transform matrix, but they are stored in a zigzag order that preserves locality with regard to spatial frequency as this permits more efficient encoding. The first coefficient (0) is referred to as the DC coefficient; the others (1-63) are AC coefficients.

Multi-scan JPEG permits this information to be packed in a fairly arbitrary way (though with some restrictions). While information is still stored top-to-bottom, it permits for only some of the data in each MCU to be given, with the intention being that later scans will provide other parts of this data (hence the name multi-scan). More specifically:

  • The three color components (Y for grayscale, and Cb/Cr for color) may be split up between scans.
  • The 64 coefficients in each component may be split up. (Two restrictions apply here for any given scan: the DC coefficient must always precede the AC coefficients, and if only AC coefficients are sent, then they may only be for one single color component.)
  • Some bits of the coefficients may be split up. (This, too, is subject to a restriction, not to a given scan but to the entire image: You must specify some of the DC bits. AC bits are all optional. Information on how many bits are actually used here is almost nonexistent.)

In other words:

  • You may leave color information out to be added later.
  • You may let spatial detail be only a low-frequency approximation to be refined later with higher-frequency coefficients. (As far as I can tell, you cannot consistently reduce grayscale detail beyond the 8×8 pixel MCU while still recovering that detail in later scans.)
  • You may leave grayscale and color values at a lower precision (i.e. coarsely quantized) to have more precision added later.
  • You may do all of the above in almost any order and almost any number of steps.

Your libjpeg distribution probably contains something called wizard.txt someplace (say, /usr/share/docs/libjpeg8a or /usr/share/doc/libjpeg-progs); I don’t know if an online copy is readily available, but mine is here. I’ll leave detailed explanation of a scan script to the “Multiple Scan / Progression Control” section of this document, but note that:

  • Each non-commented line corresponds to one scan.
  • The first section, prior to the colon, specifies which plane to send, Y (0), Cb (1), or Cr (2).
  • The two fields immediately after the colon give the first and last indices of coefficients from that plane that should be in the scan. Those indices are from 0 to 63 in zigzag order; 0 = DC, 1-63 = AC in increasing frequency.
  • The two fields immediately after those specify which bits of those coefficients this scan contains.

According to that document, the standard script for a progressive JPEG is this:

# Initial DC scan for Y,Cb,Cr (lowest bit not sent)
0,1,2: 0-0,   0, 1 ;
# First AC scan: send first 5 Y AC coefficients, minus 2 lowest bits:
0:     1-5,   0, 2 ;
# Send all Cr,Cb AC coefficients, minus lowest bit:
# (chroma data is usually too small to be worth subdividing further;
#  but note we send Cr first since eye is least sensitive to Cb)
2:     1-63,  0, 1 ;
1:     1-63,  0, 1 ;
# Send remaining Y AC coefficients, minus 2 lowest bits:
0:     6-63,  0, 2 ;
# Send next-to-lowest bit of all Y AC coefficients:
0:     1-63,  2, 1 ;
# At this point we've sent all but the lowest bit of all coefficients.
# Send lowest bit of DC coefficients
0,1,2: 0-0,   1, 0 ;
# Send lowest bit of AC coefficients
2:     1-63,  1, 0 ;
1:     1-63,  1, 0 ;
# Y AC lowest bit scan is last; it's usually the largest scan
0:     1-63,  1, 0 ;

And for standard, sequential JPEG it is:

0 1 2: 0 63 0 0;

In this image I used a custom scan script that sent all of the Y data, then all Cb, then all Cr. Its custom scan script was just this:

0;
1;
2;

While not every browser may do this right, most browsers will render the greyscale as its comes in, then add color to it one plane at a time. It’ll be more obvious over a slower connection; I purposely left the image fairly large.

Code & Utilities

The cjpeg tool from libjpeg will (among other things) create a JPEG using a custom scan script. I used a command something like:

convert input.png ppm:- | cjpeg -quality 95 -optimize -scans scan_script > output.jpg

Or if the input is already a JPEG, jpegtran will do the same thing without needing a re-encode as it is lossless:

jpegtran -scans scan_script input.jpg > output.jpg

libjpeg has some interesting features as well. Rather than decoding an entire full-resolution JPEG and then scaling it down, for instance (a common use case when generating thumbnails), you may set it up when decoding so that it will simply do the reduction for you while decoding. This takes less time and uses less memory compared with getting the full decompressed version and resampling afterward.

The following C code, based loosely on example.c from libjpeg, will split up a multi-scan JPEG into a series of numbered PPM files, each one containing a scan. Look for cinfo.scale_num (circa lines 67, 68) to use the fast scaling features mentioned in the last paragraph, and note that the code only processes as much input JPEG as it needs for the next scan. (It needs nothing special to build besides a functioning libjpeg. gcc -ljpeg -o jpeg_split.o jpeg_split.c works for me.)

#include <stdio.h>
#include <jerror.h>
#include "jpeglib.h"
#include <setjmp.h>
#include <string.h>

void read_scan(struct jpeg_decompress_struct * cinfo,
               JSAMPARRAY buffer,
               char * base_output);
int read_JPEG_file (char * filename, int scanNumber, char * base_output);

int main(int argc, char **argv) {
    if (argc < 3) {
        printf("Usage: %s <Input JPEG> <Output base name>n", argv[0]);
        printf("This reads in the progressive/multi-scan JPEG given and writes out each scann");
        printf("to a separate PPM file, named with the scan number.n");
        return 1;
    }

    char * fname = argv[1];
    char * out_base = argv[2];
    read_JPEG_file(fname, 1, out_base);
    return 0;
}

struct error_mgr {
    struct jpeg_error_mgr pub;
    jmp_buf setjmp_buffer;
};

METHODDEF(void) error_exit (j_common_ptr cinfo) {
    struct error_mgr * err = (struct error_mgr *) cinfo->err;
    (*cinfo->err->output_message) (cinfo);
    longjmp(err->setjmp_buffer, 1);
}

int read_JPEG_file (char * filename, int scanNumber, char * base_output) {
    struct jpeg_decompress_struct cinfo;
    struct error_mgr jerr;
    FILE * infile;      /* source file */
    JSAMPARRAY buffer;  /* Output row buffer */
    int row_stride;     /* physical row width in output buffer */

    if ((infile = fopen(filename, "rb")) == NULL) {
        fprintf(stderr, "can't open %sn", filename);
        return 0;
    }

    // Set up the normal JPEG error routines, then override error_exit.
    cinfo.err = jpeg_std_error(&jerr.pub);
    jerr.pub.error_exit = error_exit;
    // Establish the setjmp return context for error_exit to use:
    if (setjmp(jerr.setjmp_buffer)) {
        jpeg_destroy_decompress(&cinfo);
        fclose(infile);
        return 0;
    }
    jpeg_create_decompress(&cinfo);
    jpeg_stdio_src(&cinfo, infile);
    (void) jpeg_read_header(&cinfo, TRUE);

    // Set some decompression parameters

    // Incremental reading requires this flag:
    cinfo.buffered_image = TRUE;
    // To perform fast scaling in the output, set these:
    cinfo.scale_num = 1;
    cinfo.scale_denom = 1;

    // Decompression begins...
    (void) jpeg_start_decompress(&cinfo);

    printf("JPEG is %s-scann", jpeg_has_multiple_scans(&cinfo) ? "multi" : "single");
    printf("Outputting %ix%in", cinfo.output_width, cinfo.output_height);

    // row_stride = JSAMPLEs per row in output buffer
    row_stride = cinfo.output_width * cinfo.output_components;
    // Make a one-row-high sample array that will go away when done with image
    buffer = (*cinfo.mem->alloc_sarray)
        ((j_common_ptr) &cinfo, JPOOL_IMAGE, row_stride, 1);

    // Start actually handling image data!
    while(!jpeg_input_complete(&cinfo)) {
        read_scan(&cinfo, buffer, base_output);
    }

    // Clean up.
    (void) jpeg_finish_decompress(&cinfo);
    jpeg_destroy_decompress(&cinfo);
    fclose(infile);

    if (jerr.pub.num_warnings) {
        printf("libjpeg indicates %i warningsn", jerr.pub.num_warnings);
    }
}

void read_scan(struct jpeg_decompress_struct * cinfo,
               JSAMPARRAY buffer,
               char * base_output)
{
    char out_name[1024];
    FILE * outfile = NULL;
    int scan_num = 0;

    scan_num = cinfo->input_scan_number;
    jpeg_start_output(cinfo, scan_num);

    // Read up to the next scan.
    int status;
    do {
        status = jpeg_consume_input(cinfo);
    } while (status != JPEG_REACHED_SOS && status != JPEG_REACHED_EOI);

    // Construct a filename & write PPM image header.
    snprintf(out_name, 1024, "%s%i.ppm", base_output, scan_num);
    if ((outfile = fopen(out_name, "wb")) == NULL) {
        fprintf(stderr, "Can't open %s for writing!n", out_name);
        return;
    }
    fprintf(outfile, "P6n%d %dn255n", cinfo->output_width, cinfo->output_height);

    // Read each scanline into 'buffer' and write it to the PPM.
    // (Note that libjpeg updates cinfo->output_scanline automatically)
    while (cinfo->output_scanline < cinfo->output_height) {
        jpeg_read_scanlines(cinfo, buffer, 1);
        fwrite(buffer[0], cinfo->output_components, cinfo->output_width, outfile);
    }

    jpeg_finish_output(cinfo);
    fclose(outfile);
}

Examples

Here are all 10 scans from a standard progressive JPEG, separated out with the example code:

QMake hackery: Dependencies & external preprocessing

Qt Creator is a favorite IDE of mine for when I have to deal with miserably large C++ projects. At my job I ported a build in Visual Studio of one such large project over to Qt Creator so that builds and development could be done on OS X and Linux, and in the process, learned a good deal about QMake and how to make it do some unexpected things.

While I find Qt Creator to be a vastly cleaner, lighter IDE than Visual Studio, and find QMake to be a far more straightforward build system for the majority of things than Visual Studio’s build system, some things the build needed were very tricky to set up in QMake. The two main shortcomings I ran into were:

  • Managing dependencies between projects, as building the application in question involved building 40-50 separate subprojects as libraries, many of which depended on each other.
  • Having external build events, as the application also had to call an external tool (no, not moc, this is different) to generate some source files and headers from a series of templates.

QMake, as it happens, has some commands that actually make the project files Turing-complete, albeit in a rather ugly way. The eval command is the main source of this, and I made heavy use of it.

First is the dependency management system. It’s a little large, but I’m including it inline here.

# This file is meant to be included in from other project files, but it needs
# a particular context:
# (1) Make sure that the variable TEMPLATE is set to: subdirs, lib, or app.
#     Your project file really should be doing this anyway.
# (2) Set DEPENDS to a list of dependencies that must be linked in.
# (3) Set DEPENDS_NOLINK to a list of dependencies from which headers are
#     needed, but which are not linked in. (Doesn't matter for 'subdirs'
#     template)
# (4) Make sure BASEDIR is set.
#
# This script may modify SUBDIRS, INCLUDEPATH, and LIBS. It should always add,
# not replace.
# It will halt execution if BASEDIR or TEMPLATE are not set, or if DEPENDS or
# DEPENDS_NOLINK reference something not defined in the table.
#
# Order does matter in DEPENDS for the "subdirs" template. Items which come
# first should satisfy dependencies for items that come later.
# You'll often see:
# include ($$(BASEDIR)/qmakeDefault.pri)
# which includes this file automatically.
#
# -CMH 2011-06

# ----------------------------------------------------------------------------
# Messages and sanity checks
# ----------------------------------------------------------------------------
message("Included Dependencies.pro!")
message("Dependencies: " $$DEPENDS)
message("Dependencies (INCLUDEPATH only): " $$DEPENDS_NOLINK)
#message("TEMPLATE is: " $$TEMPLATE)

isEmpty(BASEDIR) {
    error("BASEDIR variable is empty here. Make sure it is set!")
}
isEmpty(TEMPLATE) {
    error("TEMPLATE variable is empty here. Make sure it is set!")
}

# ----------------------------------------------------------------------------
# Table of project locations
# ----------------------------------------------------------------------------

# Some common locations, here only to shorten descriptions in the _PROJ table.
_PROJECT1   = $$BASEDIR/SomeProject
_PROJECT2   = $$BASEDIR/SomeOtherProject
_DEPENDENCY = $$BASEDIR/SomeDependency

# Table of project file locations
# (Include paths are also generated based off of these)
_PROJ.FooLib               = $$_PROJECT1/Libs/FooLib
_PROJ.BarLib               = $$_PROJECT1/Libs/BarLib
_PROJ.OtherStuff           = $$_PROJECT2/Libs/BarLib
_PROJ.MoreStuff            = $$_PROJECT2/Libs/BarLib
_PROJ.ExternalLib          = $$BASEDIR/SomeLibrary

# ----------------------------------------------------------------------------
# Iterate over dependencies and update variables, as appropriate for the given
# template type
# ----------------------------------------------------------------------------

# _valid is a flag telling whether TEMPLATE has matched anything yet
_valid = false

contains(TEMPLATE, "subdirs") {
    for(dependency, DEPENDS) {
        # Look for an item like: _PROJ.(dependency)

        # Disclaimer: I wrote this and it works. I have no idea why precisely
        # why it works. However, I repeat the pattern several times.
        eval(_dep = $$"_PROJ.$${dependency}")
        isEmpty(_dep) {
            error("Unknown dependency " $${dependency} "!")
        }

        # If that looks okay, then update SUBDIRS.
        eval(SUBDIRS += $$"_PROJ.$${dependency}")
    }
    message("Setting SUBDIRS=" $$SUBDIRS)
    _valid = true
}

contains(TEMPLATE, "app") | contains(TEMPLATE, "lib") {
    # Loop over every dependency listed in DEPENDS.
    for(dependency, DEPENDS) {
        # Look for an item like: _PROJ.(dependency)
        eval(_dep = $$"_PROJ.$${dependency}")
        isEmpty(_dep) {
            error("Unknown dependency " $${dependency} "!")
        }

        # If that looks okay, then update both INCLUDEPATH and LIBS.
        eval(INCLUDEPATH += $$"_PROJ.$${dependency}"/include)
        eval(LIBS += -l$${dependency}$${LIBSUFFIX})
    }
    for(dependency, DEPENDS_NOLINK) {
        # Look for an item like: _PROJ.(dependency)
        eval(_dep = $$"_PROJ.$${dependency}")
        isEmpty(_dep) {
            error("Unknown dependency " $${dependency} "!")
        }

        # If that looks okay, then update INCLUDEPATH.
        eval(INCLUDEPATH += $$"_PROJ.$${dependency}"/include)
    }
    #message("Setting INCLUDEPATH=" $$INCLUDEPATH)
    #message("Setting LIBS=" $$LIBS)
    _valid = true
}

# If no template type has matched, throw an error.
contains(_valid, "false") {
    error("Don't recognize template type: " $${TEMPLATE})
}

It’s been sanitized heavily to remove all sorts of details from the huge project it was taken from. Mostly, you need to add your dependent projects into the “Table of Project Locations” section, and perhaps make another file that set up the necessary variables mentioned at the top. Then set the DEPENDS variable to a list of project names, and then include this QMake file from all of your individual projects (it may be necessary to include it pretty close to the top of the file).

In general, in this large application, each sub-project had two project files:

  1. One with TEMPLATE = lib (a few were app instead as well). This is the project file that is included in as a dependency from any project that has TEMPLATE = subdirs, and this project file makes use of the QMake monstrosity above to set up the include and library paths for any dependencies.
  2. One with TEMPLATE = subdirs. The same QMake monstrosity is used here to include in the project files (of the sort in #1) of dependencies so that they are built in the first place, and permit you to build the sub-project standalone if needed.

…and both are needed if you want to be able to build sub-project independently and without making to take care of dependencies individually.

The next project down below sort of shows the use of that QMake monstrosity above, though in a semi-useless sanitized form. Its purpose is to show another system, but I’ll explain that below it.

QT -= gui
QT -= core
TEMPLATE = lib

## Include our qmake defaults
DEPENDS = FooLib BarLib
include ($$(BASEDIR)/qmakeDefault.pri)

TARGET = Project$${LIBSUFFIX}
LIBS += -llua5.1 -lrt -lLua$${LIBSUFFIX}
DEFINES += PROJECT_EXPORTS

INCLUDEPATH += /usr/include/lua5.1 
    ./include

HEADERS += include/SomeHeader.h 
    include/SomeOtherHeader.h

SOURCES += source/SomeClass.cpp 
    source/SomeOtherClass.cpp

# The rest of this is done with custom build steps:
GENERATOR_INPUTS = templates/TemplateFile.ext 
    templates/OtherTemplate.ext

gen.input = GENERATOR_INPUTS
gen.commands = $${DESTDIR}/generator -i $${QMAKE_FILE_IN}
# -s source$(InputName).cpp -h include$(InputName).h

# Set the destination of the source and header files.
SOURCE_DIR = "source/"
HEADER_DIR = "include/"
# What prefix and suffix to replace with paths and .h.cpp, respectively.
TEMPLATE_PREFIX = "external/"
TEMPLATE_EXTN = ".ext"

#
# Warning: Here be black magic.
#
# We need to use QMAKE_EXTRA_COMPILERS but its functionality does not give us
# an easy way to explicitly specify the names of multiple output files with a
# single QMAKE_EXTRA_COMPILERS entry. So, we get around this by making one
# entry for each input template (the .ext files).
# The part where this gets tricky is that each entry requires a unique
# variable name, so we must create these variables dynamically, which would
# be impossible in QMake ordinarily since it does only a single eval pass.
# Luckily, QMake has an eval(...) command which explicitly performs an eval
# pass on a string. We repeatedly use constructs like this:
#    $$CONTENTS = "Some string data"
#    $$VARNAME = "STRING"
#    eval($$VARNAME = $$CONTENTS)
# These let us dynamically define variables. For sanity, I've tried to use a
# suffix of _VARNAME on any variable which contains the name of another
# variable.
#

# Iterate over every filename in GENERATOR_INPUTS
for(templatefile, GENERATOR_INPUTS) {
    # Generate the name of the header file.
    H1 = $$replace(templatefile, $$TEMPLATE_PREFIX, $$HEADER_DIR)
    HEADER = $$replace(H1, $$TEMPLATE_EXTN, ".h")
    # Generate the name of the source file.
    S1 = $$replace(templatefile, $TEMPLATE_PREFIX, $$SOURCE_DIR)
    SOURCE = $$replace(S1, $$TEMPLATE_EXTN, ".cpp")
    # Generate unique variable name to populate & pass to QMAKE_EXTRA_COMPILERS
    QEC_VARNAME = $$replace(templatefile, ".", "")
    QEC_VARNAME = $$replace(QEC_VARNAME, "/", "")
    VARNAME = $$replace(QEC_VARNAME, "\", "")
    # Append _INPUT to generate another variable name for the input filename
    INPUT_VARNAME = $${QEC_VARNAME}_INPUT
    eval($${INPUT_VARNAME} = $$templatefile)

    # Now generate an entry to pass to QMAKE_EXTRA_COMPILERS.
    eval($${VARNAME}.commands = $${DESTDIR}/generator -i ${QMAKE_FILE_IN} -s ${QMAKE_FILE_OUT} -h $${HEADER})
    eval($${VARNAME}.name = $$VARNAME)
    # ACHTUNG! The 'input' field is the _variable name_ which contains the
    # input filename, not the filename itself. If you put in a filename or
    # either of those variables don't exist, this will fail, silently, and
    # all attempts at diagnosis will lead you nowhere.
    eval($${VARNAME}.input = $${INPUT_VARNAME})
    eval($${VARNAME}.output = $${SOURCE})
    eval($${VARNAME}.variable_out = SOURCES)

    # Now tell QMake to actually do this step we meticulously built.
    eval(QMAKE_EXTRA_COMPILERS += $$VARNAME)
    # Also add our header files. I doubt it's really necessary, but here it is.
    HEADERS += $${HEADER}
}

This one uses a bit more black magic. The entire GENERATOR_INPUTS list is a set of files that are inputs to an external program that is called to generate some code, which then must be built with the rest of the project. This uses undocumented QMake features, and a couple kludges to generate some things dynamically (i.e. the filenames of the generated code) from a variable-length list. I highly recommend avoiding it. However, it does work.

These two links proved indispensable in the creation of this:

QMake Variable Reference

Undocumented qmake