Re: Jpeg Encoder: YCC Clipping error
- From: techno <web@xxxxxxxxxxxxxxxxxxxx>
- Date: 27 May 2007 01:27:17 -0700
On May 26, 7:46 am, Jeff Vidal <jeffvi...@xxxxxxxxx> wrote:
Hello,
I'm a student and I have to write a Jpeg encoder using matlab.
I wrote it, for me it looks all good but the generated JPEG files are
wrong.
For instance, this is what I get:www.gvidal.fr/misc/out.jpg
The middle of the image seems good though...
I have used a tool called "JPEGsnoof" for analyzing my jpg file, and I
get some:
ERROR: YCC clipped
Can somebody see my Jpeg file and tell me, if possible, what is wrong
in my encoder code ?
This would be great.
I'm the author of the tool, "JPEGsnoop" ( http://www.impulseadventure.com/photo/jpeg-snoop.html
),
not "snoof"! :). When the JPEG image is decoded, the tool will write
this message if
it encounters a DC component that has exceeded the limits
(-1024..+1023)
after summing all of the deltas from prior MCUs.
In your example, the image is specified as having no chroma
subsampling, so the MCU
sequence should still be Y Cb Cr (or, more completely, Ydc Yac CBdc
CBac CRdc CRac Ydc Yac CBdc CBac...).
The error indicates that the second row of MCUs (X=0, Y=1) has an
underflow in the Y component.
Your huffman tables define the variable-length code for "0" or "End of
Block" as:
Y(dc) = 0
Y(ac) = 100
C(dc) = 0
C(ac) = 0
This makes it pretty easy to hand-decode your SOS (Start of Scan)
segment:
With no chroma subsampling, we would expect a "no-change" (no-delta)
MCU to be
represented by the bit-stream:
0 100 0 0 0 0
This fits nicely into one byte: 0x40
I can see that your encoded file does in fact repeat this byte (or bit-
shifted versions) for
much of the image content. In other words, it would imply that your
original image
had large sections of flat color / intensity. Is this correct? What
does your original
image look like in the top-left corner or top row? Of course you are
also using
quantization tables that would create very high compression, so these
flat sections
are going to be expected to a degree.
Since the DC components are calculated by keeping a running total
starting from
the top-left MCU, it is very easy to see how the cumulative value can
underflow
if something gets out of sync.
In particular, we would typically expect there to be some
discontinuities in the DC value at
the start of every row in the image. The fact that your underflow
occured at the start of
a row suggests that your encoder's bitstream is not getting out of
synch / corrupted --
there may be a different problem.
As cr88192 points out, there are many things that can go wrong with
the encoding.
The JPEG bitstream doesn't provide much redundancy or indicators that
help us
identify where things get out of synchronization, so starting from a
code / algorithm
examination may be a faster solution.
If you post a link to the original bitmap image, then it will be a lot
easier to figure
out what type of encoding problem you have.
Cal.
.
- Follow-Ups:
- Re: Jpeg Encoder: YCC Clipping error
- From: Jeff Vidal
- Re: Jpeg Encoder: YCC Clipping error
- References:
- Jpeg Encoder: YCC Clipping error
- From: Jeff Vidal
- Jpeg Encoder: YCC Clipping error
- Prev by Date: OT: RFC, PRNG
- Next by Date: Re: Any zip or tgz that decompress to itself ?
- Previous by thread: Re: Jpeg Encoder: YCC Clipping error
- Next by thread: Re: Jpeg Encoder: YCC Clipping error
- Index(es):
Relevant Pages
|
