Proof of concept code available in the compressed_raw branch (silent pictures with lossless DNG output).
Some more details about how I've got valid DNGs:
Take a look at
this picture and look for TTL (TwoInTwoOutLossless) channels. The green one with two ramps (channel #8) has a pretty strange configuration:
(5180, skip 5208) x 3949, 5180, skip -41022212, (5180, skip 5208) x 3950
5180 + 5208 = 10388 = 5936 * 14/8 (horizontal raw resolution, including black bars and a few extra columns present in the raw buffer, but - for some unknown reason - not saved in the CR2)
5180 * 2 = 10360 = 5920 (horizontal CR2 resolution, with dcraw -4 -E)
(5180 + 5208) * 3949 + 5180 - 41022212 = 5180.
Now, the meaning of the above code is clear: read the left half of the image (5180 bytes = 2960 pixels), rewind and read the right half (also 2960). These are the two cr2_slice's (see dcraw code at lossless_jpeg_load_raw and lclevy's docs from first post).
A lossless DNG is decoded with a somewhat similar loop, in lossless_dng_load_raw, which treats the compressed payload as a single slice. With default encoder configuration, dcraw would render a 2960x7900 image (left and right halves stacked vertically).
Now, my encoder mod becomes obvious: double the slice width (so it becomes equal to image width) and halve the height. The encoder doesn't really care what the image layout is - it knows there are two slices (with given dimensions). It uses the data coming from the read EDMAC to fill the first slice, then the second one; therefore, the EDMAC transfer can be configured to just read the image as usual (the first half will be the top of the image, the second half will be the bottom).
In the DNG, the decoder sees a lossless jpg payload; it doesn't really care about the dimensions, as long as the total pixel count matches.
Result: the trick may be a little hackish, but Adobe's dng_validate accepts it
