2x2 order
=========
The array accesses for un-JPEGing some pixels is a bit mind bending, so the accompanying diagram, which shows the most common 2x2 case might help.

Say a !Draw window containing a JPEG needs repainting, so some rectangles need un-JPEGing. Here's roughly what happens:

1. Call to JPEG_PlotTransformed
-------------------------------
Or JPEG_PlotScaled, which other than the front end checking being a bit simpler is handled much the same. The JPEG data is validated via jpeg_find_image_dims() and the call then switches to the same rails that the train for OS_SpriteOp 56 is on.

The putscaled_compiler notes that a JPEG is being plotted and performs various library initialisation by calling
  jpeg_decompressor_opts()
  jpeg_scan_file()
to set everything up.

At the point where a raster is needed by the blitter instead of fetching pixels from the sprite area, a call to jpeg_find_line() is made. This has a preallocated 'band buffer' of height 8 or 16 lines by however wide the JPEG is.

If the y coordinate is in the band buffer already a memory copy is made and the blitter code carries on as though it was reading from a sprite.
If the y coordinate is not in the band buffer (ie. passed into a different multiple of 8 or 16) some decompression is needed.

2. Decompression
----------------
There are a pile of pointers to offsets within the compressed data to allow fast seeking within the JPEG. The nearest pointer is found then the entropy decoding expands some more data (how much? see below).

3. Inverse DCT
--------------
Except for DC only plots, this is then passed through the inverse DCT to arrive at some 8x8 blocks of samples, these are DCTSIZE x DCTSIZE, or DCTSIZE2.

All samples are arranged to be 32 bit quantities for convenience of LDR and STR, other implementations use 16 bit samples and only expand when needed for fixed point calculations.

Samples are in what is described in the code as 'row order', so neighbouring words in memory are doing a vertical strip of rows, see the numbering in the diagram.

4. Colours
----------
Lastly, the samples are converted back to greyscales or RGB (as appropriate) into the band buffer in RISC OS pixel format.

Supported input formats are
 * YUV samples (a colour JPEG)
 * Y only samples (a greyscale JPEG)
those with RGB and CMYK and YCCK data are not currently supported.

Supported output formats are
 * 32bpp ie. true colour words of &0BGR
 * 16bpp ie. true colour half words of 555/565/444 colour
 * 8bpp 256 entry VIDC colours
 * 8bpp linear greyscale
 * Less than 8bpp are output as 32bpp and the blitter dithers them for us

The output band buffer is always width * 4 bytes long
                                 8 or 16 lines high
when output is requested in something other than 32bpp the band buffer is not resized, the sprite data is just squashed up in the top left corner. Therefore, loop iterations in the 8bpp code (for example) will always increment by outoffset * 4 bytes even though they only output a quarter of that data.

How many and what?
==================
On entry to a colour conversion routine a JCOEF pointer is passed which is the base of some DCTSIZE2 blocks in memory.

Supported sampling ratios are
 * "1x1" (8x8 luma pixels for each 8x8 chroma, best looking, bigger file)
 * "1x2" (8x16 luma pixels for each 8x8 chroma)
 * "2x1" (16x8 luma pixels for each 8x8 chroma)
 * "2x2" (16x16 luma pixel for each 8x8 chroma, most common, smallest file)
Note U and V must always be sampled at the same rate in this implementation.

There are 4 cases to consider:

1. Mono, DC conversion
When the JPEG is scaled very small a shortcut is taken to only use the DC value for each 8x8 tile because the actual 8 pixels would be too small to see anyway.
IDCT is not performed.
One DC value -> a line of 8 output pixels. The 8 rows are formed by address fiddling rather than actually outputting all 64 values since they're identical.

2. Mono
One inverse DCT is performed, to yield one 8x8 block of luma data.
Output is either 8bpp greyscale, or 32bpp greyscale.

3. Colour, DC conversion
       Y[0]  Y[1]  Y[2]  Y[3]  U     V
1x1 => Ydc   junk  junk  junk  Udc   Vdc
1x2 => Ydc   Ydc   junk  junk  Udc   Vdc
2x1 => Ydc   Ydc   junk  junk  Udc   Vdc
2x2 => Ydc   Ydc   Ydc   Ydc   Udc   Vdc

If outputting greyscales, the U and V values are discarded. The Y sample is simply duplicated (for both 8bpp and 32bpp) to fill as many 8x8 output patches as the sampling ratio implies.
If outputting colour (up to) 4 Y samples and UV are converted to RGB.
The process repeats until the scan line limit is reached, and 8 or 16 rows have been output.

4. Colour
       blk1  blk2  blk3  blk4  blk5  blk6
1x1 => 8x8Y  junk  junk  junk  8x8U  8x8V
1x2 => 8x8Y  8x8Y  junk  junk  8x8U  8x8V
2x1 => 8x8Y  8x8Y  junk  junk  8x8U  8x8V
2x2 => 8x8Y  8x8Y  8x8Y  8x8Y  8x8U  8x8V

If outputting greyscales, the U and V values are discarded. The Y samples are expanded to output a patch of 64 to 256 pixels as the sampling ratio implies.
If outputting colour, the 1x1; 1x2; 2x1 ratios are always converted to 32bpp format. For fewer colours a dither is optionally available.
The 2x2 sampling ratio is dealt with specially since it is the most frequently occurring and hence should be fastest.
 * 32bpp directly converts YUV to RGB for the 8 or 16 rows requested
 * 16bpp uses an ordered dither on 8:8:8 RGB data to get a 5:5:5 pixel block
 * 8bpp works by looking up the VIDC pixel in a big YUV table, then looking
   up the VIDC colour number in a big YUV table, subtracting the two
   values (to get the error) and scattering the error into the neighbouring
   pixels in a 'u' shaped dance. Optionally full error diffused dithering
   can be requested by the user, but is slower
anything less than 8bpp is dithered by the blitter, as it will look pretty
poor whatever technique you choose.

Dancing
=======
The 8bpp 'u' shaped dance needs to map from row order data to scan line order and do a little dance. The following BASIC illustrates this
 FORj=0TO7
   FORi=0TO31
     p=i AND 3
     PRINTi,j,((j<<1)AND7)+(((p-1)AND2)>>1)+(((i AND15)>>1)*8),j+((i>>2)*8)
   NEXT
 NEXT
the inner loop, i, can be thought of as counting output pixels, ie. 2 rows of 16 pixels. The outer loop, j, counts row pairs, therefore 8 pairs give the 16 scan lines expected. 
   