Almost every time I try to check out the messages
in this list, I get the response from Yahoo:

"Oops...
The list kakadu_jpeg2000 is temporarily unavailable"

or the response is painfully slow.
The other Yahoo group I pay attention to,
the jpeg2000-ISG, doesn't seem to have the
same problems.

Are other people experiencing this?
If so, is there some other place to host the group?

BTW- I just got 3.2 two weeks ago, finally
had a chance to look at it yesterday.
Very good work David! (et al., if appropriate)

The documentation system is excellent, so no
questions yet...unless anyone wants to volunteer
some pointers on cleanly integrating hardware
acceleration of the processing modules?

I'm _very_ new to C++, OOP in general, but
would guess that there is a clean (read: correct)
way to bolt in replacements for the kdu_analysis/synth
and kdu_encode/decode functions?

Hi Justin,

I am not sure why you do not want to use quality layers?
J2K code-streams can be progressively decoded by
resolution, by quality layer, by image component, by
spatial region, or by any combination of the above.
If you only have one quality layer and want to progressively
decode the image in order of increasing resolution, that is
not a problem.  You can arrange for the original data stream
to appear in that order and decode progressively larger prefixes
of the original file.  You can arrange for the image data to
be delivered in any desired order at all to a `kdu_cache'-derived
compressed data source, which is being consumed (as often as
desired) by a decompressor.  You can use
  `kdu_codestream::apply_input_restrictions' to explicitly restrict
decompression to a particular image resolution and interpolate the
result in any manner you desire.

So indeed there are many ways to get improving resolution.
However, a widely misunderstood property of feedback-free
multi-resolution transforms is that resolution scalability does not
buy you substantial savings in total transmission bandwidth by
itself.  It would seem that if you only kept a half resolution image
with 1/4 times the total number of pixels, the compressed size should
be roughly 1/4 the original.  Instead, it can be closer to 90% of the
original.  The reason is that a sufficient quality (quantization
precision) for the full resolution image requires the lower resolution
subbands to be quantized more finely than would be required to
obtain a sufficient image quality when viewing the lower resolution
image by itself.  Thus, to exploit multi-resolution transforms for
bandwidth efficiency, it is actually necessary to have a layered
hierarchy of fidelities (quantization precisions) at each resolution
level.  This is exactly what the JPEG2000 quality layers achieve
(and potentially much more).  For this reason, resolution scalability
is of significantly less value if you do not also use multiple
quality layers.  To view a decent quality thumbnail generally requires
many fewer quality layers than to view a decent quality full resolution
image.

Cheers,

David

----------------------------------------
David Taubman
Senior Lecturer, School of Electrical Engineering and Telecommunications
The University of New South Wales
UNSW Sydney 2052, Australia

phone 61 2 9385-5223
fax   61 2 9385-5993

http://www.ee.unsw.edu.au/~taubman/

------------------------------------------
This message is intended for the addressee named and may contain
confidential information.  If you are not the intended recipient, please
delete it and notify the sender.  Views expressed in this message are
those of the individual sender and are not necessarily the views of
UNSW.
----- Original Message -----
From: "Justin" <jmcmichael@...>
To: "Kakadu_Jpeg2000" <kakadu_jpeg2000@yahoogroups.com>
Sent: Tuesday, April 16, 2002 3:36 AM
Subject: [kakadu_jpeg2000] Progressive rendering


> Is there a way to do progressive rendering a la PJPEG with the kakadu
> library without using quality layers? I know with wavelet-based images is
> should be possible to send and decode the data in such a way as to allow a
> "blurry" first pass to be rendered which gradually gets improved upon
until
> the entire image has been docoded.
>
>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

This is the first problem about availability I've seen.  I know Yahoo
sometimes gets denial-of-service attacks which may affect this, but I
haven't heard of any lately.

However you should not need to actually log in to YahooGroups to send or
receive postings.  You can have your messages forwarded to any emailbox you
like and you should be able to originate messages using an email client such
as Outlook Express.

Michael J Unverferth
MicroImages, Inc.
kakadu_jpeg2000 group moderator


----- Original Message -----
From: "Dickinson, Bill" <dickinsw@...>
To: "'kakadu_jpeg2000 Moderator'" <kakadu_jpeg2000-owner@yahoogroups.com>
Sent: Tuesday, April 16, 2002 8:26 AM
Subject: RE: Welcome to kakadu_jpeg2000


> Thanks.  Any idea why this group is unavailable so much?  Since I became a
> member, accessing the group has been next to impossible.
>
> Bill Dickinson
>
> > ----------
> > From: kakadu_jpeg2000
> > Moderator[SMTP:kakadu_jpeg2000-owner@yahoogroups.com]
> > Sent: Monday, April 15, 2002 1:53 PM
> > To: dickinsw@...
> > Subject: Welcome to kakadu_jpeg2000
> >
> >
> > Hello,
> >
> > Welcome to the kakadu_jpeg2000 group at Yahoo! Groups, a
> > free, easy-to-use email group service. Please
> > take a moment to review this message.
> >
> > To learn more about the kakadu_jpeg2000 group, please visit
> > http://groups.yahoo.com/group/kakadu_jpeg2000
> >
> > To start sending messages to members of this group, simply
> > send email to
> > kakadu_jpeg2000@yahoogroups.com
> >
> > If you do not wish to belong to kakadu_jpeg2000, you may
> > unsubscribe by sending an email to
> > kakadu_jpeg2000-unsubscribe@yahoogroups.com
> >
> > To see and modify all of your groups, go to
> > http://groups.yahoo.com/mygroups
> >
> >
> > Regards,
> >
> > Moderator, kakadu_jpeg2000
> >
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
> >
> >

Almost every time I try to check out the messages
in this list, I get the response from Yahoo:

"Oops...
The list kakadu_jpeg2000 is temporarily unavailable"

or the response is painfully slow.
The other Yahoo group I pay attention to,
the jpeg2000-ISG, doesn't seem to have the
same problems.

Are other people experiencing this?
If so, is there some other place to host the group?

BTW- I just got 3.2 two weeks ago, finally
had a chance to look at it yesterday.
Very good work David! (et al., if appropriate)

The documentation system is excellent, so no
questions yet...unless anyone wants to volunteer
some pointers on cleanly integrating hardware
acceleration of the processing modules?

I'm _very_ new to C++, OOP in general, but
would guess that there is a clean (read: correct)
way to bolt in replacements for the kdu_analysis/synth
and kdu_encode/decode functions?

Hi Bill,

A first minor correction to your understanding is that
image components in JPEG2000 are not intended
only for representing colour channels, although that
is an obvious application. JPEG2000 (and Kakadu)
allows up to 16384 image components to be embedded
in a single code-stream and the intent is to be able to
represent multi-layered images and hyper-spectral
images in this manner.

From an implementation perspective, I would like to
point out that there can be a little bit of confusion between
the Kakadu core system and the "kdu_compress" and
"kdu_expand" demo applications.  The latter use files for
transferring data, but the image file I/O is purposefully kept
simple so as to minimize the risk of people thinking that
these file-based methods are part of the core kakadu
system.  In fact, commercial applications based on kakadu
would be expected to use there own image I/O methods.
The "kdu_v_compress" and "kdu_v_expand" demo apps
use an entirely different set of image I/O routines to suit
video applications, as an example.

At the heart of a JPEG2000 compressor built around
Kakadu is the code-stream management machinery
(represented by `kdu_codestream') with any number of
components, and a compression engine, constructed from
`kdu_analysis' and `kdu_encoder' objects, presenting a
uniform `kdu_push_ifc' interface, into which you push
successive lines from a single image component.  You
can construct any number of compression engines
simultaneously.  In your case, you would construct one
compression engine for each image component and
push the image component lines to these engines in any
order you like.  You could push all the samples from
one component first, then the next component and so on.
Alternatively, you could push one line from the first
component, followed by one from the second and
so forth.  In fact, the latter approach is vastly superior
since it enables you to exploit Kakadu's ability to
anticipate the code-block truncation activities performed
during rate control and avoid performing all coding
passes on all code-blocks.  These capabilities should
never be used unless you are using an interleaved
strategy to compress all of the components together,
as explained in the connection with the
`kdu_codestream::set_max_bytes' function.

Decompression is the same, with lines being pulled
one by one from the decompression engines, in any
order you like.  The kakadu system takes care of
instantiating and recycling all resources required to
accommodate the order in which you would like
to recover the data.

Cheers,

david

----------------------------------------
David Taubman
Senior Lecturer, School of Electrical Engineering and Telecommunications
The University of New South Wales
UNSW Sydney 2052, Australia

phone 61 2 9385-5223
fax   61 2 9385-5993

http://www.ee.unsw.edu.au/~taubman/

------------------------------------------
This message is intended for the addressee named and may contain
confidential information.  If you are not the intended recipient, please
delete it and notify the sender.  Views expressed in this message are
those of the individual sender and are not necessarily the views of
UNSW.
----- Original Message -----
From: "Dickinson, Bill" <dickinsw@...>
To: <kakadu_jpeg2000@yahoogroups.com>
Sent: Tuesday, April 16, 2002 5:28 AM
Subject: [kakadu_jpeg2000] Handling multiple image channels


> Greetings,
>
> Has anyone considered the best way to handle
> compression/decompression of multiple channel image files using Kakadu?
In
> our lab, multiple channel means more than one image data channel
associated
> with a specific wavelength of light.  Image points are represented by
> unsigned shorts.  An entire raw image consists, then, of a header portion
> followed by up to 16 blocks each of which represent a channel, and no
> palette.  In total, the overall file size is approaching one gigabyte.
>
> I can think of a couple of approaches, but I am not sure which one is the
> best with regard to the Kakadu implementation.  Initial testing involved
> compressing/decompressing each channel independently using the
kdu_compress
> and kdu_expand applications running in batch.  Now that we have the code,
> the next step is to integrate compression/decompression into our
> applications.   The core Kakadu classes appear to operate on files (disk
or
> memory) that contain the equivalent of a single channel of image data, and
> thus our raw files would need to be broken down into the channel
components
> for kakadu processing.  This is ok, but I was thinking of interleaving the
> channel data and passing the interleaved file to Kakadu setting the
> Scomponent parameter to the number of channels - even though the intent of
> the Scomponent parameter is to reflect the number of color components - I
> believe.  Does this latter approach seem reasonable?
>
> Anyway, just thought I would see if anyone out there has dealt with this
> issue.  Thanks in advance for your consideration.
>
>
> ****************************************************
> Bill Dickinson
> Center for Medical Genetics
> Marshfield Medical Research Foundation
> 1000 North Oak Avenue, ML-7
> Marshfield, Wisconsin  54449
> e-mail: dickinsw@...
> http://research.marshfieldclinic.org/genetics/
> *****************************************************
>
>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Greetings,

	 Has anyone considered the best way to handle
compression/decompression of multiple channel image files using Kakadu?  In
our lab, multiple channel means more than one image data channel associated
with a specific wavelength of light.  Image points are represented by
unsigned shorts.  An entire raw image consists, then, of a header portion
followed by up to 16 blocks each of which represent a channel, and no
palette.  In total, the overall file size is approaching one gigabyte.

I can think of a couple of approaches, but I am not sure which one is the
best with regard to the Kakadu implementation.  Initial testing involved
compressing/decompressing each channel independently using the kdu_compress
and kdu_expand applications running in batch.  Now that we have the code,
the next step is to integrate compression/decompression into our
applications.   The core Kakadu classes appear to operate on files (disk or
memory) that contain the equivalent of a single channel of image data, and
thus our raw files would need to be broken down into the channel components
for kakadu processing.  This is ok, but I was thinking of interleaving the
channel data and passing the interleaved file to Kakadu setting the
Scomponent parameter to the number of channels - even though the intent of
the Scomponent parameter is to reflect the number of color components - I
believe.  Does this latter approach seem reasonable?

Anyway, just thought I would see if anyone out there has dealt with this
issue.  Thanks in advance for your consideration.


****************************************************
Bill Dickinson
Center for Medical Genetics
Marshfield Medical Research Foundation
1000 North Oak Avenue, ML-7
Marshfield, Wisconsin  54449
e-mail: dickinsw@...
http://research.marshfieldclinic.org/genetics/
*****************************************************

Is there a way to do progressive rendering a la PJPEG with the kakadu
library without using quality layers? I know with wavelet-based images is
should be possible to send and decode the data in such a way as to allow a
"blurry" first pass to be rendered which gradually gets improved upon until
the entire image has been docoded.

Hi Mehrtarupal,

The Kakadu implementation is designed to be re-entrant, but
is not thread safe.  That is, you can use the code in a multi-threading
environment without any difficulty, but you cannot generally access
the same Kakadu object from different threads simultaneously.  You
must provide your own synchronization if this is required.

The "kdu_client" and "kdu_server" applications provide examples
of using Kakadu in a true multi-threading environment.  There is
only one issue which you should pay particular attention to.  Kakadu
uses internal global variables to keep track of the objects passed
into `kdu_customize_errors' and `kdu_customize_warnings' -- there
are no other global variables which can take anything other than
predictable values.  If you want to be able to deliver error or
warning messages through customized handlers of your own, you
will have to pay attention to the fact that all threads must share the
same set of handlers and so the handlers will need to be implemented
in a thread-safe manner.  The next release of Kakadu will contain
an extra virtual member function for the base message handler class,
`kdu_message', which is called when an error or warning message
is about to be delivered (but before any text is delivered through
`kdu_message::put_text').   This makes it somewhat easier to
implement thread-safe custom message handlers.

You should also pay attention to the fact that certain types of
operations on a `kdu_codestream' object lock resources which
must be returned before a new request can be made.  If multiple
threads access the same objects, you will need to be careful
to keep track of who owns these resources yourself.  All such
resources are clearly documented.

Cheers,

David

----------------------------------------
David Taubman
Senior Lecturer, School of Electrical Engineering and Telecommunications
The University of New South Wales
UNSW Sydney 2052, Australia

phone 61 2 9385-5223
fax   61 2 9385-5993

http://www.ee.unsw.edu.au/~taubman/

------------------------------------------
This message is intended for the addressee named and may contain
confidential information.  If you are not the intended recipient, please
delete it and notify the sender.  Views expressed in this message are
those of the individual sender and are not necessarily the views of
UNSW.
----- Original Message -----
From: "mehtarupal" <mehtarupal@...>
To: <kakadu_jpeg2000@yahoogroups.com>
Sent: Saturday, April 13, 2002 10:27 AM
Subject: [kakadu_jpeg2000] Multithread Support in Kakadu Library.


> Hi David,
>
> Is Kakadu libary multithreaded ? I do not think so. But just wanted
> to confirm with you. Would you have any obvious concerns if we have
> to use the Kakadu library in a multithreaded environment ?
>
> Thanks a lot
>
> Rupal Mehta.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Hi Sebastien,

I notice that Scott has already answered your
questions, reinforcing the fact that a JP2 file
cannot simultaneously represent two images.
The embedded code-stream may contain any
number of image components, but at most
3 components can have meaning as colour
channels of the single JP2 image.

Regarding the use of Kakadu, I would like
to point out that the "kdu_compress" demo
application treats all input image components
in order.  If you supply
"-i image1.pgm,image2.ppm", you are supplying
four image components.  It does not care which
files they were originally associated with.  If
the dimensions, bit-depths and processing
reversibility attributes are compatible it will, by
default, apply the code-stream colour transform
to the first 3 image components.  When the
output file is specified as JP2, this demo
application will also interpret the first 3 image
components (after appropriate compatibility tests) as
the JP2 colour channels.  Of course, if you are
building your own application with Kakadu you can
make any associations you like.  But in the example
you gave, the first 3 components, if compatible, are
interpreted as belonging to a colour image and the
last component (last component of the PPM image)
is compressed separately and not identified as having
any special meaning to JP2.  For these reasons,
using the conventions in "kdu_compress", you would
do better to list your colour image first, rather than
second.

Hope this clarifies matters,

David

----------------------------------------
David Taubman
Senior Lecturer, School of Electrical Engineering and Telecommunications
The University of New South Wales
UNSW Sydney 2052, Australia

phone 61 2 9385-5223
fax   61 2 9385-5993

http://www.ee.unsw.edu.au/~taubman/

------------------------------------------
This message is intended for the addressee named and may contain
confidential information.  If you are not the intended recipient, please
delete it and notify the sender.  Views expressed in this message are
those of the individual sender and are not necessarily the views of
UNSW.
----- Original Message -----
From: "Sebastien Andreo" <seb_andreo@...>
To: <kakadu_jpeg2000@yahoogroups.com>
Sent: Friday, April 12, 2002 8:01 PM
Subject: Re: [kakadu_jpeg2000] KDU_EXPAND


> Hi David,
>
> thanks for your interest in my question I posted
> yesterday. Scott's answer was very helpful, and
> I learned that kakadu converts 2 gray scale components
> into 2 channels. That's perfect. Now, I tried to
> create a jp2 code stream comprising
> a color image (ppm) and a gray scale image (pgm).
>
> The command line was:
>  kdu_compress -i gray_input.pgm,color_input.ppm  -o
> gray+color.jp2 Creversible=yes
>
> Kakadu (kdu_compress) did accept it, and I got the
> codestream.
>
> The problem was to get back the color image and
> the gray scale image with kdu_expand. In fact, I
> did only manage to get back four raw components
> using the command line:
>
> kdu_expand -i gray+color.jp2 -raw_components -o
>
gray_input.raw,color_input_red.raw,color_input_green.raw,color_input_blue.ra
w
>
> Is there any way to recover the color image and the
> gray scale image directly?
>
> Thanks for any answer!
>
>
>  --- David Taubman <d.taubman@...> a écrit :
> <HR>
> <html><body>
>
>
> <tt>
> HI Sebastian and Scott,<BR>
> <BR>
> Thanks Scott for your good explanation of JP2.<BR>
> It is not at all clear to me what the writer is<BR>
> trying to do.&nbsp; Kakadu lets you put 2
> components<BR>
> into a code-stream embedded in a JP2 file (just<BR>
> tried it) and marks the first component as a<BR>
> grey-scale image, leaving the other one undefined<BR>
> as it should in the context of JP2, since there<BR>
> is one colour space which can be described<BR>
> (a monochrome space).<BR>
> <BR>
> Cheers,<BR>
> <BR>
> David<BR>
> <BR>
> ----------------------------------------<BR>
> David Taubman<BR>
> Senior Lecturer, School of Electrical Engineering and
> Telecommunications<BR>
> The University of New South Wales<BR>
> UNSW Sydney 2052, Australia<BR>
> <BR>
> phone 61 2 9385-5223<BR>
> fax&nbsp;&nbsp; 61 2 9385-5993<BR>
> <BR>
> <a
>
href="http://www.ee.unsw.edu.au/~taubman/">http://www.ee.unsw.edu.au/~taubma
n/</a><BR>
> <BR>
> ------------------------------------------<BR>
> This message is intended for the addressee named and
> may contain<BR>
> confidential information.&nbsp; If you are not the
> intended recipient, please<BR>
> delete it and notify the sender.&nbsp; Views expressed
> in this message are<BR>
> those of the individual sender and are not necessarily
> the views of<BR>
> UNSW.<BR>
> ----- Original Message -----<BR>
> From: &quot;J. Scott Houchin&quot;
> &lt;scott.houchin@...&gt;<BR>
> To: &lt;kakadu_jpeg2000@yahoogroups.com&gt;<BR>
> Sent: Friday, April 12, 2002 12:13 AM<BR>
> Subject: Re: [kakadu_jpeg2000] KDU_EXPAND<BR>
> <BR>
> <BR>
> &gt; Hi Sebastien,<BR>
> &gt;<BR>
> &gt; I'm not familiar with the Kadaku interfaces, but
> from the point of<BR>
> &gt; view of the standard, here's the answer to your
> main question.<BR>
> &gt;<BR>
> &gt; A JP2 file is a container. Inside that container
> are two kinds of things<BR>
> &gt; - A compressed JPEG 2000 codestream<BR>
> &gt; - Assorted metadata that, among other things,
> specifies the &quot;meaning&quot; of<BR>
> &gt;&nbsp;&nbsp;&nbsp; the data in the codestream.<BR>
> &gt;<BR>
> &gt; That codestream contains multiple 2D planes of
> image data, called<BR>
> &gt; components. A component has no meaning. It's just
> a a 2D plane of<BR>
> &gt; image data. It's not greyscale data, or red
> channel data, ... It's<BR>
> &gt; just data.<BR>
> &gt;<BR>
> &gt; The JP2 data structures then specify meaning for
> those components.<BR>
> &gt; However, before it can do that, it must deal with
> things like<BR>
> &gt; palettization, which will create multiple planes
> of image data from a<BR>
> &gt; single component.<BR>
> &gt;<BR>
> &gt; That's where channels come in.<BR>
> &gt;<BR>
> &gt; A channel is an abstraction of a component that
> allows for &quot;virtual<BR>
> &gt; components&quot; (components that are not
> physically stored in the file.<BR>
> &gt; For example, if I have an index color image,
> there is a virtual red<BR>
> &gt; component in the JP2 file, created by applying
> the red palette to the<BR>
> &gt; single component in the codestream. It is also
> possible to clone a<BR>
> &gt; component through the use of channels (we're not
> sure there are<BR>
> &gt; really any good reasons to do this, but it is
> allowed for coding<BR>
> &gt; simplicity as well as to avoid having unintended
> loopholes in the<BR>
> &gt; standard).<BR>
> &gt;<BR>
> &gt; The set of physical components and virtual
> components that are<BR>
> &gt; exposed to the part of the JP2 file that assigns
> meaning to data are<BR>
> &gt; collectively referred to as channels. In your
> example, if I had two<BR>
> &gt; components in a single file, then I would in
> general have two<BR>
> &gt; channels. However, the number of channels is not
> necessarily equal to<BR>
> &gt; the sum of the number of physical components and
> the number of<BR>
> &gt; virtual components. Consider that Index RGB
> image, for example. In<BR>
> &gt; that JP2 file, three virtual components will be
> created (R, G and B).<BR>
> &gt; However, in general, the physical component that
> contains the index<BR>
> &gt; data will not be assigned meaning, other than its
> use to create other<BR>
> &gt; image planes. In this case, there would only be
> three channels in the<BR>
> &gt; file.<BR>
> &gt;<BR>
> &gt; Once a set of channels have been defined (in the
> JP2 file), meaning<BR>
> &gt; is assigned. For each channel, two things are
> defined:<BR>
> &gt; - Whether it's color or non-color data (such as
> depth or opacity)<BR>
> &gt; - If it's non-color data, the set of color
> channels to which this channel<BR>
> &gt;&nbsp;&nbsp;&nbsp; applies. For example, it's
> possible to define one opacity channel to go<BR>
> &gt;&nbsp;&nbsp;&nbsp; with the red and green
> channels, and a second to go with the blue<BR>
> channel.<BR>
> &gt;<BR>
> &gt;<BR>
> &gt; As for what is specifically happening in Kakadu,
> someone else will have to<BR>
> &gt; answer this. However, if you want, you can send
> me your file and I'll take<BR>
> &gt; a look at it (please keep it small though).<BR>
> &gt;<BR>
> &gt;<BR>
> &gt; Scott Houchin<BR>
> &gt;<BR>
> &gt;<BR>
> &gt;<BR>
> &gt;<BR>
> &gt; &gt;Hie,<BR>
> &gt; &gt;<BR>
> &gt; &gt;I am working for 2 months on kakadu
> library.<BR>
> &gt; &gt;<BR>
> &gt; &gt;And I've got a pb I don't understand clearly
> what is the diference<BR>
> &gt; &gt;between a channel an a component.<BR>
> &gt; &gt;<BR>
> &gt; &gt;My goal is to make a java object for
> extracting from the codestream a<BR>
> &gt; &gt;specific component at a particular resolution
> and a particular<BR>
> &gt; &gt;quality.<BR>
> &gt; &gt;<BR>
> &gt; &gt;So I translate the Kdu_expand in java and I
> try to modify it but the<BR>
> &gt; &gt;decompression process is a little bit
> dark.<BR>
> &gt; &gt;I don't undestand because I compress two gray
> scale images in a Jp2<BR>
> &gt; &gt;file so for me I've 2 components and each
> component has 1 channel.<BR>
> &gt; &gt;But when I debug kdu_expand I've got 2
> channels and 2 components.<BR>
> &gt; &gt;<BR>
> &gt; &gt;Could yopu help me.<BR>
> &gt; &gt;<BR>
> &gt; &gt;Sebastien Andreo<BR>
> &gt; &gt;<BR>
> &gt; &gt;<BR>
> &gt; &gt;<BR>
> &gt; &gt;<BR>
> &gt; &gt;To unsubscribe from this group, send an email
> to:<BR>
> &gt;
> &gt;kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
> &gt; &gt;<BR>
> &gt; &gt;<BR>
> &gt; &gt;<BR>
> &gt; &gt;Your use of Yahoo! Groups is subject to <a
>
href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</
a><BR>
> &gt;<BR>
> &gt;<BR>
> &gt; --<BR>
> &gt;<BR>
> &gt;<BR>
> &gt; To unsubscribe from this group, send an email
> to:<BR>
> &gt; kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
> &gt;<BR>
> &gt;<BR>
> &gt;<BR>
> &gt; Your use of Yahoo! Groups is subject to <a
>
href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</
a><BR>
> &gt;<BR>
> &gt;<BR>
> &gt;<BR>
> <BR>
> </tt>
>
> <br>
>
> <!-- |**|begin egp html banner|**| -->
>
> <table border=0 cellspacing=0 cellpadding=2>
> <tr bgcolor=#FFFFCC>
> <td align=center><font size="-1"
> color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
> </tr>
> <tr bgcolor=#FFFFFF>
> <td align=center width=470><table border=0
> cellpadding=0 cellspacing=0><tr><td align=center><font
> face=arial size=-2>ADVERTISEMENT</font><br><a
>
href="http://rd.yahoo.com/M=194081.1994012.3473453.1261774/D=egroupweb/S=170
5007181:HM/A=1036972/R=0/*http://www.ediets.com/start.cfm?code=3466"targe
> t=_top><img
>
src="http://us.a1.yimg.com/us.yimg.com/a/ed/ediets/250x300_bluechair.jpg"alt
="Click
> Here!" width="250" height="300"
> border="0"></a></td></tr></table></td>
> </tr>
> <tr><td><img alt="" width=1 height=1
>
src="http://us.adserver.yahoo.com/l?M=194081.1994012.3473453.1261774/D=egrou
pmail/S=1705007181:HM/A=1036972/rand=490460471"></td></tr>
> </table>
>
> <!-- |**|end egp html banner|**| -->
>
>
> <br>
> <tt>
> To unsubscribe from this group, send an email to:<BR>
> kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
> <BR>
> </tt>
> <br>
>
> <br>
> <tt>Your use of Yahoo! Groups is subject to the <a
> href="http://docs.yahoo.com/info/terms/">Yahoo! Terms
> of Service</a>.</tt>
> </br>
>
> </body></html>
>
>
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
> Yahoo! Mail : http://fr.mail.yahoo.com
>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Hi David,

Is Kakadu libary multithreaded ? I do not think so. But just wanted
to confirm with you. Would you have any obvious concerns if we have
to use the Kakadu library in a multithreaded environment ?

Thanks a lot

Rupal Mehta.

The JP2 file format is not capable of storing two separate images.
Let me continue with my explanation from yesterday, and it should make
sense.

Once a set of channels have been defined, the JP2 file format then uses
those channels to specify the colorspace of THE image. JP2 explicitly
specifies that there is only one set of header information.

In your example, you have four channels (0-3).

Once those channels are defined, the format then attempts to assign
meaning to those channels. For non-color/grey channels, it just indicates
what type of data is in that channel.

For channels that are input to some color or tonescale processing
transform (thus producing visual stimuli), the JP2 format first uses
the channel definition architecture to match channels to inputs in
a single color processing transform. For example, the JP2 format never
actually says that the red data is red. It just says that it maps to the
first input the the color transform. If the transform takes RGB input, the
indication that the first channel contains red data is only implicit.

The JP2 file format does allow you to embed multiple color transforms in
the file. However, those multiple transforms are explicitly defined as
alternate equations to take a single set of inputs and get equivalent
output (at different precisions). For example, it is possible to specify
many different RGB colorspaces using the Restricted ICC method. However,
to distill the color transform equations to a 3x3 matrix, 1D LUT form might
involve the sacrifice of some precision or accuracy. Thus it is possible
to include a second colorspace transform (defined in the JPX standard in
JPEG 2000 part 2) to allow for a more accurate/precise result in extended
applications.


In your example, JP2 will either require you to take those four channels
as input to a single colorspace transform (which is not appropriate) or
to specify an RGB colorspace with the greyscale data as other data (such
as opacity), or as you've found, to specify that the four components
are of unknown meaning. I'm guessing that Kakadu chose the last option
because it didn't not know what you wanted.

If you can be more explcit about what you're trying to do and why
you want to put both the color image and the greyscale image into the same
codestream, maybe we can give you a better solution.


Scott Houchin



>Hi David,
>
>thanks for your interest in my question I posted
>yesterday. Scott's answer was very helpful, and
>I learned that kakadu converts 2 gray scale components
>into 2 channels. That's perfect. Now, I tried to
>create a jp2 code stream comprising
>a color image (ppm) and a gray scale image (pgm).
>
>The command line was:
>  kdu_compress -i gray_input.pgm,color_input.ppm  -o
>gray+color.jp2 Creversible=yes
>
>Kakadu (kdu_compress) did accept it, and I got the
>codestream.
>
>The problem was to get back the color image and
>the gray scale image with kdu_expand. In fact, I
>did only manage to get back four raw components
>using the command line:
>
>kdu_expand -i gray+color.jp2 -raw_components -o
>gray_input.raw,color_input_red.raw,color_input_green.raw,color_input_blue.raw
>
>Is there any way to recover the color image and the
>gray scale image directly?
>
>Thanks for any answer!
>
>
>  --- David Taubman <d.taubman@...> a écrit :
><HR>
><html><body>
>
>
><tt>
>HI Sebastian and Scott,<BR>
><BR>
>Thanks Scott for your good explanation of JP2.<BR>
>It is not at all clear to me what the writer is<BR>
>trying to do.&nbsp; Kakadu lets you put 2
>components<BR>
>into a code-stream embedded in a JP2 file (just<BR>
>tried it) and marks the first component as a<BR>
>grey-scale image, leaving the other one undefined<BR>
>as it should in the context of JP2, since there<BR>
>is one colour space which can be described<BR>
>(a monochrome space).<BR>
><BR>
>Cheers,<BR>
><BR>
>David<BR>
><BR>
>----------------------------------------<BR>
>David Taubman<BR>
>Senior Lecturer, School of Electrical Engineering and
>Telecommunications<BR>
>The University of New South Wales<BR>
>UNSW Sydney 2052, Australia<BR>
><BR>
>phone 61 2 9385-5223<BR>
>fax&nbsp;&nbsp; 61 2 9385-5993<BR>
><BR>
><a
>href="http://www.ee.unsw.edu.au/~taubman/">http://www.ee.unsw.edu.au/~taubman/<\
/a><BR>
><BR>
>------------------------------------------<BR>
>This message is intended for the addressee named and
>may contain<BR>
>confidential information.&nbsp; If you are not the
>intended recipient, please<BR>
>delete it and notify the sender.&nbsp; Views expressed
>in this message are<BR>
>those of the individual sender and are not necessarily
>the views of<BR>
>UNSW.<BR>
>----- Original Message -----<BR>
>From: &quot;J. Scott Houchin&quot;
>&lt;scott.houchin@...&gt;<BR>
>To: &lt;kakadu_jpeg2000@yahoogroups.com&gt;<BR>
>Sent: Friday, April 12, 2002 12:13 AM<BR>
>Subject: Re: [kakadu_jpeg2000] KDU_EXPAND<BR>
><BR>
><BR>
>&gt; Hi Sebastien,<BR>
>&gt;<BR>
>&gt; I'm not familiar with the Kadaku interfaces, but
>from the point of<BR>
>&gt; view of the standard, here's the answer to your
>main question.<BR>
>&gt;<BR>
>&gt; A JP2 file is a container. Inside that container
>are two kinds of things<BR>
>&gt; - A compressed JPEG 2000 codestream<BR>
>&gt; - Assorted metadata that, among other things,
>specifies the &quot;meaning&quot; of<BR>
>&gt;&nbsp;&nbsp;&nbsp; the data in the codestream.<BR>
>&gt;<BR>
>&gt; That codestream contains multiple 2D planes of
>image data, called<BR>
>&gt; components. A component has no meaning. It's just
>a a 2D plane of<BR>
>&gt; image data. It's not greyscale data, or red
>channel data, ... It's<BR>
>&gt; just data.<BR>
>&gt;<BR>
>&gt; The JP2 data structures then specify meaning for
>those components.<BR>
>&gt; However, before it can do that, it must deal with
>things like<BR>
>&gt; palettization, which will create multiple planes
>of image data from a<BR>
>&gt; single component.<BR>
>&gt;<BR>
>&gt; That's where channels come in.<BR>
>&gt;<BR>
>&gt; A channel is an abstraction of a component that
>allows for &quot;virtual<BR>
>&gt; components&quot; (components that are not
>physically stored in the file.<BR>
>&gt; For example, if I have an index color image,
>there is a virtual red<BR>
>&gt; component in the JP2 file, created by applying
>the red palette to the<BR>
>&gt; single component in the codestream. It is also
>possible to clone a<BR>
>&gt; component through the use of channels (we're not
>sure there are<BR>
>&gt; really any good reasons to do this, but it is
>allowed for coding<BR>
>&gt; simplicity as well as to avoid having unintended
>loopholes in the<BR>
>&gt; standard).<BR>
>&gt;<BR>
>&gt; The set of physical components and virtual
>components that are<BR>
>&gt; exposed to the part of the JP2 file that assigns
>meaning to data are<BR>
>&gt; collectively referred to as channels. In your
>example, if I had two<BR>
>&gt; components in a single file, then I would in
>general have two<BR>
>&gt; channels. However, the number of channels is not
>necessarily equal to<BR>
>&gt; the sum of the number of physical components and
>the number of<BR>
>&gt; virtual components. Consider that Index RGB
>image, for example. In<BR>
>&gt; that JP2 file, three virtual components will be
>created (R, G and B).<BR>
>&gt; However, in general, the physical component that
>contains the index<BR>
>&gt; data will not be assigned meaning, other than its
>use to create other<BR>
>&gt; image planes. In this case, there would only be
>three channels in the<BR>
>&gt; file.<BR>
>&gt;<BR>
>&gt; Once a set of channels have been defined (in the
>JP2 file), meaning<BR>
>&gt; is assigned. For each channel, two things are
>defined:<BR>
>&gt; - Whether it's color or non-color data (such as
>depth or opacity)<BR>
>&gt; - If it's non-color data, the set of color
>channels to which this channel<BR>
>&gt;&nbsp;&nbsp;&nbsp; applies. For example, it's
>possible to define one opacity channel to go<BR>
>&gt;&nbsp;&nbsp;&nbsp; with the red and green
>channels, and a second to go with the blue<BR>
>channel.<BR>
>&gt;<BR>
>&gt;<BR>
>&gt; As for what is specifically happening in Kakadu,
>someone else will have to<BR>
>&gt; answer this. However, if you want, you can send
>me your file and I'll take<BR>
>&gt; a look at it (please keep it small though).<BR>
>&gt;<BR>
>&gt;<BR>
>&gt; Scott Houchin<BR>
>&gt;<BR>
>&gt;<BR>
>&gt;<BR>
>&gt;<BR>
>&gt; &gt;Hie,<BR>
>&gt; &gt;<BR>
>&gt; &gt;I am working for 2 months on kakadu
>library.<BR>
>&gt; &gt;<BR>
>&gt; &gt;And I've got a pb I don't understand clearly
>what is the diference<BR>
>&gt; &gt;between a channel an a component.<BR>
>&gt; &gt;<BR>
>&gt; &gt;My goal is to make a java object for
>extracting from the codestream a<BR>
>&gt; &gt;specific component at a particular resolution
>and a particular<BR>
>&gt; &gt;quality.<BR>
>&gt; &gt;<BR>
>&gt; &gt;So I translate the Kdu_expand in java and I
>try to modify it but the<BR>
>&gt; &gt;decompression process is a little bit
>dark.<BR>
>&gt; &gt;I don't undestand because I compress two gray
>scale images in a Jp2<BR>
>&gt; &gt;file so for me I've 2 components and each
>component has 1 channel.<BR>
>&gt; &gt;But when I debug kdu_expand I've got 2
>channels and 2 components.<BR>
>&gt; &gt;<BR>
>&gt; &gt;Could yopu help me.<BR>
>&gt; &gt;<BR>
>&gt; &gt;Sebastien Andreo<BR>
>&gt; &gt;<BR>
>&gt; &gt;<BR>
>&gt; &gt;<BR>
>&gt; &gt;<BR>
>&gt; &gt;To unsubscribe from this group, send an email
>to:<BR>
>&gt;
>&gt;kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
>&gt; &gt;<BR>
>&gt; &gt;<BR>
>&gt; &gt;<BR>
>&gt; &gt;Your use of Yahoo! Groups is subject to <a
>href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a><\
BR>
>&gt;<BR>
>&gt;<BR>
>&gt; --<BR>
>&gt;<BR>
>&gt;<BR>
>&gt; To unsubscribe from this group, send an email
>to:<BR>
>&gt; kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
>&gt;<BR>
>&gt;<BR>
>&gt;<BR>
>&gt; Your use of Yahoo! Groups is subject to <a
>href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a><\
BR>
>&gt;<BR>
>&gt;<BR>
>&gt;<BR>
><BR>
></tt>
>
><br>
>
><!-- |**|begin egp html banner|**| -->
>
><table border=0 cellspacing=0 cellpadding=2>
><tr bgcolor=#FFFFCC>
><td align=center><font size="-1"
>color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
></tr>
><tr bgcolor=#FFFFFF>
><td align=center width=470><table border=0
>cellpadding=0 cellspacing=0><tr><td align=center><font
>face=arial size=-2>ADVERTISEMENT</font><br><a
>href="http://rd.yahoo.com/M=194081.1994012.3473453.1261774/D=egroupweb/S=170500\
7181:HM/A=1036972/R=0/*http://www.ediets.com/start.cfm?code=3466"targe
>t=_top><img
>src="http://us.a1.yimg.com/us.yimg.com/a/ed/ediets/250x300_bluechair.jpg"alt="C\
lick
>Here!" width="250" height="300"
>border="0"></a></td></tr></table></td>
></tr>
><tr><td><img alt="" width=1 height=1
>src="http://us.adserver.yahoo.com/l?M=194081.1994012.3473453.1261774/D=egroupma\
il/S=1705007181:HM/A=1036972/rand=490460471"></td></tr>
></table>
>
><!-- |**|end egp html banner|**| -->
>
>
><br>
><tt>
>To unsubscribe from this group, send an email to:<BR>
>kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
><BR>
></tt>
><br>
>
><br>
><tt>Your use of Yahoo! Groups is subject to the <a
>href="http://docs.yahoo.com/info/terms/">Yahoo! Terms
>of Service</a>.</tt>
></br>
>
></body></html>
>
>
>___________________________________________________________
>Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
>Yahoo! Mail : http://fr.mail.yahoo.com
>
>
>To unsubscribe from this group, send an email to:
>kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


--

Hi David,

thanks for your interest in my question I posted
yesterday. Scott's answer was very helpful, and
I learned that kakadu converts 2 gray scale components
into 2 channels. That's perfect. Now, I tried to
create a jp2 code stream comprising
a color image (ppm) and a gray scale image (pgm).

The command line was:
  kdu_compress -i gray_input.pgm,color_input.ppm  -o
gray+color.jp2 Creversible=yes

Kakadu (kdu_compress) did accept it, and I got the
codestream.

The problem was to get back the color image and
the gray scale image with kdu_expand. In fact, I
did only manage to get back four raw components
using the command line:

kdu_expand -i gray+color.jp2 -raw_components -o
gray_input.raw,color_input_red.raw,color_input_green.raw,color_input_blue.raw

Is there any way to recover the color image and the
gray scale image directly?

Thanks for any answer!


  --- David Taubman <d.taubman@...> a écrit :
<HR>
<html><body>


<tt>
HI Sebastian and Scott,<BR>
<BR>
Thanks Scott for your good explanation of JP2.<BR>
It is not at all clear to me what the writer is<BR>
trying to do.&nbsp; Kakadu lets you put 2
components<BR>
into a code-stream embedded in a JP2 file (just<BR>
tried it) and marks the first component as a<BR>
grey-scale image, leaving the other one undefined<BR>
as it should in the context of JP2, since there<BR>
is one colour space which can be described<BR>
(a monochrome space).<BR>
<BR>
Cheers,<BR>
<BR>
David<BR>
<BR>
----------------------------------------<BR>
David Taubman<BR>
Senior Lecturer, School of Electrical Engineering and
Telecommunications<BR>
The University of New South Wales<BR>
UNSW Sydney 2052, Australia<BR>
<BR>
phone 61 2 9385-5223<BR>
fax&nbsp;&nbsp; 61 2 9385-5993<BR>
<BR>
<a
href="http://www.ee.unsw.edu.au/~taubman/">http://www.ee.unsw.edu.au/~taubman/</\
a><BR>
<BR>
------------------------------------------<BR>
This message is intended for the addressee named and
may contain<BR>
confidential information.&nbsp; If you are not the
intended recipient, please<BR>
delete it and notify the sender.&nbsp; Views expressed
in this message are<BR>
those of the individual sender and are not necessarily
the views of<BR>
UNSW.<BR>
----- Original Message -----<BR>
From: &quot;J. Scott Houchin&quot;
&lt;scott.houchin@...&gt;<BR>
To: &lt;kakadu_jpeg2000@yahoogroups.com&gt;<BR>
Sent: Friday, April 12, 2002 12:13 AM<BR>
Subject: Re: [kakadu_jpeg2000] KDU_EXPAND<BR>
<BR>
<BR>
&gt; Hi Sebastien,<BR>
&gt;<BR>
&gt; I'm not familiar with the Kadaku interfaces, but
from the point of<BR>
&gt; view of the standard, here's the answer to your
main question.<BR>
&gt;<BR>
&gt; A JP2 file is a container. Inside that container
are two kinds of things<BR>
&gt; - A compressed JPEG 2000 codestream<BR>
&gt; - Assorted metadata that, among other things,
specifies the &quot;meaning&quot; of<BR>
&gt;&nbsp;&nbsp;&nbsp; the data in the codestream.<BR>
&gt;<BR>
&gt; That codestream contains multiple 2D planes of
image data, called<BR>
&gt; components. A component has no meaning. It's just
a a 2D plane of<BR>
&gt; image data. It's not greyscale data, or red
channel data, ... It's<BR>
&gt; just data.<BR>
&gt;<BR>
&gt; The JP2 data structures then specify meaning for
those components.<BR>
&gt; However, before it can do that, it must deal with
things like<BR>
&gt; palettization, which will create multiple planes
of image data from a<BR>
&gt; single component.<BR>
&gt;<BR>
&gt; That's where channels come in.<BR>
&gt;<BR>
&gt; A channel is an abstraction of a component that
allows for &quot;virtual<BR>
&gt; components&quot; (components that are not
physically stored in the file.<BR>
&gt; For example, if I have an index color image,
there is a virtual red<BR>
&gt; component in the JP2 file, created by applying
the red palette to the<BR>
&gt; single component in the codestream. It is also
possible to clone a<BR>
&gt; component through the use of channels (we're not
sure there are<BR>
&gt; really any good reasons to do this, but it is
allowed for coding<BR>
&gt; simplicity as well as to avoid having unintended
loopholes in the<BR>
&gt; standard).<BR>
&gt;<BR>
&gt; The set of physical components and virtual
components that are<BR>
&gt; exposed to the part of the JP2 file that assigns
meaning to data are<BR>
&gt; collectively referred to as channels. In your
example, if I had two<BR>
&gt; components in a single file, then I would in
general have two<BR>
&gt; channels. However, the number of channels is not
necessarily equal to<BR>
&gt; the sum of the number of physical components and
the number of<BR>
&gt; virtual components. Consider that Index RGB
image, for example. In<BR>
&gt; that JP2 file, three virtual components will be
created (R, G and B).<BR>
&gt; However, in general, the physical component that
contains the index<BR>
&gt; data will not be assigned meaning, other than its
use to create other<BR>
&gt; image planes. In this case, there would only be
three channels in the<BR>
&gt; file.<BR>
&gt;<BR>
&gt; Once a set of channels have been defined (in the
JP2 file), meaning<BR>
&gt; is assigned. For each channel, two things are
defined:<BR>
&gt; - Whether it's color or non-color data (such as
depth or opacity)<BR>
&gt; - If it's non-color data, the set of color
channels to which this channel<BR>
&gt;&nbsp;&nbsp;&nbsp; applies. For example, it's
possible to define one opacity channel to go<BR>
&gt;&nbsp;&nbsp;&nbsp; with the red and green
channels, and a second to go with the blue<BR>
channel.<BR>
&gt;<BR>
&gt;<BR>
&gt; As for what is specifically happening in Kakadu,
someone else will have to<BR>
&gt; answer this. However, if you want, you can send
me your file and I'll take<BR>
&gt; a look at it (please keep it small though).<BR>
&gt;<BR>
&gt;<BR>
&gt; Scott Houchin<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; &gt;Hie,<BR>
&gt; &gt;<BR>
&gt; &gt;I am working for 2 months on kakadu
library.<BR>
&gt; &gt;<BR>
&gt; &gt;And I've got a pb I don't understand clearly
what is the diference<BR>
&gt; &gt;between a channel an a component.<BR>
&gt; &gt;<BR>
&gt; &gt;My goal is to make a java object for
extracting from the codestream a<BR>
&gt; &gt;specific component at a particular resolution
and a particular<BR>
&gt; &gt;quality.<BR>
&gt; &gt;<BR>
&gt; &gt;So I translate the Kdu_expand in java and I
try to modify it but the<BR>
&gt; &gt;decompression process is a little bit
dark.<BR>
&gt; &gt;I don't undestand because I compress two gray
scale images in a Jp2<BR>
&gt; &gt;file so for me I've 2 components and each
component has 1 channel.<BR>
&gt; &gt;But when I debug kdu_expand I've got 2
channels and 2 components.<BR>
&gt; &gt;<BR>
&gt; &gt;Could yopu help me.<BR>
&gt; &gt;<BR>
&gt; &gt;Sebastien Andreo<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;To unsubscribe from this group, send an email
to:<BR>
&gt;
&gt;kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;Your use of Yahoo! Groups is subject to <a
href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a><B\
R>
&gt;<BR>
&gt;<BR>
&gt; --<BR>
&gt;<BR>
&gt;<BR>
&gt; To unsubscribe from this group, send an email
to:<BR>
&gt; kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; Your use of Yahoo! Groups is subject to <a
href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a><B\
R>
&gt;<BR>
&gt;<BR>
&gt;<BR>
<BR>
</tt>

<br>

<!-- |**|begin egp html banner|**| -->

<table border=0 cellspacing=0 cellpadding=2>
<tr bgcolor=#FFFFCC>
<td align=center><font size="-1"
color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
</tr>
<tr bgcolor=#FFFFFF>
<td align=center width=470><table border=0
cellpadding=0 cellspacing=0><tr><td align=center><font
face=arial size=-2>ADVERTISEMENT</font><br><a
href="http://rd.yahoo.com/M=194081.1994012.3473453.1261774/D=egroupweb/S=1705007\
181:HM/A=1036972/R=0/*http://www.ediets.com/start.cfm?code=3466"targe
t=_top><img
src="http://us.a1.yimg.com/us.yimg.com/a/ed/ediets/250x300_bluechair.jpg"alt="Cl\
ick
Here!" width="250" height="300"
border="0"></a></td></tr></table></td>
</tr>
<tr><td><img alt="" width=1 height=1
src="http://us.adserver.yahoo.com/l?M=194081.1994012.3473453.1261774/D=egroupmai\
l/S=1705007181:HM/A=1036972/rand=490460471"></td></tr>
</table>

<!-- |**|end egp html banner|**| -->


<br>
<tt>
To unsubscribe from this group, send an email to:<BR>
kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
<BR>
</tt>
<br>

<br>
<tt>Your use of Yahoo! Groups is subject to the <a
href="http://docs.yahoo.com/info/terms/">Yahoo! Terms
of Service</a>.</tt>
</br>

</body></html>


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Hmm,

This is an interesting one.  Would be good to
get to the bottom of it.  If you were working
with bit-depths greater than 8-bit per sample
I would suggest that your problem is connected
with getting the byte order mixed up (easy to
do, since kdu_compress expects big-endian,
while intel processors use native little-endian).
However, your mail suggests it is an 8-bit image.

Since the fundamental algorithm used for
compression and rate control is the EBCOT
algorithm in both Jasper and Kakadu, I cannot
see any reason for differing results, except that
Jasper does not select exactly the same set
of default coding parameters.  I would suggest
you look into whether or not the compression
path was reversible.  Open up the Jasper
compressed image with "kdu_show" and use
the file->properties menu item to check
whether "Creversible" is "yes" or "no".
Kakadu's default is "no".  To change, send
"Creversible=yes to "kdu_compress"
and see what happens. The reversible path
uses shorter filters which may have something
to do with the artefacts.

Cheers,

David

----------------------------------------
David Taubman
Senior Lecturer, School of Electrical Engineering and Telecommunications
The University of New South Wales
UNSW Sydney 2052, Australia

phone 61 2 9385-5223
fax   61 2 9385-5993

http://www.ee.unsw.edu.au/~taubman/

------------------------------------------
This message is intended for the addressee named and may contain
confidential information.  If you are not the intended recipient, please
delete it and notify the sender.  Views expressed in this message are
those of the individual sender and are not necessarily the views of
UNSW.
----- Original Message -----
From: "mehtarupal" <mehtarupal@...>
To: <kakadu_jpeg2000@yahoogroups.com>
Sent: Friday, April 12, 2002 7:42 AM
Subject: [kakadu_jpeg2000] Re: JPEG2000 Compression Artifacts


> Hi Jim,
>
> Thanks for your reply. I have tried compressing this image with
> jasper. I see no artifacts when compressing this image using jasper.
> As far as I know, there is no way to specify any other information
> like Qstep when compressing using jasper. So I just specify the
> compression ratio of 10:1 for both the lib.
>                 Comp Ratio         Artifacts
> Kakadu Result : 10:1                Present.
> Jasper results: 17:1                No Artifacts
>
> The image is a 8-bit Unsigned CR Chest Image(792KB)
> Let me know how would you like to receive this image ?
>
> My email address is : rmehta@...
>
> Thanks
>
> Rupal
>
> --- In kakadu_jpeg2000@y..., "Reid, Jim" <jreid@c...> wrote:
> > Have you compared these results to those of other JPEG 2000
> implementations
> > (VM, JasPer, JJ2k)?
> > How large are your images?
> > I'd be willing to double check your results if your images
> > are reasonable to send via email.
> >
> >
> > X_________       _____
> > Jim Reid
> > jreid@c...
> > (716) 422-9690
> >
> > -----Original Message-----
> > From: mehtarupal [mailto:mehtarupal@y...]
> > Sent: Wednesday, April 10, 2002 9:52 PM
> > To: kakadu_jpeg2000@y...
> > Subject: [kakadu_jpeg2000] JPEG2000 Compression Artifacts
> >
> >
> > Hi David,
> >
> > I am observing some compression artifacts on CR Chest images.
> > The artifacts always appear on the right hand side of the image.
> > They run diagonal from right to left. It's like alternate band of
> > black and white values.
> >
> > I have tried to compress this image at JPEG2000 10:1 compression
> > ratio using different values for Qstep. We have not observed a
> > pattern where increasing or decreasing the Qstep would give
> > consistent results in terms of image quality. Sometimes a lower
> value
> > of Qstep gives the desired quality and sometimes a higher value
> gives
> > the same quality.
> > Using kdu_compress and the same Qstep values, we see the same
> > behaviour. So we are having trouble to algorithmically compute the
> > appropriate Qstep.
> >
> > I have tried using variations in the block size, but I believe this
> > problem is very specific to selection of right Qstep.
> > Using rate-distortion slope values does not help to resolve these
> > problems.
> > Could you explain what is the relation of bitdepth to Qstep ?
> >
> > I have a .pgm version of the CR Chest image. Would you like to get
> a
> > copy of that image?
> > What are the other parameters we can use to control the image
> quality
> > and compression ratio. We have tried using rate-distortion
> threshold,
> > Cmodes.., Block size...Is there any other combination that can work
> > accross all images?
> >
> > Thanks
> >
> > Rupal Mehta
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Sponsor
> >
> > ADVERTISEMENT
> >
> >
> <http://rd.yahoo.com/M=213858.1981271.3463330.1261774/D=egroupweb/S=17
> 050071
> > 81:HM/A=763352/R=0/*http://www.classmates.com/index.tf?s=5085>
>
> >
> > <http://us.adserver.yahoo.com/l?
> M=213858.1981271.3463330.1261774/D=egroupmai
> > l/S=1705007181:HM/A=763352/rand=495001293>
> >
> > To unsubscribe from this group, send an email to:
> > kakadu_jpeg2000-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> > <http://docs.yahoo.com/info/terms/> .
>
>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

HI Sebastian and Scott,

Thanks Scott for your good explanation of JP2.
It is not at all clear to me what the writer is
trying to do.  Kakadu lets you put 2 components
into a code-stream embedded in a JP2 file (just
tried it) and marks the first component as a
grey-scale image, leaving the other one undefined
as it should in the context of JP2, since there
is one colour space which can be described
(a monochrome space).

Cheers,

David

----------------------------------------
David Taubman
Senior Lecturer, School of Electrical Engineering and Telecommunications
The University of New South Wales
UNSW Sydney 2052, Australia

phone 61 2 9385-5223
fax   61 2 9385-5993

http://www.ee.unsw.edu.au/~taubman/

------------------------------------------
This message is intended for the addressee named and may contain
confidential information.  If you are not the intended recipient, please
delete it and notify the sender.  Views expressed in this message are
those of the individual sender and are not necessarily the views of
UNSW.
----- Original Message -----
From: "J. Scott Houchin" <scott.houchin@...>
To: <kakadu_jpeg2000@yahoogroups.com>
Sent: Friday, April 12, 2002 12:13 AM
Subject: Re: [kakadu_jpeg2000] KDU_EXPAND


> Hi Sebastien,
>
> I'm not familiar with the Kadaku interfaces, but from the point of
> view of the standard, here's the answer to your main question.
>
> A JP2 file is a container. Inside that container are two kinds of things
> - A compressed JPEG 2000 codestream
> - Assorted metadata that, among other things, specifies the "meaning" of
>    the data in the codestream.
>
> That codestream contains multiple 2D planes of image data, called
> components. A component has no meaning. It's just a a 2D plane of
> image data. It's not greyscale data, or red channel data, ... It's
> just data.
>
> The JP2 data structures then specify meaning for those components.
> However, before it can do that, it must deal with things like
> palettization, which will create multiple planes of image data from a
> single component.
>
> That's where channels come in.
>
> A channel is an abstraction of a component that allows for "virtual
> components" (components that are not physically stored in the file.
> For example, if I have an index color image, there is a virtual red
> component in the JP2 file, created by applying the red palette to the
> single component in the codestream. It is also possible to clone a
> component through the use of channels (we're not sure there are
> really any good reasons to do this, but it is allowed for coding
> simplicity as well as to avoid having unintended loopholes in the
> standard).
>
> The set of physical components and virtual components that are
> exposed to the part of the JP2 file that assigns meaning to data are
> collectively referred to as channels. In your example, if I had two
> components in a single file, then I would in general have two
> channels. However, the number of channels is not necessarily equal to
> the sum of the number of physical components and the number of
> virtual components. Consider that Index RGB image, for example. In
> that JP2 file, three virtual components will be created (R, G and B).
> However, in general, the physical component that contains the index
> data will not be assigned meaning, other than its use to create other
> image planes. In this case, there would only be three channels in the
> file.
>
> Once a set of channels have been defined (in the JP2 file), meaning
> is assigned. For each channel, two things are defined:
> - Whether it's color or non-color data (such as depth or opacity)
> - If it's non-color data, the set of color channels to which this channel
>    applies. For example, it's possible to define one opacity channel to go
>    with the red and green channels, and a second to go with the blue
channel.
>
>
> As for what is specifically happening in Kakadu, someone else will have to
> answer this. However, if you want, you can send me your file and I'll take
> a look at it (please keep it small though).
>
>
> Scott Houchin
>
>
>
>
> >Hie,
> >
> >I am working for 2 months on kakadu library.
> >
> >And I've got a pb I don't understand clearly what is the diference
> >between a channel an a component.
> >
> >My goal is to make a java object for extracting from the codestream a
> >specific component at a particular resolution and a particular
> >quality.
> >
> >So I translate the Kdu_expand in java and I try to modify it but the
> >decompression process is a little bit dark.
> >I don't undestand because I compress two gray scale images in a Jp2
> >file so for me I've 2 components and each component has 1 channel.
> >But when I debug kdu_expand I've got 2 channels and 2 components.
> >
> >Could yopu help me.
> >
> >Sebastien Andreo
> >
> >
> >
> >
> >To unsubscribe from this group, send an email to:
> >kakadu_jpeg2000-unsubscribe@yahoogroups.com
> >
> >
> >
> >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
> --
>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

----- Original Message -----

From: Reid, Jim

To: 'kakadu_jpeg2000@yahoogroups.com'

Sent: Wednesday, April 10, 2002 9:07 PM

Subject: RE: [kakadu_jpeg2000] Introduction and a couple of questions.

 

Hi Steve.

 

The images I've been working with are typically in the 100-300 Meg range.

Kakada can handle these just fine. I haven't tried an image as large as yours yet,

but I recall in the Kakadu documentation, Dr. Taubman mentioning another

customer who had done so.

You should be able to achieve your desired compression ratios easily, but at 5:1 - 10:1

I'm not sure you'll see drastic differences in image quality between

JPEG 2000 and JPEG. JPEG 2000 vs. JPEG

image quality differences are far more recognizable at higher compression ratios

(lower bit rates).

Finally, I know nothing of GEO references.

 

See you,

 

Jim

jreid@... 

-----Original Message-----
From: Steve Brooks [mailto:sbrooks2@...]
Sent: Wednesday, April 10, 2002 2:22 AM
To: kakadu_jpeg2000@yahoogroups.com
Subject: [kakadu_jpeg2000] Introduction and a couple of questions.

First an introduction, my name is Steve Brooks and my interest in kakadu and JPEG2000 is

in aerial images for mapping.  I’m a self employed programmer that has developed some internal

mapping tools for a small mapping company. Currently I’m just using libtiff and geotiff to store

and compress the aerial images. Color images are around 1.2 Giga Bytes in size uncompressed. 

With jpeg compression they are around around 200-400 Mega Bytes depending on the image

and the jpeg quality setting.  

 

I haven’t got around to compiling the kakadu library yet.  I expect to here in the next couple of weeks.

My environment is Pentium 4 Windows XP and Microsoft Visual Studio 6 and 7(.Net).

 

But, before I did I had a couple of questions.

 

1. Is there anyone else working with large images and how much compression can I expect?
2. How lossy is the compression compared to jpeg?
3. Is there a Geo-reference for JPEG2000 like geotiff?

 

Thanks

 

Steve Brooks

sbrooks2@...

 

 

To unsubscribe from this group, send an email to:
kakadu_jpeg2000-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To unsubscribe from this group, send an email to:
kakadu_jpeg2000-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

thanks now it's ok

Seb

  --- "J. Scott Houchin" <scott.houchin@...> a
écrit :
<HR>
<html><body>


<tt>
Hi Sebastien,<BR>
<BR>
I'm not familiar with the Kadaku interfaces, but from
the point of <BR>
view of the standard, here's the answer to your main
question.<BR>
<BR>
A JP2 file is a container. Inside that container are
two kinds of things<BR>
- A compressed JPEG 2000 codestream<BR>
- Assorted metadata that, among other things,
specifies the &quot;meaning&quot; of<BR>
&nbsp;&nbsp; the data in the codestream.<BR>
<BR>
That codestream contains multiple 2D planes of image
data, called <BR>
components. A component has no meaning. It's just a a
2D plane of <BR>
image data. It's not greyscale data, or red channel
data, ... It's <BR>
just data.<BR>
<BR>
The JP2 data structures then specify meaning for those
components. <BR>
However, before it can do that, it must deal with
things like <BR>
palettization, which will create multiple planes of
image data from a <BR>
single component.<BR>
<BR>
That's where channels come in.<BR>
<BR>
A channel is an abstraction of a component that allows
for &quot;virtual <BR>
components&quot; (components that are not physically
stored in the file. <BR>
For example, if I have an index color image, there is
a virtual red <BR>
component in the JP2 file, created by applying the red
palette to the <BR>
single component in the codestream. It is also
possible to clone a <BR>
component through the use of channels (we're not sure
there are <BR>
really any good reasons to do this, but it is allowed
for coding <BR>
simplicity as well as to avoid having unintended
loopholes in the <BR>
standard).<BR>
<BR>
The set of physical components and virtual components
that are <BR>
exposed to the part of the JP2 file that assigns
meaning to data are <BR>
collectively referred to as channels. In your example,
if I had two <BR>
components in a single file, then I would in general
have two <BR>
channels. However, the number of channels is not
necessarily equal to <BR>
the sum of the number of physical components and the
number of <BR>
virtual components. Consider that Index RGB image, for
example. In <BR>
that JP2 file, three virtual components will be
created (R, G and B). <BR>
However, in general, the physical component that
contains the index <BR>
data will not be assigned meaning, other than its use
to create other <BR>
image planes. In this case, there would only be three
channels in the <BR>
file.<BR>
<BR>
Once a set of channels have been defined (in the JP2
file), meaning <BR>
is assigned. For each channel, two things are
defined:<BR>
- Whether it's color or non-color data (such as depth
or opacity)<BR>
- If it's non-color data, the set of color channels to
which this channel<BR>
&nbsp;&nbsp; applies. For example, it's possible to
define one opacity channel to go<BR>
&nbsp;&nbsp; with the red and green channels, and a
second to go with the blue channel.<BR>
<BR>
<BR>
As for what is specifically happening in Kakadu,
someone else will have to<BR>
answer this. However, if you want, you can send me
your file and I'll take<BR>
a look at it (please keep it small though).<BR>
<BR>
<BR>
Scott Houchin<BR>
<BR>
<BR>
<BR>
<BR>
&gt;Hie,<BR>
&gt;<BR>
&gt;I am working for 2 months on kakadu library.<BR>
&gt;<BR>
&gt;And I've got a pb I don't understand clearly what
is the diference<BR>
&gt;between a channel an a component.<BR>
&gt;<BR>
&gt;My goal is to make a java object for extracting
from the codestream a<BR>
&gt;specific component at a particular resolution and
a particular<BR>
&gt;quality.<BR>
&gt;<BR>
&gt;So I translate the Kdu_expand in java and I try to
modify it but the<BR>
&gt;decompression process is a little bit dark.<BR>
&gt;I don't undestand because I compress two gray
scale images in a Jp2<BR>
&gt;file so for me I've 2 components and each
component has 1 channel.<BR>
&gt;But when I debug kdu_expand I've got 2 channels
and 2 components.<BR>
&gt;<BR>
&gt;Could yopu help me.<BR>
&gt;<BR>
&gt;Sebastien Andreo<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;To unsubscribe from this group, send an email
to:<BR>
&gt;kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;Your use of Yahoo! Groups is subject to <a
href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a><B\
R>
<BR>
<BR>
-- <BR>
</tt>

<br>

<!-- |**|begin egp html banner|**| -->

<table border=0 cellspacing=0 cellpadding=2>
<tr bgcolor=#FFFFCC>
<td align=center><font size="-1"
color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
</tr>
<tr bgcolor=#FFFFFF>
<td align=center width=470><table border=0
cellpadding=0 cellspacing=0><tr><td align=center><font
face=arial size=-2>ADVERTISEMENT</font><br><a
href="http://rd.yahoo.com/M=194081.1994012.3473453.1261774/D=egroupweb/S=1705007\
181:HM/A=1036972/R=0/*http://www.ediets.com/start.cfm?code=3466"targe
t=_top><img
src="http://us.a1.yimg.com/us.yimg.com/a/ed/ediets/250x300_bluechair.jpg"alt="Cl\
ick
Here!" width="250" height="300"
border="0"></a></td></tr></table></td>
</tr>
<tr><td><img alt="" width=1 height=1
src="http://us.adserver.yahoo.com/l?M=194081.1994012.3473453.1261774/D=egroupmai\
l/S=1705007181:HM/A=1036972/rand=283871055"></td></tr>
</table>

<!-- |**|end egp html banner|**| -->


<br>
<tt>
To unsubscribe from this group, send an email to:<BR>
kakadu_jpeg2000-unsubscribe@yahoogroups.com<BR>
<BR>
</tt>
<br>

<br>
<tt>Your use of Yahoo! Groups is subject to the <a
href="http://docs.yahoo.com/info/terms/">Yahoo! Terms
of Service</a>.</tt>
</br>

</body></html>


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Rupal,

Send the image to my address below.
I'll take a look on Monday.
Please also send me the parameters you used to compress/decompress
using Kakadu/JasPer.
Thanks,

Jim Reid
jreid@...
(716) 422-9690



-----Original Message-----
From: mehtarupal [mailto:mehtarupal@...]
Sent: Thursday, April 11, 2002 5:42 PM
To: kakadu_jpeg2000@yahoogroups.com
Subject: [kakadu_jpeg2000] Re: JPEG2000 Compression Artifacts


Hi Jim,

Thanks for your reply. I have tried compressing this image with
jasper. I see no artifacts when compressing this image using jasper.
As far as I know, there is no way to specify any other information
like Qstep when compressing using jasper. So I just specify the
compression ratio of 10:1 for both the lib.
                 Comp Ratio         Artifacts
Kakadu Result : 10:1                Present.
Jasper results: 17:1                No Artifacts

The image is a 8-bit Unsigned CR Chest Image(792KB)
Let me know how would you like to receive this image ?

My email address is : rmehta@...

Thanks

Rupal

--- In kakadu_jpeg2000@y..., "Reid, Jim" <jreid@c...> wrote:
> Have you compared these results to those of other JPEG 2000
implementations
> (VM, JasPer, JJ2k)?
> How large are your images?
> I'd be willing to double check your results if your images
> are reasonable to send via email.
>
>
> X_________       _____
> Jim Reid
> jreid@c...
> (716) 422-9690
>
> -----Original Message-----
> From: mehtarupal [mailto:mehtarupal@y...]
> Sent: Wednesday, April 10, 2002 9:52 PM
> To: kakadu_jpeg2000@y...
> Subject: [kakadu_jpeg2000] JPEG2000 Compression Artifacts
>
>
> Hi David,
>
> I am observing some compression artifacts on CR Chest images.
> The artifacts always appear on the right hand side of the image.
> They run diagonal from right to left. It's like alternate band of
> black and white values.
>
> I have tried to compress this image at JPEG2000 10:1 compression
> ratio using different values for Qstep. We have not observed a
> pattern where increasing or decreasing the Qstep would give
> consistent results in terms of image quality. Sometimes a lower
value
> of Qstep gives the desired quality and sometimes a higher value
gives
> the same quality.
> Using kdu_compress and the same Qstep values, we see the same
> behaviour. So we are having trouble to algorithmically compute the
> appropriate Qstep.
>
> I have tried using variations in the block size, but I believe this
> problem is very specific to selection of right Qstep.
> Using rate-distortion slope values does not help to resolve these
> problems.
> Could you explain what is the relation of bitdepth to Qstep ?
>
> I have a .pgm version of the CR Chest image. Would you like to get
a
> copy of that image?
> What are the other parameters we can use to control the image
quality
> and compression ratio. We have tried using rate-distortion
threshold,
> Cmodes.., Block size...Is there any other combination that can work
> accross all images?
>
> Thanks
>
> Rupal Mehta
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Sponsor
>
> ADVERTISEMENT
>
>
<http://rd.yahoo.com/M=213858.1981271.3463330.1261774/D=egroupweb/S=17
050071
> 81:HM/A=763352/R=0/*http://www.classmates.com/index.tf?s=5085>

>
> <http://us.adserver.yahoo.com/l?
M=213858.1981271.3463330.1261774/D=egroupmai
> l/S=1705007181:HM/A=763352/rand=495001293>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@y...
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/> .


Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
kakadu_jpeg2000-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi Jim,

Thanks for your reply. I have tried compressing this image with
jasper. I see no artifacts when compressing this image using jasper.
As far as I know, there is no way to specify any other information
like Qstep when compressing using jasper. So I just specify the
compression ratio of 10:1 for both the lib.
                 Comp Ratio         Artifacts
Kakadu Result : 10:1                Present.
Jasper results: 17:1                No Artifacts

The image is a 8-bit Unsigned CR Chest Image(792KB)
Let me know how would you like to receive this image ?

My email address is : rmehta@...

Thanks

Rupal

--- In kakadu_jpeg2000@y..., "Reid, Jim" <jreid@c...> wrote:
> Have you compared these results to those of other JPEG 2000
implementations
> (VM, JasPer, JJ2k)?
> How large are your images?
> I'd be willing to double check your results if your images
> are reasonable to send via email.
>
>
> X_________       _____
> Jim Reid
> jreid@c...
> (716) 422-9690
>
> -----Original Message-----
> From: mehtarupal [mailto:mehtarupal@y...]
> Sent: Wednesday, April 10, 2002 9:52 PM
> To: kakadu_jpeg2000@y...
> Subject: [kakadu_jpeg2000] JPEG2000 Compression Artifacts
>
>
> Hi David,
>
> I am observing some compression artifacts on CR Chest images.
> The artifacts always appear on the right hand side of the image.
> They run diagonal from right to left. It's like alternate band of
> black and white values.
>
> I have tried to compress this image at JPEG2000 10:1 compression
> ratio using different values for Qstep. We have not observed a
> pattern where increasing or decreasing the Qstep would give
> consistent results in terms of image quality. Sometimes a lower
value
> of Qstep gives the desired quality and sometimes a higher value
gives
> the same quality.
> Using kdu_compress and the same Qstep values, we see the same
> behaviour. So we are having trouble to algorithmically compute the
> appropriate Qstep.
>
> I have tried using variations in the block size, but I believe this
> problem is very specific to selection of right Qstep.
> Using rate-distortion slope values does not help to resolve these
> problems.
> Could you explain what is the relation of bitdepth to Qstep ?
>
> I have a .pgm version of the CR Chest image. Would you like to get
a
> copy of that image?
> What are the other parameters we can use to control the image
quality
> and compression ratio. We have tried using rate-distortion
threshold,
> Cmodes.., Block size...Is there any other combination that can work
> accross all images?
>
> Thanks
>
> Rupal Mehta
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Sponsor
>
> ADVERTISEMENT
>
>
<http://rd.yahoo.com/M=213858.1981271.3463330.1261774/D=egroupweb/S=17
050071
> 81:HM/A=763352/R=0/*http://www.classmates.com/index.tf?s=5085>

>
> <http://us.adserver.yahoo.com/l?
M=213858.1981271.3463330.1261774/D=egroupmai
> l/S=1705007181:HM/A=763352/rand=495001293>
>
> To unsubscribe from this group, send an email to:
> kakadu_jpeg2000-unsubscribe@y...
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/> .

Jim

-----Original Message-----
From: thormaker [mailto:thormaker@...]
Sent: Thursday, April 11, 2002 12:37 PM
To: kakadu_jpeg2000@yahoogroups.com
Subject: [kakadu_jpeg2000] block_encoder does not compile on solaris using gcc/++ >=3.0

Hi,

I cannot compile any kadadu version [3.03..3.2] on solaris using a gcc
>= 3.0. It works on Linux. gcc works otherwise. Any Ideas?

best
etzard

/usr/sepp/bin/g++-3.0.2 -I../common -O -Wall -Wno-uninitialized
-mv8   -c ../coding/block_encoder.cpp \
      -o block_encoder.o
../coding/block_encoder.cpp: In member function `virtual void
   kd_block_encoder::encode(kdu_block*, bool, double, short unsigned
int)':
../coding/block_encoder.cpp:1388: Internal compiler error in
change_address, at
   emit-rtl.c:1635
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
gmake: *** [block_encoder.o] Error 1




To unsubscribe from this group, send an email to:
kakadu_jpeg2000-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi,

I cannot compile any kadadu version [3.03..3.2] on solaris using a gcc
>= 3.0. It works on Linux. gcc works otherwise. Any Ideas?

best
etzard

/usr/sepp/bin/g++-3.0.2 -I../common -O -Wall -Wno-uninitialized
-mv8   -c ../coding/block_encoder.cpp \
       -o block_encoder.o
../coding/block_encoder.cpp: In member function `virtual void
    kd_block_encoder::encode(kdu_block*, bool, double, short unsigned
int)':
../coding/block_encoder.cpp:1388: Internal compiler error in
change_address, at
    emit-rtl.c:1635
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
gmake: *** [block_encoder.o] Error 1

-----Original Message-----
From: seb_andreo [mailto:seb_andreo@...]
Sent: Thursday, April 11, 2002 9:34 AM
To: kakadu_jpeg2000@yahoogroups.com
Subject: [kakadu_jpeg2000] KDU_EXPAND

Hie,

I am working for 2 months on kakadu library.

And I've got a pb I don't understand clearly what is the diference
between a channel an a component.

My goal is to make a java object for extracting from the codestream a
specific component at a particular resolution and a particular
quality.

So I translate the Kdu_expand in java and I try to modify it but the
decompression process is a little bit dark.
I don't undestand because I compress two gray scale images in a Jp2
file so for me I've 2 components and each component has 1 channel.
But when I debug kdu_expand I've got 2 channels and 2 components.

Could yopu help me.

Sebastien Andreo




To unsubscribe from this group, send an email to:
kakadu_jpeg2000-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi Sebastien,

I'm not familiar with the Kadaku interfaces, but from the point of
view of the standard, here's the answer to your main question.

A JP2 file is a container. Inside that container are two kinds of things
- A compressed JPEG 2000 codestream
- Assorted metadata that, among other things, specifies the "meaning" of
    the data in the codestream.

That codestream contains multiple 2D planes of image data, called
components. A component has no meaning. It's just a a 2D plane of
image data. It's not greyscale data, or red channel data, ... It's
just data.

The JP2 data structures then specify meaning for those components.
However, before it can do that, it must deal with things like
palettization, which will create multiple planes of image data from a
single component.

That's where channels come in.

A channel is an abstraction of a component that allows for "virtual
components" (components that are not physically stored in the file.
For example, if I have an index color image, there is a virtual red
component in the JP2 file, created by applying the red palette to the
single component in the codestream. It is also possible to clone a
component through the use of channels (we're not sure there are
really any good reasons to do this, but it is allowed for coding
simplicity as well as to avoid having unintended loopholes in the
standard).

The set of physical components and virtual components that are
exposed to the part of the JP2 file that assigns meaning to data are
collectively referred to as channels. In your example, if I had two
components in a single file, then I would in general have two
channels. However, the number of channels is not necessarily equal to
the sum of the number of physical components and the number of
virtual components. Consider that Index RGB image, for example. In
that JP2 file, three virtual components will be created (R, G and B).
However, in general, the physical component that contains the index
data will not be assigned meaning, other than its use to create other
image planes. In this case, there would only be three channels in the
file.

Once a set of channels have been defined (in the JP2 file), meaning
is assigned. For each channel, two things are defined:
- Whether it's color or non-color data (such as depth or opacity)
- If it's non-color data, the set of color channels to which this channel
    applies. For example, it's possible to define one opacity channel to go
    with the red and green channels, and a second to go with the blue channel.


As for what is specifically happening in Kakadu, someone else will have to
answer this. However, if you want, you can send me your file and I'll take
a look at it (please keep it small though).


Scott Houchin




>Hie,
>
>I am working for 2 months on kakadu library.
>
>And I've got a pb I don't understand clearly what is the diference
>between a channel an a component.
>
>My goal is to make a java object for extracting from the codestream a
>specific component at a particular resolution and a particular
>quality.
>
>So I translate the Kdu_expand in java and I try to modify it but the
>decompression process is a little bit dark.
>I don't undestand because I compress two gray scale images in a Jp2
>file so for me I've 2 components and each component has 1 channel.
>But when I debug kdu_expand I've got 2 channels and 2 components.
>
>Could yopu help me.
>
>Sebastien Andreo
>
>
>
>
>To unsubscribe from this group, send an email to:
>kakadu_jpeg2000-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


--

Hie,

I am working for 2 months on kakadu library.

And I've got a pb I don't understand clearly what is the diference
between a channel an a component.

My goal is to make a java object for extracting from the codestream a
specific component at a particular resolution and a particular
quality.

So I translate the Kdu_expand in java and I try to modify it but the
decompression process is a little bit dark.
I don't undestand because I compress two gray scale images in a Jp2
file so for me I've 2 components and each component has 1 channel.
But when I debug kdu_expand I've got 2 channels and 2 components.

Could yopu help me.

Sebastien Andreo

X_________       _____
Jim Reid
jreid@...
(716) 422-9690

-----Original Message-----
From: mehtarupal [mailto:mehtarupal@...]
Sent: Wednesday, April 10, 2002 9:52 PM
To: kakadu_jpeg2000@yahoogroups.com
Subject: [kakadu_jpeg2000] JPEG2000 Compression Artifacts

Hi David,

I am observing some compression artifacts on CR Chest images.
The artifacts always appear on the right hand side of the image.
They run diagonal from right to left. It's like alternate band of
black and white values.

I have tried to compress this image at JPEG2000 10:1 compression
ratio using different values for Qstep. We have not observed a
pattern where increasing or decreasing the Qstep would give
consistent results in terms of image quality. Sometimes a lower value
of Qstep gives the desired quality and sometimes a higher value gives
the same quality.
Using kdu_compress and the same Qstep values, we see the same
behaviour. So we are having trouble to algorithmically compute the
appropriate Qstep.

I have tried using variations in the block size, but I believe this
problem is very specific to selection of right Qstep.
Using rate-distortion slope values does not help to resolve these
problems.
Could you explain what is the relation of bitdepth to Qstep ?

I have a .pgm version of the CR Chest image. Would you like to get a
copy of that image?
What are the other parameters we can use to control the image quality
and compression ratio. We have tried using rate-distortion threshold,
Cmodes.., Block size...Is there any other combination that can work
accross all images?

Thanks

Rupal Mehta










To unsubscribe from this group, send an email to:
kakadu_jpeg2000-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi David,

I am observing some compression artifacts on CR Chest images.
The artifacts always appear on the right hand side of the image.
They run diagonal from right to left. It's like alternate band of
black and white values.

I have tried to compress this image at JPEG2000 10:1 compression
ratio using different values for Qstep. We have not observed a
pattern where increasing or decreasing the Qstep would give
consistent results in terms of image quality. Sometimes a lower value
of Qstep gives the desired quality and sometimes a higher value gives
the same quality.
Using kdu_compress and the same Qstep values, we see the same
behaviour. So we are having trouble to algorithmically compute the
appropriate Qstep.

I have tried using variations in the block size, but I believe this
problem is very specific to selection of right Qstep.
Using rate-distortion slope values does not help to resolve these
problems.
Could you explain what is the relation of bitdepth to Qstep ?

I have a .pgm version of the CR Chest image. Would you like to get a
copy of that image?
What are the other parameters we can use to control the image quality
and compression ratio. We have tried using rate-distortion threshold,
Cmodes.., Block size...Is there any other combination that can work
accross all images?

Thanks

Rupal Mehta

-----Original Message-----
From: Steve Brooks [mailto:sbrooks2@...]
Sent: Wednesday, April 10, 2002 2:22 AM
To: kakadu_jpeg2000@yahoogroups.com
Subject: [kakadu_jpeg2000] Introduction and a couple of questions.

First an introduction, my name is Steve Brooks and my interest in kakadu and JPEG2000 is

in aerial images for mapping.  I’m a self employed programmer that has developed some internal

mapping tools for a small mapping company. Currently I’m just using libtiff and geotiff to store

and compress the aerial images. Color images are around 1.2 Giga Bytes in size uncompressed. 

With jpeg compression they are around around 200-400 Mega Bytes depending on the image

and the jpeg quality setting.  

 

I haven’t got around to compiling the kakadu library yet.  I expect to here in the next couple of weeks.

My environment is Pentium 4 Windows XP and Microsoft Visual Studio 6 and 7(.Net).

 

But, before I did I had a couple of questions.

 

1. Is there anyone else working with large images and how much compression can I expect?
2. How lossy is the compression compared to jpeg?
3. Is there a Geo-reference for JPEG2000 like geotiff?

 

Thanks

 

Steve Brooks

sbrooks2@...

 

 

To unsubscribe from this group, send an email to:
kakadu_jpeg2000-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi,

We're developing several Freewares and Sharewares based on kakadu.
Congratulations to David and his team, this is a very good product,
efficient, stable, well documented, always up-to-date.

http://www.morgan-multimedia.com/JPEG2000
http://www.morgan-multimedia.com/MJPEG2000
http://www.morgan-multimedia.com
http://www.morgan-multimedia.fr

-guillaume

Dear group members:
I have studied EBCOT and MQ-coder for a few month. but I didn't test
the process of EBCOT and MQ. How can I get the bit stream from
kakadu's code? I means I want to know that quantization index was
encoded to context and  the context convert to bit stream.

thanks
gavin chung

An introduction ...
Jim Reid here - Kakadu user for about a year now ...
I work for Xerox, and we have a full commercial license.
I've built several applications so far on top of Kakadu, and
I like it (Kakadu) very much.


X_________       _____
Jim Reid
jreid@...
(716) 422-9690