Home > Archive > Compression > October 2004 > JPEG image data
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Is it true that the image data for given JPEG (baseline) file depends
on the used decoder, i.e. there is no unique image data?
Thank you,
Greg
| |
|
| I would say that this is only true to the extent that decoding
accuracy depends on the arithmetic precision of the decoder.
"Greg" <gregrswartz@yahoo.com> wrote in message
news:78ba78f3.0410160504.75194fe4@posting.google.com...
> Is it true that the image data for given JPEG (baseline) file depends
> on the used decoder, i.e. there is no unique image data?
>
> Thank you,
> Greg
| |
|
| So from mathematical standpoint it is possible to decode the unique
image data?
If this is true why there exist decoders which do not decode the
correct(unique) image for some JPEG files?
Thanks,
Greg
"Pat" <ebooks2goNOSPAM@yahoo.co.uk> wrote in message news:<cks5jb$8s9$1@titan.btinternet.com>...[color=darkred]
> I would say that this is only true to the extent that decoding
> accuracy depends on the arithmetic precision of the decoder.
>
> "Greg" <gregrswartz@yahoo.com> wrote in message
> news:78ba78f3.0410160504.75194fe4@posting.google.com...
| |
|
| It might help if you were more specific, with an example.
Personally I'm not an expert, but it's possible to pick and mix
from the JPEG specification, and decide not to implement certain parts.
For example you specified baseline files. Even here you could have a
sequential
or a progressive mode picture file. It may not be 'legal' to ignore
progressive
files but it is very tempting to the 'amateur' developer.
"Greg" <gregrswartz@yahoo.com> wrote in message
news:78ba78f3.0410170623.d1a2471@posting.google.com...
> So from mathematical standpoint it is possible to decode the unique
> image data?
>
> If this is true why there exist decoders which do not decode the
> correct(unique) image for some JPEG files?
>
> Thanks,
> Greg
>
> "Pat" <ebooks2goNOSPAM@yahoo.co.uk> wrote in message
news:<cks5jb$8s9$1@titan.btinternet.com>...[color=darkred]
| |
| Thomas Richter 2004-10-18, 8:55 am |
| Hi Greg,
> So from mathematical standpoint it is possible to decode the unique
> image data?
Actually, your question doesn't really make much sense. JPEG is a lossy
image compression. As such, there are many pre-images that compress
to the same JPEG (simply by quantization) and as such there is
ambiguity defined in the compression scheme already.
> If this is true why there exist decoders which do not decode the
> correct(unique) image for some JPEG files?
There is no "correct" pre-image for a given JPEG. There is a full
set of them. This is not just a limitation of the compuational
accuracy of the DCT, it is also a matter of picking,
actually *choosing*, a reconstruction point for the dequantizer.
In fact, it often helps to improve the "visual image quality" to
post-process the resulting reconstructed image in order to lower
the visibility of the DCT block boundaries.
So long,
Thomas
| |
|
| Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message news:<cl02un$99i$2@mamenchi.zrz.TU-Berlin.DE>...
>
> Actually, your question doesn't really make much sense. JPEG is a lossy
> image compression. As such, there are many pre-images that compress
> to the same JPEG (simply by quantization) and as such there is
> ambiguity defined in the compression scheme already.
I didn't ask for the pre-images.
Every JPEG file contains encoded image data.
I asked whether there exists a standardized deterministic algorithm(or
way) for decoding of that image data for every baseline JPEG file.
For example it is possible to lossy convert image data A to B and then
convert B to PNG(B), where PNG(B) is the image data B encoded in PNG
format. At this point there is only one way to decode PNG(B) and
therefore only one(unique) decoded image.
>
> This is not just a limitation of the compuational
> accuracy of the DCT, it is also a matter of picking,
> actually *choosing*, a reconstruction point for the dequantizer.
This imply that the decoded image depends on the implementation of the
decoder, because there is no standardized algorithm(or way) for
decoding baseline JPEG files. Right?
Thank you,
Greg
| |
| Guido Vollbeding 2004-10-18, 3:55 pm |
| Greg wrote:
>
> This imply that the decoded image depends on the implementation of the
> decoder, because there is no standardized algorithm(or way) for
> decoding baseline JPEG files. Right?
You should see that the "JPEG decoding algorithm" consists of several
parts which are variably "standardized".
There consist several IDCT algorithms which may produce more or less
accurate results due to finite precision calculation.
The *theoretical* IDCT algorithm would require infinite precision
arithmetics and is thus not practical.
Similar arguments apply to the required YCbCr->RGB colorspace
transformation at the end of the decoding process.
The dequantization part is somehow specified in the standard, but
it is not necessary to follow it precisily. In fact, there exist
'recommendations' in the standard how to 'improve' the decoded
image quality ("display adapted decoding") by different
dequantization rules.
But I want to draw your attention particularly to another part of
the JPEG process which is often underrated: That is the color
subsampling feature! Many JPEG images in use today are color
subsampled, and they need to be upsampled when decoding! If you
consider the general resampling difficulty of digital images,
you will notice that there exist many quite different methods!
Not only the finite precision calculation accuracy is an issue
here, but the *algorithms* themselves are quite different and
produce different results even in infinite theory!
Unfortunately, the commonly used JPEG libraries today use
only suboptimal algorithms for the problem of color subsampling.
I have introduced a new method for this purpose which is
faster, better, and more appropriate for the JPEG process
than the suboptimal methods offered otherwise.
You will find some hints about this on my advanced JPEG pages
(http://jpegclub.org/djpeg/ and http://jpegclub.org/cjpeg/).
Regards
Guido
| |
| Flavius Vespasianus 2004-10-30, 3:55 am |
| gregrswartz@yahoo.com (Greg) wrote in news:78ba78f3.0410160504.75194fe4
@posting.google.com:
> Is it true that the image data for given JPEG (baseline) file depends
> on the used decoder, i.e. there is no unique image data?
JPEG is a lossy compresion mechanism and a JPEG decode makes a number of
choices that affect the output. It is unlikely two encoders will produce
the same output for the same input.
Sampling intervals
Quantization table selection
Restart intervals
In addition, there are diffent mechanisms for calculating the DCT. An
encoder that does it using floating point can be the most precise but it
will be slower than an integer implementation.
|
|
|
|
|