JPEG2000:what is a "tile part"

Hi all!
I didn't understand what is a tile part in the JPEG2000 compression
standard. I studied the standard documents, but I really didn't find
the difference between "tile" and "tile-part".
Can someone help me?
Thanks in advance.

--
Catania (Sicilia)
Estate:max 45 C, Inverno: min:0 C
----------------------------------------------------------
"The best time to make friends is before you
need them."
Ethel Barrymore
--------------------------------------------
http://mattiafabiani.altervista.org/

Inviato da www.mynewsgate.net

Hi,

> I didn't understand what is a tile part in the JPEG2000 compression
> standard. I studied the standard documents, but I really didn't find
> the difference between "tile" and "tile-part".
> Can someone help me?

Well, the JPEG2000 ISO-standard is written in a rather
non-understandable way, I afraid, so the question is really very
natural. (-;

A tile-part is not a geometrical object like a tile or a precinct
or a codeblock. It is rather a part of the data a tile contributes
to the final compressed codestream. Tile encoding can be "interleaved"
in the sense that in the middle of the currently encoded tile, encoding
is aborted, and encoding goes on with a second tile. You could encode
only the first layer of the first tile, then advance to the next tile,
encode only its first layer, then to next, and so on. When the first
layer of the last tile has been encoded, the loop could continue with
the second layer of the first tile, then the second layer of the second
tile, etc... to get a progression by quality even though tiles are enabled.

If a progression as the above is used, then the convention is that
"the first layer of the first tile" is a "tile part", and this part is
encoded with its own SOT/SOD marker(s). Though tile-parts are not limited
to interrupt tile encoding at layer boundaries. The truncation points
are in fact arbitrary - you could stop encoding the tile right in the
middle of somewhere and make that a "tile part", too.

Thus, a "tile part" is an encoder/decoder concept very much like "layer"
is; it is a collection of data belonging to a tile and encoding a part
of it. All tile-parts of a tile thus form a codestream that would build
up this tile completely.

So long,
Thomas

> Well, the JPEG2000 ISO-standard is written in a rather
> non-understandable way, I afraid, so the question is really very
> natural.
It's really true :-(
> A tile-part is not a geometrical object like a tile or a precinct
> or a codeblock.
Now I understood what is a tiel part, but I'm afraid to need a further
help: Is a precinct a geometric object? I thinks that divsion  of
resolutions into precincts is a virtual concept. Cold you explain my
this concept? What is a precinct in spacial terms of images?
Thanks again in advance.

Hi,
 

> Now I understood what is a tiel part, but I'm afraid to need a further
> help: Is a precinct a geometric object? I thinks that divsion  of
> resolutions into precincts is a virtual concept. Cold you explain my
> this concept? What is a precinct in spacial terms of images?
> Thanks again in advance.

A precinct is very much a geometric object (though possibly with
a "fuzzy boundary"); it contains coefficients in a rectangular region
in a specific resolution level in the wavelet tree. Thus, if you would
render this resolution level as a downscaled version of the original
image, all "pixels" within the precinct would appear in the highest
possible resolution. If then rendered in the final (highest) resolution
level, the precinct gets a fuzzy/smoothed boundary due to the size of the
wavelet. In other words, precincts are like tiles, just in the wavelet
domain (and typically much better suited to generate progression in
the spacial domain than tiles since they don't cause artifacts at
their boundaries, unlike tiles).

Thus, you can understand a precinct as a "rectangle" in a given
resolution level. Since this resolution level consists of an
LL,HL,LH and HH band, and since the LL band is reconstructed from the
next lower resolution level, the precinct is actually only defined by
the coefficients within the 'high-passes' HL,LH and HH. There
is no ISO-defined name for these sub-sets, but I call them
"precinct-parts".

The only (obvious) exception is that of resolution level zero,
consisting of an LL band, and nothing else.

Thus, one resolution level = many precincts. One precint = three
precinct parts (non-zero level) or one precinct-part
(resolution zero), and one precinct = a rectangle in the given
resolution.

So long,
Thomas

Uhm...So, let me try to explain what I understood. Each tile (suppose
considering just one color component) is DWT transformed, so it's
partitioned into subbands and resolutions levels.Each resolution is
also partitioned into precincts, that are rectangular blocks of
coefficients. Moreover, the subbands are partitioned into code-blocks,
too. The size of codeblocks is less or eqiual to the size of
precincts. I wonder: why we need one more partitioning? code blocks
xould be have the same role of precincts, isn't it? Why precincts are
needed? Just to make the standard more complicated?!-(
Thank you!

Hi,

> Uhm...So, let me try to explain what I understood. Each tile (suppose
> considering just one color component) is DWT transformed, so it's
> partitioned into subbands and resolutions levels.

Right. The proper name for these are "tile components", thus: One tile =
several tile components.

> Each resolution is
> also partitioned into precincts, that are rectangular blocks of
> coefficients.

Right.

> Moreover, the subbands are partitioned into code-blocks,
> too.

Right.

> The size of codeblocks is less or eqiual to the size of
> precincts.

Right codeblocks are at most as large as precincts are, provided
you use the proper definition of "size". Codeblocks are placed
in the subbands, precincts are placed in the resolution levels.
Thus, the proper definition of "size" would be: Size of the rectangle
of coefficients in a subband that make up the part of the precinct
within this subband. Or in my language: A codeblock can be at most
as large as the precinct parts.

> I wonder: why we need one more partitioning? code blocks
> xould be have the same role of precincts, isn't it? Why precincts are
> needed? Just to make the standard more complicated?!-(

Actually, the question should be "why are tiles needed?". (-;

Precincts serve the purpose of allowing a position progession entirely
within the wavelet domain, without boundary artifacts. Due to the way
how DWT works, a rectangle of size NxM in decomposition level D
corresponds approximately a spatial image domain of size N*2^D x
M*2^D. Thus, in case you want progression in the wavelet domain, the
blocking required for this progression must depend on the
level. Precincts in a higher-resolution level have to be larger than
those in the lower levels. If one would just do that with codeblocks,
the codeblocks in the lower levels would either become too small to
allow efficient entropy coding, or too large in the high-resolution
levels to allow efficient rate allocation, thus precincts are a
collection of codeblocks that make "sense".

Now we have position progression. It remains the question what tiles
are good for. And the answer is: Politics.

Greetings,
Thomas

> Now we have position progression. It remains the question what tiles
> are good for. And the answer is: Politics.
>
Now I uderstood, thanks. Just your opinion: do you think that we will
find Jpeg2000 (with all the allowed functionalities) in real
applicastions (mobile phones, digital still cameras) soon?

Hi,

> Now I uderstood, thanks. Just your opinion: do you think that we will
> find Jpeg2000 (with all the allowed functionalities) in real
> applicastions (mobile phones, digital still cameras) soon?

Well, to some part we already have it in real applications, though
less in "consumer products". My personal opinion is that JPEG2000 will
be something like a "premium service" for images very much like ISDN
is a premium service for telephone. That is, it will find, and has found
its applications in the medical market, for example. There's also a
proposal to use Motion-JPEG2000 for digital movies - as shown in
movie theaters (huge images, see below. Traditional JPEG doesn`t scale
very well)

As for "consumer products", e.g. web applications, internet browsing, etc,
I don't quite see the point. This market niche is already well taken by
traditional JPEG, and JPEG2000 doesn't really have to offer much if you
"just want to see pictures" and don't care about the features.

It gets good for large images (approximately above 1000x1000), or high
compression (below about 0.7bpp), or if you have demands about
flexibility and configurability traditional JPEG cannot offer. It has
IMHO no real benefit compression wise in the "mid range average web
image", though it does show huge advantages "feature wise". There has
been too much hype about it, and this did more damage than it helped.

So long,
Thomas

Mattia wrote:
>
> Now I uderstood, thanks. Just your opinion: do you think that we will
> find Jpeg2000 (with all the allowed functionalities) in real
> applicastions (mobile phones, digital still cameras) soon?

This wouldn't be good, because Wavelet-based JPEG2000 is inferior
compared with DCT-based JPEG which we already have.  Wavelets are
academic artifacts with no practical advantage compared to DCT,
at least for image compression.
The reason for the hype about JPEG2000 is commerce on one hand,
and lack of knowledge about fundamental DCT properties by so-called
"experts" on the other hand.  Note that the fundamental DCT properties
are not widely known and used, and if known, are ignored by the
"experts" for other reasons.
The Wavelet route and JPEG2000 in particular is an error, and I don't
see this change soon, until progress will be made by exploiting
fundamental DCT properties in some future...

Regards
Guido

Hi,
 

> This wouldn't be good, because Wavelet-based JPEG2000 is inferior
> compared with DCT-based JPEG which we already have.  Wavelets are
> academic artifacts with no practical advantage compared to DCT,
> at least for image compression.

Stop talking trash and state some facts, as in "reproducable results
obtained in a scientific matter". I've done my homework, presenting
images and PSNR measurements. Now it's your turn.

> The reason for the hype about JPEG2000 is commerce on one hand,
> and lack of knowledge about fundamental DCT properties by so-called
> "experts" on the other hand.

Which, clearly, you are /-:. You've still to learn a lot, Guido.
Number one on my priority list is "The Scientific Approach", leave
alone some image compression buisiness, but that's at a lower
priority. As you're continuously refusing to state facts, you're no
bit better than the "marketing folks" you seem to dislike so much.

So long,
Thomas