Home > Archive > Compression > April 2006 > Generation of first context for a code block in JPEG2000 MQ-Decoder
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]
| Author |
Generation of first context for a code block in JPEG2000 MQ-Decoder
|
|
| Sharjeel 2006-04-18, 3:55 am |
| Hi,
When decoding the bitstream of JPEG2000 for a codeblock, what would
be the value of context for the first location in the code block? For
all the rest of the locations, we can estimate the context by the
updated values of sigma, eta or sigma_bar but for the very first
location, how can we do that? Assuming I am using the context values as
in JPEG2000 standard, then if I take the context to be zero (Zero
Coding) for the first location then there is always the possibility
that the bit was encoded by Run-Length Coding. In such a case, I would
not be able to generate the exact context as I did on the encoder.
Another thing I want to ask is about the MQ-Encoder. In the last step
of BYTEOUT procedure, the compressed image data pointer BP is
incremented by 1. Supposing that I am writing the output bytes in an
array, then in the last step of BYTEOUT (Bit-Stuffing/No Bitstuffing),
does increasing BP means that I should write the data in B to the
output array? I am a little  about it because in the INITENC
procedure, BP is initialized to BPST-1.
Regards,
Sharjeel Saeed
| |
| Thomas Richter 2006-04-18, 3:55 am |
| Hi,
> When decoding the bitstream of JPEG2000 for a codeblock, what would
> be the value of context for the first location in the code block?
Non-significant, non-refined. Thus, the initial context index is zero.
> For
> all the rest of the locations, we can estimate the context by the
> updated values of sigma, eta or sigma_bar but for the very first
> location, how can we do that? Assuming I am using the context values as
> in JPEG2000 standard, then if I take the context to be zero (Zero
> Coding) for the first location then there is always the possibility
> that the bit was encoded by Run-Length Coding.
Run length coding is performed if you have a column of four non-significant
coefficients, step D8 in figure D-3.
Thus, if you have a column of four coefficients (which you will always have
if your codeblock is taller than three coefficients) the initial column will
always be runlength coded, no matter what.
> In such a case, I would
> not be able to generate the exact context as I did on the encoder.
You are. Contexts are not updated in advance to coding. They are
updated after a coefficient has been encoded; that's the trick.
> Another thing I want to ask is about the MQ-Encoder. In the last step
> of BYTEOUT procedure, the compressed image data pointer BP is
> incremented by 1. Supposing that I am writing the output bytes in an
> array, then in the last step of BYTEOUT (Bit-Stuffing/No Bitstuffing),
> does increasing BP means that I should write the data in B to the
> output array? I am a little about it because in the INITENC
> procedure, BP is initialized to BPST-1.
Whether or how you write data is an implementation detail the standard
does not define. The standard defines writing MQ data "as if" you would
be writing into a memory array. If you do not, your implementation must
work on the basis of the "as-if" rule: It should generate exactly the
same data into the stream it should write into the memory buffer. In
the initENC part, the "B=FF" branch is never taken and, as I see it,
just a confusion. What *is* important, though, is that the B register
contains the last byte, and you need to fix it when overflows appear,
e.g. in the BYTEOUT procedure. BP is therefore a pointer to an array
of Bs, and the first B to be put into this array is at BP. Since B is
the "last byte", BP has to be initialized to point in front of the
buffer. What you can do is to write all those bytes out of which you
can prove that the algorithm does not change them anymore. And these
are, of course, all the bytes in front of BP.
So long,
Thomas
| |
| Sharjeel 2006-04-18, 9:55 pm |
| This BP thing is still a little unclear. Suppose that I want to start
writing the data at memory location 1, so I would initialize the BP
with 0. Now in the BYTEOUT procedure, BP is incremenetd by 1 (pointing
to the location where I want my data to be written) and right after
that, B would updated by a shifted value of C. Supposing that the data
in B before BP gets incremented, is XX. Then the data which is to be
written at memory location-1 should be XX or whatever changes we make
in B after incrementing BP till the next time BP is called, would be
written at location-1?
Regards,
Sharjeel Saeed
| |
| Thomas Richter 2006-04-19, 3:55 am |
| > This BP thing is still a little unclear.
B equals the byte pointed to by BP, i.e. b = *bp.
> Suppose that I want to start
> writing the data at memory location 1, so I would initialize the BP
> with 0.
Yes.
> Now in the BYTEOUT procedure, BP is incremenetd by 1 (pointing
> to the location where I want my data to be written) and right after
> that, B would updated by a shifted value of C. Supposing that the data
> in B before BP gets incremented, is XX. Then the data which is to be
> written at memory location-1 should be XX
Exactly, since *bp = b.
> or whatever changes we make
> in B after incrementing BP till the next time BP is called, would be
> written at location-1?
No. That will be written to the next memory location. Or, almost, since
this location can still be changed by the next byteout call since
there's one case where have a handle a carry-over from the next output
into the old output, b = b + 1. This case increments the memory location
pointed to by bp, and thus the output of the last call.
So long,
Thomas
|
|
|
|
|