Home > Archive > Compression > May 2005 > Fixed-Size JPEG2000
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 |
Fixed-Size JPEG2000
|
|
| Sharjeel 2005-05-16, 3:55 am |
| Hi,
In the JPEG2000 requirements and Profiles documents, it is mentioned
that it also supports fixed size/limited workspace memory. I could not
find any documents descirbing the details about it. Can someone refer
to some reading material (web or printed) or explain how it can be
achieved?
Regards,
Sharjeel Saeed
| |
| Gui Xie 2005-05-16, 3:55 am |
| The JPEG2000 image coder generates a distortion scalable coded bit-stream
that can be truncated into any size. Please refer to Taubman's book
"Jpeg2000: Image Compression Fundamentals, Standards, and Practice".
"Sharjeel" <sharjeel.saeed@gmail.com> ????
news:1116205344.784279.114810@g47g2000cwa.googlegroups.com...
> Hi,
> In the JPEG2000 requirements and Profiles documents, it is mentioned
> that it also supports fixed size/limited workspace memory. I could not
> find any documents descirbing the details about it. Can someone refer
> to some reading material (web or printed) or explain how it can be
> achieved?
> Regards,
> Sharjeel Saeed
>
| |
| Thomas Richter 2005-05-17, 8:55 am |
| Hi,
> In the JPEG2000 requirements and Profiles documents, it is mentioned
> that it also supports fixed size/limited workspace memory. I could not
> find any documents descirbing the details about it. Can someone refer
> to some reading material (web or printed) or explain how it can be
> achieved?
The basic idea is that you only encode a limited amount of data from
each codeblock. Thus, you build a wavelet transformer that performs
data transformation on the fly, push data into codeblocks and
encode up to a maximum output size for each codeblock, then write out
the data as soon as it is encoded. Since your backend now delivers
data as it is encoded, you need to define codestream parameters such
that the order of encoding fits well to the order in which codeblocks
have to appear in the output stream. For most encoder architectures,
this would be a progression order with "position" as "slowest variable".
In a typical application, you would then only need to buffer:
a) The wavelet overlap, i.e. the lenght of the support of the
wavelet filter, in lines.
b) Enough lines to build up one line of codeblocks.
c) One codeblock plus states for the EBCOT coder.
d) Output memory for the EBCOT. You can also limit this because
you can truncate the EBCOT output due to the "embedded" nature of
the code.
So long,
Thomas
|
|
|
|
|