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.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
