Blocking artifacts in JPEG
Arun Kumar
Why blocking artifacts occur in JPEG compressed imaged because of
DCT 8x8 pixel grouping ? how it is overcome by Wavelet method?
I need a detailed notes on this. plz help me.
smsabu
No Claim Bonus
some data compression text books also give an explanation
Arun Kumar <smsab...@yahoo.com> wrote in article
<84afc8e.03012...@posting.google.com>...
Jack Berlin
Yes, because of the 8x8 blocks. However, there are succesful means of
building decoders that erase some of this effect. Pegasus JPEG viewers
remove many of these artifacts without blurring. Vastly overcompress an
image and view in different viewers, including one of ours. This will show
interesting differences between JPEG decoders.
This is our test viewer for Windows: ftp://jpg.com/MINERVA.EXE 1MB
Or you could use our commercial JPEG Wizard(tm) product.
Hope this helps,
jack
--
The JPEG Wizard free web compression testing: http://www.jpegwizard.com/
--
http://www.jpg.com/ - Pegasus - The BETTER JPEG People!
Photo slideshow creator: http://www.pegasusimaging.com/picshow.htm
--
"Arun Kumar" <smsab...@yahoo.com> wrote in message
news:84afc8e.03012...@posting.google.com...
Thomas Richter
> Hello,
> Why blocking artifacts occur in JPEG compressed imaged because of
> DCT 8x8 pixel grouping ?
If the compression is very high, all that remains of an 8x8 block is the
low pass, meaning its average color, leading to blocking.
> how it is overcome by Wavelet method?
Wavelet codecs (e.g. jpeg2000) don't cut images into blocks in the visual
image domain. Rather, they wavelet transform them before cutting them in blocks,
giving each individual block ("codeblock") less data to represent, and the
data it represents does not cover a simple rectangular region in the image
domain. Rather, a block in the wavelet domain can be thought of a "smeared"
block in the image domain, giving you an effective anti-blocking more or less
for free, with the wavelet filters acting as de-blocking filter.
Some jpeg-decoders provide smart code to detect this blocking case in traditional
jpeg and provide suitable filtering to reduce these artefacts. See Jack's post
below.
Greetings,
Thomas
No Spam
Why not tell us what ***you*** think ? Where have you looked for
information so far ? What have you found ?
Why does this sound like you are looking for people to do your homework or
exam ?
Phil Carmody
> Hi,
>
> Yes, because of the 8x8 blocks. However, there are succesful means of
> building decoders that erase some of this effect. Pegasus JPEG viewers
> remove many of these artifacts without blurring. Vastly overcompress an
> image and view in different viewers, including one of ours. This will show
> interesting differences between JPEG decoders.
Define "blurring", please.
If what you mean by blurring is what I think you mean, then your claim is
mathematically impossible, surely.
Phil
Jack Berlin
Our 'claim' is that our JPEG decoder is removing the artifacts by doing a
better job of 'interpreting' the compressed JPEG data and actually yielding
an image from *any* JPEG file that is 'closer' to the original image than
what comes from other JPEG decoders. So, not by filtering or smoothing.
Deblocking is a byproduct of this better accuracy.
Very easy to check for yourself. Define your own little experiment and test
my claim by 'over compressing' a JPEG (or not, but the results will be
easier to measure with a overcompressed image), decoding the image with a
Pegasus JPEG decoder and one or more others, and measure errors in some sort
of subtraction scheme, and compare. Then let us all know. And, blurring
will not occur, as I said, as blurring or smoothing destroys the results of
subtraction comparisons.
Not mathematically impossible, just mathematically very clever. Pegasus
actually knows how to make more improvement still, but this is the subject
of a patent filing and not demonstrable yet, but soon.
Hope this helps. Please let me know if you have any further questions.
Best wishes,
jack
--
The JPEG Wizard free web compression testing: http://www.jpegwizard.com/
--
http://www.pegasusimaging.com/ - Pegasus - The BETTER JPEG People!
--
"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
news:pan.2003.01.27....@yahoo.co.uk...
Simon F
> Well...
>
>
>
> Not mathematically impossible, just mathematically very clever. Pegasus
> actually knows how to make more improvement still, but this is the subject
> of a patent filing and not demonstrable yet, but soon.
Out of curiousity, is the process similar to the MPEG4 deblocking (and
deringing) processes?
Simon
Phil Carmody
> Well...
>
> Our 'claim' is that our JPEG decoder is removing the artifacts by doing a
> better job of 'interpreting' the compressed JPEG data and actually yielding
> an image from *any* JPEG file that is 'closer' to the original image than
> what comes from other JPEG decoders. So, not by filtering or smoothing.
> Deblocking is a byproduct of this better accuracy.
Auto-scare-quoting, that's reassuring. Any words but 'blurring', eh?
An avoidance of the direct request for a definition of blurring too.
Curious - I ask you to be more precise with terminology and your response
is to come back scare-quoted and wishy-washy waffle.
I'm underwelmed.
> Very easy to check for yourself. Define your own little experiment and test
One doesn't need experiments to verify or disprove mathematical
principles. Pure mathematics is not an experimental science.
> my claim by 'over compressing' a JPEG (or not, but the results will be
> easier to measure with a overcompressed image), decoding the image with a
> Pegasus JPEG decoder and one or more others, and measure errors in some sort
> of subtraction scheme, and compare. Then let us all know. And, blurring
> will not occur, as I said, as blurring or smoothing destroys the results of
> subtraction comparisons.
Mathematically impossible. The counting argument (pigeon-hole principle)
says so. There are many images that compress to the same JPEG file. You
chose to decode it one way, other decoders chose to decode it another way.
How do you know that you're always right, and they're always wrong?
You can say that you are _more likely_ to chose something closer to the
original image based on your assumptions about what the original image was
_likely_ to be, but you _cannot_ make the claim that you will always
restore an image more faithfully than other compressors.
Let S be a source image, a quality scan of a photo of a real-life scene, say.
Let C be a highly-lossily compressed JPEG of S.
Throw S away. Pretend it doesn't exist, and never existed.
Let I be a cheap JPEG decompress of L.
Throw C away, likewise.
Now from I compress, using the cheap encoder, using the same quantisation as before, to the JPEG C2
Then give C2 to both your decoder and the cheap decoder.
I posit, from what you've claimed, that your software will try to decode
to something approximating S. However, S doesn't exist. The image file
that was compressed was the intermediate I, not S. To decompress to appear
more like S is an error, as the source image to the compression was unarguably
I.
> Not mathematically impossible, just mathematically very clever. Pegasus
> actually knows how to make more improvement still, but this is the subject
> of a patent filing and not demonstrable yet, but soon.
I've seen more H.261 deblocking than I'd care to report. Your descriptions
sound no cleverer than some of the things I've seen the DSP engineers
where I've worked come up with.
None of them made claims of mathematically impossible things either.
> Hope this helps. Please let me know if you have any further questions.
Why do you top-post?
Phil
Martin Brown
Phil Carmody wrote:
> On Tue, 28 Jan 2003 19:25:37 +0000, Jack Berlin wrote:
> > Well...
> >
> > Our 'claim' is that our JPEG decoder is removing the artifacts by doing a
> > better job of 'interpreting' the compressed JPEG data and actually yielding
> > an image from *any* JPEG file that is 'closer' to the original image than
> > what comes from other JPEG decoders. So, not by filtering or smoothing.
> > Deblocking is a byproduct of this better accuracy.
>
> Auto-scare-quoting, that's reassuring. Any words but 'blurring', eh?
> An avoidance of the direct request for a definition of blurring too.
> Curious - I ask you to be more precise with terminology and your response
> is to come back scare-quoted and wishy-washy waffle.
You seem excessively dismissive of his claims - without bothering to try it.
> > Very easy to check for yourself. Define your own little experiment and test
>
> One doesn't need experiments to verify or disprove mathematical
> principles. Pure mathematics is not an experimental science.
Indeed and there are good reasons to believe that the fast classical simple JPEG inverse is by no means
the highest fidelity way to reconstruct an image from its saved coefficients. The catch is that most of
the methods with greater finesse take a signficantly longer time to compute.
> > my claim by 'over compressing' a JPEG (or not, but the results will be
> > easier to measure with a overcompressed image), decoding the image with a
> > Pegasus JPEG decoder and one or more others, and measure errors in some sort
> > of subtraction scheme, and compare. Then let us all know. And, blurring
> > will not occur, as I said, as blurring or smoothing destroys the results of
> > subtraction comparisons.
>
> Mathematically impossible. The counting argument (pigeon-hole principle)
> says so. There are many images that compress to the same JPEG file. You
> chose to decode it one way, other decoders chose to decode it another way.
> How do you know that you're always right, and they're always wrong?
>
> You can say that you are _more likely_ to chose something closer to the
> original image based on your assumptions about what the original image was
> _likely_ to be, but you _cannot_ make the claim that you will always
> restore an image more faithfully than other compressors.
Actually I think you can bound it. And any decent pseudo inverse method should never be worse.
You can certainly reconstruct an image which when re-encoded with the quantisation table belonging to
the raw JPEG will generate the same set of coefficients (give or take a tiny amount of rounding error).
> Let S be a source image, a quality scan of a photo of a real-life scene, say.
> Let C be a highly-lossily compressed JPEG of S.
> Throw S away. Pretend it doesn't exist, and never existed.
> Let I be a cheap JPEG decompress of L.
> Throw C away, likewise.
> Now from I compress, using the cheap encoder, using the same quantisation as before, to the JPEG C2
> Then give C2 to both your decoder and the cheap decoder.
>
> I posit, from what you've claimed, that your software will try to decode
> to something approximating S. However, S doesn't exist. The image file
> that was compressed was the intermediate I, not S. To decompress to appear
> more like S is an error, as the source image to the compression was unarguably I.
If they are doing what I think they are doing (and it is a reasonably smart move).
Solve a constrained least squares problem to find the maximum entropy (or other handy regularising
function) image consistent with the supplied JPEG coefficients and the quantisation tables.
In general such an approach will usually get closer to the input to the JPEG codec and will never be
worse. If I understand their claim the enhanced reconstruction will look closer to the intermediate
"I".
But why bother arguing about it. Why don't you generate a sample test case image and perform the
experiment instead of sounding off about why it won't work?
> > Not mathematically impossible, just mathematically very clever. Pegasus
> > actually knows how to make more improvement still, but this is the subject
> > of a patent filing and not demonstrable yet, but soon.
>
> I've seen more H.261 deblocking than I'd care to report. Your descriptions
> sound no cleverer than some of the things I've seen the DSP engineers
> where I've worked come up with.
>
> None of them made claims of mathematically impossible things either.
He hasn't made any mathematically impossible claims.
They may also use some other continuity heuristics at the block boundaries.
Regards,
Martin Brown
Phil Carmody
>> None of them made claims of mathematically impossible things either.
>
> He hasn't made any mathematically impossible claims.
If there exist images A and B such that with a chosen arbitrary encoder
JPEG(A) == JPEG(B) = C, then if pegasus thinks that JPEG^-1(C) == A,
I'll chose B as my source image. Any other decoder that yields B has
performed a more faithful reconstruction of my chosen image. He's asserted
that there can not exist such a decoder. There can - here's the
pseudo-code:
if(compressed data is C)
return image B;
else
return something else.
If there don't exist such images, A and B, then JPEG isn't lossy, and
we'll all need to take shelter from pigs on the wing.
I don't care if he maximised entropy, or maximises bogosity, this is just
a simple counting argument.
Phil
Reading in comp.compression
Thomas Richter
Hi,
>> He hasn't made any mathematically impossible claims.
> If there exist images A and B such that with a chosen arbitrary encoder
> JPEG(A) == JPEG(B) = C, then if pegasus thinks that JPEG^-1(C) == A,
> I'll chose B as my source image. Any other decoder that yields B has
> performed a more faithful reconstruction of my chosen image. He's asserted
> that there can not exist such a decoder. There can - here's the
> pseudo-code:
> if(compressed data is C)
> return image B;
> else
> return something else.
> If there don't exist such images, A and B, then JPEG isn't lossy, and
> we'll all need to take shelter from pigs on the wing.
> I don't care if he maximised entropy, or maximises bogosity, this is just
> a simple counting argument.
I'm very sorry, but I cannot agree. Phil, we're here performing lossy
compression. Something has to go on compressing the image in JPEG, and
this "something" has to be choosen carefully to keep it as "less visible"
as possible to get a visually appealing image after reconstruction. Now,
"visually appealing" is of course very subjective, but I guess we agree
that "images with blocks" are a) not even less visually appealing, what-
ever that means in mathematical terms, and b) relatively unlikely in an
image class we could define as "natural". Hence, a decoder can, of course,
imply guesses how an "overcompressed" image might have looked like before
compression: Namely, by guessing --- and it is really that, in
mathematical terms --- that the original image must have been of the
natural image class.
Hence, we get an image of better quality, and of an expected (!) image
quality (e.g. measured in PSNR) that is higher than the expected image
quality of a "non-trickery" decoder. This is because the probability
distribution we have to integrate against has high value for images without
blocks, and low values with images with blocks: This is the "probability
measure of typical natural images".
In this sense, Jack's claim makes perfect sense, and is neither
mathematically impossible. Nobody claimed that Pegasus can decompress
images from data that is not available, but rather, it is better at
guessing how the data might have looked like for a typical class of
images. Or in still another word, the counting argument does not apply
for lossy compression if you imply pre-knowledge of the probability
distribution of the data sets you want to compress, and you measure
image quality as the expectation against this measure.
Greetings,
Thomas
Marco Al
> "Jack Berlin" <jbe...@jpg.com> wrote in message
>> Not mathematically impossible, just mathematically very clever.
Pegasus
>> actually knows how to make more improvement still, but this is the
subject
>> of a patent filing and not demonstrable yet, but soon.
>
> Out of curiousity, is the process similar to the MPEG4 deblocking (and
> deringing) processes?
Hey Simon, I doubt he is going to tell you much ... Im guessing it is
closer to the method described in "Blocking Artifact Detection and
Reduction in Compressed Data". Or maybe POCS, in image decompression you
have the time to make sure coefficients respect their quantization
intervals so MPEG4 post-processing isnt very appropriate.
Marco
Phil Carmody
>
> Hi,
>
>>> He hasn't made any mathematically impossible claims.
>
>> If there exist images A and B such that with a chosen arbitrary encoder
>> JPEG(A) == JPEG(B) = C, then if pegasus thinks that JPEG^-1(C) == A,
>> I'll chose B as my source image. Any other decoder that yields B has
>> performed a more faithful reconstruction of my chosen image. He's asserted
>> that there can not exist such a decoder. There can - here's the
>> pseudo-code:
>
>> if(compressed data is C)
>> return image B;
>> else
>> return something else.
>
>
>> If there don't exist such images, A and B, then JPEG isn't lossy, and
>> we'll all need to take shelter from pigs on the wing.
>
>> I don't care if he maximised entropy, or maximises bogosity, this is just
>> a simple counting argument.
>
> I'm very sorry, but I cannot agree. Phil, we're here performing lossy
> compression.
That's my point!
...
> guessing how the data might have looked like for a typical class of
> images.
That's my point!
> Or in still another word, the counting argument does not apply
> for lossy compression if you imply pre-knowledge of the probability
> distribution of the data sets you want to compress, and you measure
> image quality as the expectation against this measure.
However, there are (2^24)^64 possible RGB 8x8 blocks whether Jack
likes it or not, and for him to assert that every single one will be
reconstructed more faithfully with his software than with other software
is mathematically impossible.
And that was his claim - look at Jacks original post. The words are in
black and white - he even uses *emphasis* to indicate the absoluteness
of his claim. Remember - I get to chose the source image. Therefore I
have a choice from (2^24)^64 blocks. If he didn't want me to have that
choice, he should not have offered it to me.
If he'd have said:
"Our software provides more faithful reconstruction of 0.0000001% of all
possible images, and to be honest we don't care about the other 99.9999999%
of the images, as you're never likely to encounter them".
Then I would not have taken issue with him. Of course, he could have used
a slightly more flattering wording, but do you get my point?
Yes, it's pedantry, but hey, this is comp.compression, and it can get a
lot more pedantic than this.
On top of that it's very hard to argue against someone who, when asked for
a clarification of a term in an argument, replies with even more less well
defined terms. I've _done_ the solution that Martin mentioned in order to
focus cameras, I can take tech talk far better than I can take fluff.
Phil
Tom Clune
>...
> compression. Something has to go on compressing the image in JPEG, and
> this "something" has to be choosen carefully to keep it as "less visible"
> Hence, a decoder can, of course,
> imply guesses how an "overcompressed" image might have looked like before
> compression: Namely, by guessing --- and it is really that, in
> mathematical terms --- that the original image must have been of the
> natural image class.
>
> Hence, we get an image of better quality, and of an expected (!) image
> quality (e.g. measured in PSNR) that is higher than the expected image
> quality of a "non-trickery" decoder.
PMFJI, but I believe that this argument may be largely semantic. For
JPEG encoding, you can make improvements on the image quality for a
given size of compresssion by selecting your quantization tables or
choosing how to generate your Huffman tables. However, for conformant
decoding, all you can do is reconstruct the encoded lossy image.
Anything that does otherwise is non-conformant. In general, "broken"
is a synonym for "noncomformant" here.
However, you may create a viewer for JPEG images that would also apply
intelligent enhancements, either to correct for blockiness of
overcompressed iamges or for some other goal. Such a viewer is not
nonconforming, it is a product that is outside the scope of the JPEG
standard.
It appears that Phil is taking issue with the idea that the decoder
can be "better" or "worse" -- it simply conforms or it doesn't.
However, the image that the viewer displays may involve some
"extra-standard" processing, and may even be seen as preferable to
images that are not so processed in some contexts.
FWIW
--Tom Clune
Alexander Belov
random points which mean nothing for eye. I think that for random set of
points any deblocking algorithm will not work and it is not required
because the eye cannot see block bounds between two random squares.
The natural image can be considered as a smooth 2D function and this is
serious limitation on class of images. Thus like in DAC reconstruction
the device reconstructs smooth bandlimited voltage function of time, the
same process can be invented to correct pixel color to reconstruct
smooth 2D function with smooth bounds between squares that can be
coded to compressed image (or overcompressed).
Due to high loss of precision we cannot get close to original image but
we can get more natural image. So the more information we lose
the more natural images can be compressed to our JPEG.
So decompression method just defines which smooth 2D functions it
prefers.
"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
news:pan.2003.01.29...@yahoo.co.uk...
Phil Carmody
> It appears that Phil is taking issue with the idea that the decoder
> can be "better" or "worse" -- it simply conforms or it doesn't.
> However, the image that the viewer displays may involve some
> "extra-standard" processing, and may even be seen as preferable to
> images that are not so processed in some contexts.
That's not actually my point. It's an interesting one though. The errors
that are possible in low-precision FFTs might make it hard to measure
conformancy, if the standards permit these small differences. Even the
FPU's rounding settings can give you different results. If the standards
do specify a standard against which the transforms can be compared, then
I wonder what Kahan would say about that (given his comments on Java).
My point is that Jack is very sloppy with his words, relying more on
rhetoric than clearly defined accepted terminology. And *misplaced* emphasis.
Phil
Martin Brown
Phil Carmody wrote:
> On Wed, 29 Jan 2003 13:53:50 +0000, Martin Brown wrote:
> >> None of them made claims of mathematically impossible things either.
> >
> > He hasn't made any mathematically impossible claims.
>
> If there exist images A and B such that with a chosen arbitrary encoder
> JPEG(A) == JPEG(B) = C, then if pegasus thinks that JPEG^-1(C) == A,
> I'll chose B as my source image. Any other decoder that yields B has
> performed a more faithful reconstruction of my chosen image.
The main problem for your argument is that for most images knowing that
JPEG(A) == JPEG(B) = C
Does not imply that applying JPEG^-1(C) returns either A or B
Very often in practice JPEG^-1(C) contains values < 0 and >255 which are then
topped and tailed.
Due to the quantisation errors (and to a much lesser extent DCT rounding
errors) it is widely known that in most circumstances repeated JPEG
compression has small generational losses because the classical pseudo
inverse is imperfect when applied directly to the quantised coefficients.
Decoding and re-encoding do not get you back to where you started.
JPEG( JPEG^-1(C)) <> C
However, if instead you determine the set of images, {I}, for which
JPEG({I}) = C (using identical quantisation tables)
And then choose a suitable representative from this set of images that are
consistent with your JPEG coefficient data. The result can be much closer to
the original target than any classical inverse because it is able to
explicitly make use of prior information you have about the target image.
Choose wisely by using additional heuristics about real photographic images
and you can do even better.
> He's asserted that there can not exist such a decoder. There can - here's
> the
> pseudo-code:
>
> if(compressed data is C)
> return image B;
> else
> return something else.
>
> If there don't exist such images, A and B, then JPEG isn't lossy, and
> we'll all need to take shelter from pigs on the wing.
Certainly you can do that, but it has no bearing on the problem in hand.
> I don't care if he maximised entropy, or maximises bogosity, this is just
> a simple counting argument.
A simple counting argument misapplied.
I am well aware that there is a huge multiplicity of possible images that are
consistent with any given set of JPEG data, but most times the result of the
classical JPEG pseudo inverse is *not* one of them.
Classical JPEG^-1( ) has some limitations that other pseudo inverses do not
share.
A simple example where JPEG will drift off nicely is a single white pixel
value 255 in an 8x8 square of 0's. JPEG encode that quantised with the default
Y tables from the JPEG std and see what you get back.
Regards,
Martin Brown
Tom Clune
> On Wed, 29 Jan 2003 10:49:41 +0000, Tom Clune wrote:
> > It appears that Phil is taking issue with the idea that the decoder
> > can be "better" or "worse" -- it simply conforms or it doesn't.
> > However, the image that the viewer displays may involve some
> > "extra-standard" processing, and may even be seen as preferable to
> > images that are not so processed in some contexts.
>
> That's not actually my point. It's an interesting one though. The errors
> that are possible in low-precision FFTs might make it hard to measure
> conformancy, if the standards permit these small differences. Even the
> FPU's rounding settings can give you different results. If the standards
> do specify a standard against which the transforms can be compared, then
> I wonder what Kahan would say about that (given his comments on Java).
>
Sorry to have misconstrued your intent. There is, indeed, such a
standard -- ISO DIS 10918-2 is specifically devoted to compliance
testing of exactly this sort. My recollection is that you could also
get a disk of known data to go with the conformance testing. FWIW
--Tom Clune
Dave Martindale
>My point is that Jack is very sloppy with his words, relying more on
>rhetoric than clearly defined accepted terminology. And *misplaced* emphasis.
It's also worth noting that this thread is crossposted to three
newsgroups. While comp.compression readers and contributors may be used
to a particular set of "clearly defined accepted terminology" when
discussing JPEG compression, things may not be so clearcut in comp.dsp
and sci.image.processing.
For example, image processing is primarily concerned with source images
that might actually be acquired from some real sensor, not all possible
source images including completely random ones. Words have different
meanings depending on whether the context is "all possible source
images" or "almost all real-world images".
Dave
Martin Brown
Tom Clune wrote:
> Thomas Richter <th...@cleopatra.math.tu-berlin.de> wrote in message news:<b18tkd$1in$1...@mamenchi.zrz.TU-Berlin.DE>...
> >...
> > I'm very sorry, but I cannot agree. Phil, we're here performing lossy
> > compression. Something has to go on compressing the image in JPEG, and
> > this "something" has to be choosen carefully to keep it as "less visible"
> > as possible to get a visually appealing image after reconstruction. ...
I am not talking about guessing here (although I am sure that heuristics about real images do work).
JPEG can be recast as an inference problem and then solved by finding an image which when JPEG encoded gives a closer
fit to the supplied JPEG coefficients of the unknown compressed image.
> PMFJI, but I believe that this argument may be largely semantic. For
> JPEG encoding, you can make improvements on the image quality for a
> given size of compresssion by selecting your quantization tables or
> choosing how to generate your Huffman tables. However, for conformant
> decoding, all you can do is reconstruct the encoded lossy image.
I agree. But the classical JPEG inverse normally used for this purpose does not obtain a precise solution to the stated
problem. If it did you would not see generational losses with decode and recompress cycles.
(for some lucky patterns and quantisation tables the coefficients do settle on a stable attractor)
But in a fair proportion of cases the stored quantised JPEG coefficients are inconsistent with *any* image.
> Anything that does otherwise is non-conformant. In general, "broken"
> is a synonym for "noncomformant" here.
Once you start putting in arbitrary heuristics then I agree. Even if such things as penalising block edge
discontinuities can help to improve the cosmetic appearance.
Where we differ is that I see nothing wrong with using all the information available including:
1. There was once an image which when compressed by JPEG gave these data.
2. The image contained values in a fixed positive range 0..255, or 0..4095
Your preferred linear reconstruction although very fast quietly sweeps under the carpet any reconstructed pixel values
that are outside the valid range. That isn't a nice thing to do.
> However, you may create a viewer for JPEG images that would also apply
> intelligent enhancements, either to correct for blockiness of
> overcompressed iamges or for some other goal. Such a viewer is not
> nonconforming, it is a product that is outside the scope of the JPEG standard.
>
> It appears that Phil is taking issue with the idea that the decoder
> can be "better" or "worse" -- it simply conforms or it doesn't.
The decoders that you say "conform" were designed to be quick to compute in the old days when JPEG required hardware
acceleration. They have two distinct weaknesses:
1. Reconstructions include values outside the range of the source image (that are then truncated).
2. Decompressing and then recompressing using the same tables is inexact.
The classical pseudo inverse is very quick to compute but it is not self consistent with the JPEG coefficient data used
to produce it. There is hard a priori information available that can be used to infer a more nearly correct solution to
the inverse problem. Using this makes for a better JPEG image reconstruction.
And I am using better here in the *strict* sense that it more closely represents an accurate representation of the
gamut of possible images that could have produced the coefficients in the JPEG file.
I don't see how you can realistically claim that the reconstruction method described in the standard is "the one true
way" when it manifestly loses something in the round trip JPEG=>image=>JPEG.
Regards,
Martin Brown
Tom Clune
>
> > Anything that does otherwise is non-conformant. In general, "broken"
> > is a synonym for "noncomformant" here.
>
> Once you start putting in arbitrary heuristics then I agree. Even if such things as penalising block edge
> discontinuities can help to improve the cosmetic appearance.
>
> Where we differ is that I see nothing wrong with using all the information available including:
> 1. There was once an image which when compressed by JPEG gave these data.
> 2. The image contained values in a fixed positive range 0..255, or 0..4095
>
> ...
> The decoders that you say "conform" were designed to be quick to compute in the old days when JPEG required hardware
> acceleration. They have two distinct weaknesses:
>
> 1. Reconstructions include values outside the range of the source image (that are then truncated).
> 2. Decompressing and then recompressing using the same tables is inexact.
>
> The classical pseudo inverse is very quick to compute but it is not self consistent with the JPEG coefficient data used
> to produce it. There is hard a priori information available that can be used to infer a more nearly correct solution to
> the inverse problem. Using this makes for a better JPEG image reconstruction.
>
> And I am using better here in the *strict* sense that it more closely represents an accurate representation of the
> gamut of possible images that could have produced the coefficients in the JPEG file.
>
> I don't see how you can realistically claim that the reconstruction method described in the standard is "the one true
> way" when it manifestly loses something in the round trip JPEG=>image=>JPEG.
I understand your point. However, I work in a somewhat different world
than you probably do. My field is medical instrumentation. When we
develop an instrument, a standard is good in and of itself. The reason
is that JPEG has been exhaustively studied, including with a wide
variety of ROC studies over a wide variety of medical images by a wide
variety of physicians, and is a known quantity. A new approach may be
an improvement in some contexts. It may be an improvemet in all
contexts. It may be an improvement in no context that we care about.
In any of these cases, establishing the truth is a long and costly
process. If you are working with snapshots of your Aunt Tillie,
whatever you think looks good IS good. In medicine, you are concerned
with the efficacy of the clinical information in the data set. That is
established by people other than me. Indeed, something that seems
better for one doctor may not be an improvement for another. In
medical imaging, it is not a trivial thing to obscure the blocky
artifacts of JPEG. You have NOT reconstructed the true clinical
reality, you have just hidden the fact that you have lost it. This is
a big and BAD deal in this context.
[side bar: I once worked for many months creating a complex image
processing product that lessoned the noise in nuclear medicine images.
We developed the routines with physicians and then field tested them
with a variety of other physicians. Once we were feeling good about
ourselves, we ran the "improvement" by one of the foremost nuclear
medicine diagnosticians in the world. It took him about two seconds to
tell us to get that crap off his images. For a man of his
sophistication, he could see everything that we had extracted from the
image without our help. In addition, the amount of noise that he had
to see through provided him with an important calibrator of how
seriously to take the structures that he was seeing. The moral of the
story is that image quality is not an abstract notion, it is tied to
the use of the image and the user of the image.]
One important virtue of the CCITT T.83 test suite for conformance (and
no, _I_ don't say it conforms -- the standards committee says it
conforms if it meets the stated test criteria) is that I can say with
confidence that I am doing what I believe that I am doing in my code,
that I have successfully created a product that is subject to all the
known constraints of a particular JPEG process.
I do not suggest that conforming to the standard is "the one true
way." I DO, however, suggest that breaking the standard and claiming
to be JPEG is misleading. There are disciplines in the world for which
standards are meaningful. Call the new, improved,
I'm-not-telling-you-what-I-do thing KPEG if you like. But it is not
JPEG.
I don't think that we have an argument here -- we just work under
different constraints. I thought you might find mine of some interest.
FWIW
--Tom Clune
Jack Berlin
Thanks to all for the thoughtful discussion. Some excellent points have
been made and this seems a perfect type of discussion for this group. I'm
not a scientist so certainly my language may have been scientifically
imprecise, but it's equally obvious from the thread that I've successfully
communicated my points. For my part I should have been more careful and
less general in my posting.
From the Pegasus science staff:
"Strictly, if somewhat narrowly, I can appreciate his perspective. As
noted, for a given lossy compressed image, the number of possible input
images is huge. And there is no a priori reason to select one of those
possible images over another as the correct output image. Without
additional information about the source of the image, each possible input
image is equally likely. But these statements don't help us improve the
probability that the decompressed output image is closer to the actual input
image. As one example, for the vast majority of real-world images,
smoothing in such a way that block boundaries are de-emphasized, but so the
output image remains in the set of possible input images, has a high
probability of improving the quality of the output image, as measured by its
overall closeness to the actual input image, along with a low probability of
smoothing away some edge detail at some block boundaries. This makes it
sound like this smoothing may not be the correct choice for all images.
That's certainly true, but neither is not smoothing unless additional
information is available about the source of the image. The point is,
without this additional information, not smoothing just chooses a different
output image but with less empiricism behind the choice. You can't avoid
having to choose"
Hope this helps,
jack
--
http://www.pegasusimaging.com/ - Pegasus - BETTER DIGITAL IMAGING!
--
"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
news:pan.2003.01.29...@yahoo.co.uk...
lakshmi
> DCT 8x8 pixel grouping ? how it is overcome by Wavelet method?
> I need a detailed notes on this. plz help me.
hi
jpeg compression using dct has blocking artifacts because it does not
take into account the correlation between the 8 x8 blocked pixels and
try to remove the interpixel redundancies between the 8 x8 blocks so
wavelet was switched over which transformed the entire image to
wavelet form and does not subdivide
regards
lakshmi