connect four (game)

[nospam.Ned Batchelder]

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 <bc at 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.