On 11/27/17 1:57 PM, bartc wrote: > On 27/11/2017 17:41, Chris Angelico wrote: >> On Tue, Nov 28, 2017 at 2:14 AM, bartc <b...@freeuk.com> wrote: >>> JPEG uses lossy compression. The resulting recovered data is an >>> approximation of the original. >> >> Ah but it is a perfect representation of the JPEG stream. Any given >> compressed stream must always decode to the same output. The lossiness >> is on the ENcoding, not the DEcoding. > > You make it sound as bad as currency calculations where different > software must produce results that always match to the nearest cent. > > We're talking about perhaps +1 or -1 difference in the least > significant bit of one channel of one pixels. If the calculation is > consistent, then you will not know anything is amiss. > > By +1 or -1, I mean compared with the same jpeg converted by > independent means. > > I also passed the same jpeg through another C program (not mine) using > its own algorithms. There some pixels varied by up to +/- 9 from the > others (looking at the first 512 bytes of the conversion to ppm). > > Here's my test image: > https://github.com/bartg/langs/blob/master/card2.jpg (nothing naughty). > > Tell me what the definitive values of the pixels in this part of the > image should be (I believe this corresponds to roughly the leftmost > 180 pixels of the top line; there are two million pixels in all). And > tell me WHY you think those are the definitive ones. > > Bear in mind also that this is not intended to be the world's most > perfect software. But it does do a good enough job. And the other two > Python versions I have, at the minute don't work at all. > >
Surely the details of JPEG decompression, and the possible presence of flaws in certain decoders, is beyond the scope of this thread? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
