Put a JPEG's chroma back the way every other reader does

[tannevaled]

Diagnoses and closes #40.

The cause

Our JPEG decode disagrees with poppler because of chroma upsampling, and because of nothing else.

Go's image/jpeg hands back an *image.YCbCr. Reading that through raster.FromImage reads chroma through image.YCbCr.COffset, which divides x and y by the sampling factor (image/ycbcr.go:101), so a 4:2:0 picture's chroma is replicated: four pixels share one sample exactly.

libjpeg interpolates instead — three quarters of the nearer chroma sample and one quarter of the further one, each way. That is "fancy upsampling", and it is on by default (jdapimin.c:229). poppler never touches the flag (DCTStream.cc:98), and neither do pdfium, mupdf or Ghostscript.

The evidence that it is only this

decoded how	vs poppler's pdfimages -png
greyscale JPEG, 112 real corpus pictures	largest channel difference 1 level — the ISO/IEC 10918-2 IDCT allowance exactly
4:4:4 colour, synthetic	bit-identical
4:2:0 colour, us-dol/CA-10.pdf — before	56 levels, on 48.3% of pixels
4:2:0 colour, us-dol/CA-10.pdf — after this change	3 levels, on 0.018% of pixels

A greyscale JPEG and a 4:4:4 one have no chroma to put back, and on those the Huffman decode, the dequantiser, the IDCT and the colour matrix already agreed with libjpeg. The 3 levels that remain are two conformant IDCTs, each within the ISO allowance of the reference and so up to 2 apart in Y, Cb and Cr, carried through the colour matrix.

What it does

It reproduces libjpeg's filter, and only where libjpeg applies it:

• 4:2:0, 4:2:2 and 4:4:0 — and within those only when the chroma plane is more than two samples wide, because libjpeg falls back to replication below that (jdsample.c, compptr->downsampled_width > 2).
• 4:1:1 and 4:1:0 have no fancy method in libjpeg at all — they go through int_upsample, which replicates — so they are left alone.
• A picture with no chroma to put back is left alone.

TestChromaIsLeftAloneWhereLibjpegLeavesItAlone asserts each of those cases comes out byte for byte as raster.FromImage would have made it, so this cannot become the odd one out in the other direction.

TestChromaIsPutBackTheWayLibjpegPutsItBack pins the three interpolated samplings against expected rows evaluated from libjpeg's own expressions — including the asymmetric biases, 1 for the upper row of a pair and 2 for the lower — rather than from this code's output. A test that only agreed with itself would assert nothing about a decoder written in another language.

Rows rather than planes

The reconstruction is made one row at a time into a buffer the plane owns, not into two whole extra planes beside the picture: a picture is already the largest thing a page allocates, and reconstructing both planes in full would have raised what a JPEG costs by half for no gain. An edge row reads the last real row twice rather than the MCU padding that follows it in memory, which is what libjpeg does (jdmainct.c:217) and is the only reading under which the two agree.

Not merged on my own judgement

Neither behaviour violates ISO/IEC 10918 — the standard specifies the IDCT and leaves reconstruction open, and pdf.js replicates too (src/core/jpg.js truncates with 0 | (x * componentScaleX)). This changes the output of every subsampled JPEG in the fleet, so it is a proposal, not a defect fix. Please decide it rather than auto-merging it.