On 8/4/2012 2:39 PM, Terje Mathisen wrote:
> BGB wrote:
>> in this case, the calculation being integer-exact (and reversible) was
>> an important point of the calculation, and I saw little point on people
>> insisting on a form of the calculation which would often result in the
>> wrong answer (I saw it, got suspicious, and rigged up a test that had
>> confirmed that, yes, the original calculation was not reliable, and that
>> the reworked calculation was).
>>
>> but, whatever sometimes, luckily I have authority over my own code...
>>
>>
>> (note: technically this was related to a lossless variant of JPEG which
>> remains backwards compatible with lossy decoders, and works mostly by
>> using a tweaked DCT transform and colorspace conversions).
>
> Nice!
>
yeah.
FWIW, the guy working on libjpeg has added similar functionality, but
there are minor differences in the implementation (so, full
compatibility is less certain).
the basic idea though it that an alternate version of DCT is used (SERMS
RDCT), which differs from the normal DCT in being fully reversible, but
is also still compatible with the (lossy) DCT.
also, all quantization values are set to 1 (no quantization).
the color conversion is a little harder, since the usual YCbCr color
conversion ends up using a smaller output range than the input range,
and so can't be made lossless.
the solution is partly to use an alternate color conversion with a
larger value range (based on JPEG-2000 RCT). a downside of this though
is that, for decoders which are not aware of the alternate colorspace,
the colors come out "slightly off" (mostly the color saturation is a bit
higher).
the math in question mostly had to do with the RCT color conversions.
another theoretical option would have been the use of raw-RGB, but of
the apps I had to test with, none seemed to recognize the markers to
indicate the use of the RGB colorspace, so it was a tradeoff between
"slightly off" and "totally wrong" (most apps don't recognize much
outside the range of generic JFIF style images). (the main alternative,
used by libjpeg, would require storing an alternate image for the
lossless version, considerably adding to the image size).
technically, my implementation is domain specific and has a number of
non-standard extensions to JPEG anyways (mostly adding stuff relevant to
textures in a 3D engine, such as alpha blending, depth/normal maps,
specular maps, luminance maps, support for limited-precision
floating-point data in images, ...).
these extensions are backwards compatible in that an unaware
implementation will generally just ignore them.
> Terje
>
>