Hello everybody,

I can get lossless compression by using the following command:

kdu_compress -i  INNametif  -o INName.jp2 Creversible=yes -rate ¨C       (1)

and decompressed by using:

kdu_expand  -fprec 16  -i  INName.jp2 -o  bandnametif                                 (2)

by using uncompressed TIFF images. Thanks David, I could get the original image back.

==========================================================================================================

I have another question about rate. This time I want to perform lossy compression, for example at rate 2.0 by using the following command:

kdu_compress -i  INNametif  -o INName.jp2 -rate 2.0                                     (3)

and decompressed using (2) above, and calculate the SNR by using the following equation:

10*log10(summation(f"(x,y,z))/summation(f"(x,y,z)-f(x,y,z))                                                   (4)

Note: My image is Hyperspectral image that is from AVIRIS. f" is the decompressed Hyperspectral image, and f is the original image.

And I've got 32.75 dB. Then I change the rate to 1.0 in (3) and I still got the same value of SNR.

Maybe I'm not understand what is rate here, or maybe it is not the same rate as discussed in popular topic nowadays, Hyperspectral Image Compression when people are using Kakadu. I really hope that somebody could point me out from this problem.

Best regards,

Rizuan

Hi,

We have two machines both running Windows server 2003 64bit SP2 with similar
spec cpu's. One runs decompression upto 50% faster.

Dell Precision T3500 Workstation Spec:
-Single Intel QuadCore W3520
-4GB RAM

Dell R710 Spec:
-Dual Intel QuadCore X5560
-48GB Ram

The T3500 shows up to 50% better performance on decompression and we are a bit
stumped.

We have managed to simplify this down to a single executable that does 1000
decompressions in memory of a 512k file with a different number of threads
(Hyper threading was off). The results are as follows:

Threads T3500(ms) R710 (ms)
1       26.8     26.1
2       15       15.0 or 23.2*
4       10.3     15.5
6       12.1     14.2
7       13.3     19.2
8       13.3     19
16      14.4     21

* Quite variable results either around 15ms or 23.2 ms

So far we have tried a range of things including:
-Windows Server 2008 64 bit vs Windows 2003 64 bit
-Combinations of CPU affinitity, hyperthreading and threads
-Combinations of RAM

Speed pack version is vs6_1_2. Any thoughts on what might be causing the
performance difference will be greatly appreciated.

Kind Regards

Paul

I vaguely remember that is a general confuision with 16bits PGM. Most
people assume this is little endian, while PGM specs says it should be
big endian. Maybe there is something like that going on here...

On Wed, Nov 25, 2009 at 4:20 PM, Roland Sweet <roland.sweet@...> wrote:
> Mathieu,
>
> I was referring to kdu_compress, not kdu_expand.  Curiously, kdu_expand will
> write 16-bit pgm files, but not read them!
>
> Roland
>
> ----- Original Message -----
> From: "Mathieu Malaterre" <mathieu.malaterre@...>
> To: <kakadu_jpeg2000@yahoogroups.com>
> Sent: Tuesday, November 24, 2009 3:45 PM
> Subject: Re: [kakadu_jpeg2000] kdu_compress and kdu_expand for 16-bit .pgm
> file
>
>
> kdu_expand has been working great for me so far. Even for 16bits, I am
> using the linux binaries.
>
> On Tue, Nov 24, 2009 at 10:40 PM, Roland Sweet <roland.sweet@...>
> wrote:
>>
>>
>>
>> Rizuan,
>>
>> Even though the pgm file format supports 16-bit input, the code in
>> kdu_compress (class pgm_in in image_in.cpp, line 1073) only supports
>> 8-bits. You will have to modify that code to get it to encode 16-bit
>> images correctly.
>>
>> Roland
>>
>> *************************
>>
>> Hello Dr. David Taubman and everyone else,
>>
>> I'm a beginner in Kakadu, and I just want to use Kakadu to perform
>> lossless compression for the moment. I want to compress 16-bit .pgm file
>> to j2c. The image is not a color image, just greyscale that values varying
>> from 0 to 65535. I've tried to use the command line below:
>>
>> kdu_compress -i band12.pgm -o band12.j2c Creversible=yes -rate 1.0
>>
>> However, I couldn't get the original image back by using the following
>> kdu_expand
>>
>> kdu_expand -i band12.j2c -o band12.pgm
>>
>> and the resulting band12.pgm file was 8-bit image, not the original 16-bit
>> image.
>>
>> I'm sorry if this question is too basic, but I really need an answer. I've
>> used JPEG-LS program (locoe, loco16e,locod, loco16d) that have special 16
>> bit operation. Is this similar with Kakadu?
>>
>> Many thanks for your attention
>>
>> Rizuan
>>
>>
>
>
> --
> Mathieu
>
>
> ------------------------------------
>
> For problems with your subscription in this group please email
> kakadu_jpeg2000-owner@yahoogroups.com.
> Yahoo! Groups Links
>
>
>
>
>
> ------------------------------------
>
> For problems with your subscription in this group please email
> kakadu_jpeg2000-owner@yahoogroups.com.
> Yahoo! Groups Links
>
>
>
>



--
Mathieu

Mathieu,

I was referring to kdu_compress, not kdu_expand.  Curiously, kdu_expand will
write 16-bit pgm files, but not read them!

Roland

----- Original Message -----
From: "Mathieu Malaterre" <mathieu.malaterre@...>
To: <kakadu_jpeg2000@yahoogroups.com>
Sent: Tuesday, November 24, 2009 3:45 PM
Subject: Re: [kakadu_jpeg2000] kdu_compress and kdu_expand for 16-bit .pgm
file


kdu_expand has been working great for me so far. Even for 16bits, I am
using the linux binaries.

On Tue, Nov 24, 2009 at 10:40 PM, Roland Sweet <roland.sweet@...>
wrote:
>
>
>
> Rizuan,
>
> Even though the pgm file format supports 16-bit input, the code in
> kdu_compress (class pgm_in in image_in.cpp, line 1073) only supports
> 8-bits. You will have to modify that code to get it to encode 16-bit
> images correctly.
>
> Roland
>
> *************************
>
> Hello Dr. David Taubman and everyone else,
>
> I'm a beginner in Kakadu, and I just want to use Kakadu to perform
> lossless compression for the moment. I want to compress 16-bit .pgm file
> to j2c. The image is not a color image, just greyscale that values varying
> from 0 to 65535. I've tried to use the command line below:
>
> kdu_compress -i band12.pgm -o band12.j2c Creversible=yes -rate 1.0
>
> However, I couldn't get the original image back by using the following
> kdu_expand
>
> kdu_expand -i band12.j2c -o band12.pgm
>
> and the resulting band12.pgm file was 8-bit image, not the original 16-bit
> image.
>
> I'm sorry if this question is too basic, but I really need an answer. I've
> used JPEG-LS program (locoe, loco16e,locod, loco16d) that have special 16
> bit operation. Is this similar with Kakadu?
>
> Many thanks for your attention
>
> Rizuan
>
>


--
Mathieu


------------------------------------

For problems with your subscription in this group please email
kakadu_jpeg2000-owner@yahoogroups.com.
Yahoo! Groups Links

Hello Mathieu and Roland,

Thanks for replies. I don't have the library of Kakadu Software, just use the
kdu_compress and kdu_expand.

I was thinking about using the .raw since that is the only method that explain
about 16-bit coding. Can anyone explain about the Ssize, Scomponents, Ssigned,
and Sprecision arguments? I only know about Sprecision that is 16. Where to find
these information?

kdu_compress -i image.raw -o out.bits Sprecision=16 Ssigned=no
                  Sdims={1024,800} Qstep=0.0001 -rate 1.0

For your information, my image is 512x512, 16-bit, uint16 and I'm using Matlab
to generate the .raw file of the image. I've tried to use this method anyway.
But after kdu_expand, the resulting image is still 8-bit. I'm targetting for
lossless compression first.

Many thanks for your attention, guys. Really appreciate it.

Rizuan



--- In kakadu_jpeg2000@yahoogroups.com, "RolandS" <roland.sweet@...> wrote:
>
>
> Rizuan,
>
> Here is another suggestion.  Strip the header off of the pgm file and make it
into a raw file--just the image pixels.  Rename that file as a .raw (or rawl)
file and use that as input to kdu_compress.  You will have to specify the Ssize,
Scomponents, Ssigned, and Sprecision arguments.  Be careful with the endianess
of your data--big-endian for most-significant-byte first versus little-endian
for least-significant byte first.  Good luck!
>
> An alternative would be to try to find an image processing program that will
convert pgm to another format such as tif.
>
> Roland
>
> --- In kakadu_jpeg2000@yahoogroups.com, "norrizuan" <norrizuan@> wrote:
> >
> > Hello Dr. David Taubman and everyone else,
> >
> > I'm a beginner in Kakadu, and I just want to use Kakadu to perform lossless
compression for the moment. I want to compress 16-bit .pgm file to j2c. The
image is not a color image, just greyscale that values varying from 0 to 65535.
I've tried to use the command line below:
> >
> > kdu_compress -i band12.pgm -o band12.j2c Creversible=yes -rate 1.0
> >
> > However, I couldn't get the original image back by using the following
kdu_expand
> >
> > kdu_expand -i band12.j2c -o band12.pgm
> >
> > and the resulting band12.pgm file was 8-bit image, not the original 16-bit
image.
> >
> > I'm sorry if this question is too basic, but I really need an answer. I've
used JPEG-LS program (locoe, loco16e,locod, loco16d) that have special 16 bit
operation. Is this similar with Kakadu?
> >
> > Many thanks for your attention
> >
> > Rizuan
> >
>

The problem here is your concept of what -rate means.
-rate 1.0 will give you a 1 bit per pixel file, i.e. not lossless.
The kdu_compress rate parameter indicates bitrate, not a percentage of original
filesize.

If you want the file to be lossless you need either omit the -rate option
entirely or else set it to '-' as in '-rate -', both of which mean use all the
bits available.  (If you want layers at lower bitrates in addition to lossless,
try
-rate -,r1,r2,...


--- In kakadu_jpeg2000@yahoogroups.com, "norrizuan" <norrizuan@...> wrote:
>
> Hello Dr. David Taubman and everyone else,
>
> I'm a beginner in Kakadu, and I just want to use Kakadu to perform lossless
compression for the moment. I want to compress 16-bit .pgm file to j2c. The
image is not a color image, just greyscale that values varying from 0 to 65535.
I've tried to use the command line below:
>
> kdu_compress -i band12.pgm -o band12.j2c Creversible=yes -rate 1.0
>
> However, I couldn't get the original image back by using the following
kdu_expand
>
> kdu_expand -i band12.j2c -o band12.pgm
>
> and the resulting band12.pgm file was 8-bit image, not the original 16-bit
image.
>
> I'm sorry if this question is too basic, but I really need an answer. I've
used JPEG-LS program (locoe, loco16e,locod, loco16d) that have special 16 bit
operation. Is this similar with Kakadu?
>
> Many thanks for your attention
>
> Rizuan
>

Thank you Dr. Taubman,

You are correct, all my test systems are 32 bit architecture.

Also, our compression ratios are at most 5 to 1, so that probably qualifies as
very low bit rate.

In my code I'm presently not using KDU_SOURCE_CAP_SEEKABLE. I had forgotten that
I had previously disabled it (fixed now). I think I disabled it early on when I
had some bad codestreams and it seemed to interfere with error reporting (that
shouldn't be a problem anymore).

Thank you for your help.

Ciro.

--- In kakadu_jpeg2000@yahoogroups.com, David Taubman <d.taubman@...> wrote:
>
> Hi,
>
> I have no problem with you sharing source code for your project
> (not the Kakadu source code, though).
>
> Your observations leave me with a lot of questions.
>
> Firstly, the architecture is important to speed-pack.  You will get the full
> benefits of speed-pack on Intel architectures with 64-bit builds.  What
> that means is that your OS would be OSX 10.4 or later, some flavour
> of Win64 or some flavour of Linux x86_64.  I suspect that you are
> not running 64-bit binaries, especially if you are invoking everything as
> a plug-in dynamic library loaded from another application (such as
> quick-time), since then that application must be running in 64-bit mode.
> For example, if you build a universal binary on OSX with LIPO (happens
> automatically under Xcode, and the Kakadu make files also do this), the
> application will load the version which matches its architecture, which
> is likely to be 32-bit (although Quicktime on OSX 10.6 is almost certainly
> a 64-bit app).
>
> Secondly, images compressed at very low bit-rates will benefit less
> from speed-pack (but should still benefit) than images compressed
> at higher bit-rates.
>
> Thirdly, if your source is in memory, I suggest you make sure
> it advertises the `KDU_SOURCE_CAP_IN_MEMORY' capability,
> along with `KDU_SOURCE_CAP_SEEKABLE'.
>
> Finally, when testing the performance of some sample code, you
> might like to also verify the performance of the Kakadu demo executables
> on the same images, for reference.  For example, you might find that
> the full speed-up is achieved with `kdu_expand' on some images of
> interest and a slightly different speed-up is achieved with
> `kdu_buffered_expand'.  This may help point to inefficiencies in your
> design, because each time data is converted needlessly from one form
> to another (even though it seems convenient) there are overheads.
>
> Cheers,
> David
>
>
> On 24/11/2009, at 6:42 AM, cornejoc wrote:
>
> Hi all,
>
> I've noticed some performance anomalies while developing a J2K decompressor
for Apple QuickTime.
>
> The issue is that on a low end machine Kakadu Speedpack S6_3_1 seems to be
slower than Kakadu non-speedpack 6_3_1. On a dual core machine, however, the
speedpack version is about 10% faster than the non-speedpack version.
>
> In my application performance is very important, so I'm now worried that I'm
probably doing something wrong.
>
> I'm using the stripe decompressor and doing memory to memory decompression.
All my builds have KDU_PENTIUM_MSVC on Windows, and KDU_MAC_SPEEDUPS on Macs.
>
> I would like to know what I'm doing wrong, or what I can improve. I'm hoping
that someone will tell me about that special trick to get speedpack going.
>
> This is how I call kakadu:
>
> source.set_source ((kdu_byte *) jpeg_data, jpeg_size);
> codestream.create (& source, & threads);
> codestream.apply_input_restrictions (0, 3,
>                                     discard_levels,
>                                     0, NULL, KDU_WANT_CODESTREAM_COMPONENTS);
> codestream.set_fast ();
> codestream.set_block_truncation (truncation_factor);
>
> kdu_dims dims;
> codestream.get_dims (0, dims);
> int stripe_heights [3] = {dims.size.y, dims.size.y, dims.size.y};
> int sample_offsets [3] = {1, 0, 2};        // Default is {0, 1, 2}, first
component at 1, next at 0, ...
> int sample_gaps [3]    = {2, 4, 4};        // Default is {3, 3, 3}, number of
components (3).
> int row_gaps [3]       = {gap, gap, gap};  // Default is {3w, 3w, 3w}, number
of components * width.
> int precisions [3]     = {8, 8, 8};        // Default is {8, 8, 8}, Must be
between 1 and 8 inclusive [1..8].
>
> try
> {
>    decompressor.start (codestream,
>                        false,       // Force precise, default is false.
>                        true,        // Want fastest, default is false.
>                        & threads);  // Threading environment, default is NULL.
>
>    decompressor.pull_stripe (target, stripe_heights, sample_offsets,
sample_gaps, row_gaps, precisions);
>    decompressor.finish ();
>    codestream.destroy ();
> }
>
> Also, if I can get Dr Taubman's permission, I would like to post my entire
project.
>
> My hope is to share a fun project, get more and better feedback, and of course
promote Kakadu and JPEG2000.
>
>
>
>
> ------------------------------------
>
> For problems with your subscription in this group please email
>
kakadu_jpeg2000-owner@yahoogroups.com<mailto:kakadu_jpeg2000-owner@...\
om>.
> Yahoo! Groups Links
>
>
>
>
> --
> Professor David Taubman
> Head, Telecommunications Research Group
> School of Electrical Engineering and Telecommunications
> The University of New South Wales
> UNSW, Sydney, NSW 2052, Australia
> d.taubman@...<mailto:d.taubman@...>
>

Rizuan,

Here is another suggestion.  Strip the header off of the pgm file and make it
into a raw file--just the image pixels.  Rename that file as a .raw (or rawl)
file and use that as input to kdu_compress.  You will have to specify the Ssize,
Scomponents, Ssigned, and Sprecision arguments.  Be careful with the endianess
of your data--big-endian for most-significant-byte first versus little-endian
for least-significant byte first.  Good luck!

An alternative would be to try to find an image processing program that will
convert pgm to another format such as tif.

Roland

--- In kakadu_jpeg2000@yahoogroups.com, "norrizuan" <norrizuan@...> wrote:
>
> Hello Dr. David Taubman and everyone else,
>
> I'm a beginner in Kakadu, and I just want to use Kakadu to perform lossless
compression for the moment. I want to compress 16-bit .pgm file to j2c. The
image is not a color image, just greyscale that values varying from 0 to 65535.
I've tried to use the command line below:
>
> kdu_compress -i band12.pgm -o band12.j2c Creversible=yes -rate 1.0
>
> However, I couldn't get the original image back by using the following
kdu_expand
>
> kdu_expand -i band12.j2c -o band12.pgm
>
> and the resulting band12.pgm file was 8-bit image, not the original 16-bit
image.
>
> I'm sorry if this question is too basic, but I really need an answer. I've
used JPEG-LS program (locoe, loco16e,locod, loco16d) that have special 16 bit
operation. Is this similar with Kakadu?
>
> Many thanks for your attention
>
> Rizuan
>

kdu_expand has been working great for me so far. Even for 16bits, I am
using the linux binaries.

On Tue, Nov 24, 2009 at 10:40 PM, Roland Sweet <roland.sweet@...> wrote:
>
>
>
> Rizuan,
>
> Even though the pgm file format supports 16-bit input, the code in
kdu_compress (class pgm_in in image_in.cpp, line 1073) only supports 8-bits. 
You will have to modify that code to get it to encode 16-bit images correctly.
>
> Roland
>
> *************************
>
> Hello Dr. David Taubman and everyone else,
>
> I'm a beginner in Kakadu, and I just want to use Kakadu to perform lossless
compression for the moment. I want to compress 16-bit .pgm file to j2c. The
image is not a color image, just greyscale that values varying from 0 to 65535.
I've tried to use the command line below:
>
> kdu_compress -i band12.pgm -o band12.j2c Creversible=yes -rate 1.0
>
> However, I couldn't get the original image back by using the following
kdu_expand
>
> kdu_expand -i band12.j2c -o band12.pgm
>
> and the resulting band12.pgm file was 8-bit image, not the original 16-bit
image.
>
> I'm sorry if this question is too basic, but I really need an answer. I've
used JPEG-LS program (locoe, loco16e,locod, loco16d) that have special 16 bit
operation. Is this similar with Kakadu?
>
> Many thanks for your attention
>
> Rizuan
>
>


--
Mathieu

Hello Dr. David Taubman and everyone else,

I'm a beginner in Kakadu, and I just want to use Kakadu to perform lossless
compression for the moment. I want to compress 16-bit .pgm file to j2c. The
image is not a color image, just greyscale that values varying from 0 to 65535.
I've tried to use the command line below:

kdu_compress -i band12.pgm -o band12.j2c Creversible=yes -rate 1.0

However, I couldn't get the original image back by using the following
kdu_expand

kdu_expand -i band12.j2c -o band12.pgm

and the resulting band12.pgm file was 8-bit image, not the original 16-bit
image.

I'm sorry if this question is too basic, but I really need an answer. I've used
JPEG-LS program (locoe, loco16e,locod, loco16d) that have special 16 bit
operation. Is this similar with Kakadu?

Many thanks for your attention

Rizuan

Hi everyone,

Just wanted to pass on some results after playing with using the kakadu
thread features.  This is orthorectifying an nitf image (Quick Bird)
using rpc model doing dynamic elevation look ups.

// Source image size:
$ ls -lh 10DEC05QB.ntf
393M

// One thread:
$ ossim-orthoigen --writer-prop threads=1 -w ossim_kakadu_jp2
10DEC05QB.ntf t2.jp2
100%
Time elapsed: 89

// Four threads (all cpu's light up in system monitor):
$ ossim-orthoigen --writer-prop threads=4 -w ossim_kakadu_jp2
10DEC05QB.ntf t2.jp2
100%
Time elapsed: 50

// Output image size, with 9 levels to take if below 64x64 tile:
$ ls -lh t2.jp2
118M

I know the results are not linear but they are exiting as the ossim code
is not threaded.

Anyway just thought I'd share...

Take care,
Dave

 

Hi Dave,

In Part-2 (i.e., JPX files), you can use a 4-component

colour space, which might be more appropriate.  However,

Part-1 (JP2 files) only supports 1 and 3 component colour

spaces.  The mapping is constructed from a combination

of the information in `jp2_channels' and `jp2_colour'.  The

first one maps decompressed image components to channels

(possibly through a palette), which can include colour channels,

opacity channels and pre-multiplied opacity channels.  The

second one provides an interpretation for the colour channels.

There is nothing wrong with having a JP2 file whose embedded

codestream has more image components, but JP2 does not

provide you with a means for describing the colour representation

associated with all those channels.  So, for example, you can

set up a single colour channel and initialize the colour space to

JP2_sLUM_SPACE, while having 3 additional image components

which have meaning to you -- you just can't describe the meaning

to other people in a generic way, without resorting to JPX.

You can try compressing a CMYK TIFF file with kdu_compress

and you will find that you successfully compress this thing to

a JPX file.  Personally, I don't see any reason to restrict yourself

to JP2.  It may be that Kakadu's JPX implementation does not

allow you to set up 4-colour (unrestricted) ICC profiles.  If so, that

is an oversight, because Kakadu otherwise provides extremely

broad coverage for JPX.

Hope this helps.

David

On 23/11/2009, at 8:48 AM, David Burken wrote:

Hi,

I'm trying to write an 4 band jp2 file and I'm having issues with color
space and channels.  Note the 4th band is not an alpha.

When I do:

colour.init( JP2_sLUM_SPACE );

I get on write:

Error in Kakadu File Format Support:
A `jp2_channels' object indicates the presence of more colour channels
than the
number which is associated with the specified colour space.  This may happen
while reading a JP2-family data source which contains an illegal channel
definitions (cdef) box, or it may happen while writing a JP2-family file
if the
`jp2_channels' object has been incorrectly initialized.
ossimIgen::outputProduct ERROR:
Unknown exception caught!

So I was looking at using the jp2_colour::init(kdu_byte *icc_profile);

But now I see in class j2_icc_profile:

int num_colours; // must be either 1 or 3.

With my nitf j2k writer I can compress 4 bands with no problem so I know
this is a jp2 issue.

Is there a simple way to do this?

If it helps you can see the source code for this at:

http://trac.osgeo.org/ossim/browser/trunk/ossim_plugins/kakadu/ossimKakaduCompressor.cpp

Any help appreciated...

Take care,
Dave






------------------------------------

For problems with your subscription in this group please email
kakadu_jpeg2000-owner@yahoogroups.com.
Yahoo! Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/kakadu_jpeg2000/

<*> Your email settings:
   Individual Email | Traditional

<*> To change settings online go to:
   http://groups.yahoo.com/group/kakadu_jpeg2000/join
   (Yahoo! ID required)

<*> To change settings via email:
   kakadu_jpeg2000-digest@yahoogroups.com
   kakadu_jpeg2000-fullfeatured@yahoogroups.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/

--

Professor David Taubman

Head, Telecommunications Research Group

School of Electrical Engineering and Telecommunications

The University of New South Wales

UNSW, Sydney, NSW 2052, Australia

d.taubman@unsw.edu.au

Hi,

I'm trying to write an 4 band jp2 file and I'm having issues with color
space and channels.  Note the 4th band is not an alpha.

When I do:

colour.init( JP2_sLUM_SPACE );

I get on write:

Error in Kakadu File Format Support:
A `jp2_channels' object indicates the presence of more colour channels
than the
number which is associated with the specified colour space.  This may happen
while reading a JP2-family data source which contains an illegal channel
definitions (cdef) box, or it may happen while writing a JP2-family file
if the
`jp2_channels' object has been incorrectly initialized.
ossimIgen::outputProduct ERROR:
Unknown exception caught!

So I was looking at using the jp2_colour::init(kdu_byte *icc_profile);

But now I see in class j2_icc_profile:

int num_colours; // must be either 1 or 3.

With my nitf j2k writer I can compress 4 bands with no problem so I know
this is a jp2 issue.

Is there a simple way to do this?

If it helps you can see the source code for this at:

http://trac.osgeo.org/ossim/browser/trunk/ossim_plugins/kakadu/ossimKakaduCompre\
ssor.cpp

Any help appreciated...

Take care,
Dave

Hi all,

I've noticed some performance anomalies while developing a J2K decompressor for
Apple QuickTime.

The issue is that on a low end machine Kakadu Speedpack S6_3_1 seems to be
slower than Kakadu non-speedpack 6_3_1. On a dual core machine, however, the
speedpack version is about 10% faster than the non-speedpack version.

In my application performance is very important, so I'm now worried that I'm
probably doing something wrong.

I'm using the stripe decompressor and doing memory to memory decompression. All
my builds have KDU_PENTIUM_MSVC on Windows, and KDU_MAC_SPEEDUPS on Macs.

I would like to know what I'm doing wrong, or what I can improve. I'm hoping
that someone will tell me about that special trick to get speedpack going.

This is how I call kakadu:

source.set_source ((kdu_byte *) jpeg_data, jpeg_size);
codestream.create (& source, & threads);
codestream.apply_input_restrictions (0, 3,
                                      discard_levels,
                                      0, NULL, KDU_WANT_CODESTREAM_COMPONENTS);
codestream.set_fast ();
codestream.set_block_truncation (truncation_factor);

kdu_dims dims;
codestream.get_dims (0, dims);
int stripe_heights [3] = {dims.size.y, dims.size.y, dims.size.y};
int sample_offsets [3] = {1, 0, 2};        // Default is {0, 1, 2}, first
component at 1, next at 0, ...
int sample_gaps [3]    = {2, 4, 4};        // Default is {3, 3, 3}, number of
components (3).
int row_gaps [3]       = {gap, gap, gap};  // Default is {3w, 3w, 3w}, number of
components * width.
int precisions [3]     = {8, 8, 8};        // Default is {8, 8, 8}, Must be
between 1 and 8 inclusive [1..8].

try
{
     decompressor.start (codestream,
                         false,       // Force precise, default is false.
                         true,        // Want fastest, default is false.
                         & threads);  // Threading environment, default is NULL.

     decompressor.pull_stripe (target, stripe_heights, sample_offsets,
sample_gaps, row_gaps, precisions);
     decompressor.finish ();
     codestream.destroy ();
}

Also, if I can get Dr Taubman's permission, I would like to post my entire
project.

My hope is to share a fun project, get more and better feedback, and of course
promote Kakadu and JPEG2000.

Dieter --

I don't have a direct answer, but my own experiments with lossless JPEG2000 are
documented at:

   http://dltj.org/article/lossless-jpeg2000/

Perhaps that might be of some help...


Peter
--
Peter Murray                            http://www.pandc.org/peter/work/
Assistant Director, New Service Development    *NEW* tel:+1-614-485-6725
OhioLINK: the Ohio Library and Information Network        Columbus, Ohio
The Disruptive Library Technology Jester                http://dltj.org/
Attrib-Noncomm-Share   http://creativecommons.org/licenses/by-nc-sa/2.5/

Dear all,

we are running some tests to use JPEG2000 as the master format to store the
scans of our archives.  We'd like to replace TIFF lossless with JPEG2000
lossless.  As you might know, there are some ways to convert TIFFs into
JPEG2000.  One is using the Kakadu library, another one JasPer, as used in
ImageMagick.

I have encoded a sample TIFF using Kakadu, using the following options:
(defaults as used by 
[url=http://sourceforge.net/apps/mediawiki/djatoka/index.php?title=Compression_P\
roperties]Djatoka[/url]:

[code]slope=51651,51337,51186,50804,50548,50232
Clayers=6
Creversible=yes
Cprecincts={256,256},{256,256},{128,128}
[/code]

This results in an image of 1231 kb.

Converting the same TIFF with ImageMagick, using [code]>convert 0001.tif
-compress Lossless -quality 100 0001.jp2[/code]
results in a 6485kb image.

If I compare both files using IM's compare function, combined with "-metric AE",
there are 4.75701e+006 different pixels...
Comparing the original TIFF with a decompressed TIFF-version of the Kakadu JP2,
gives the same error rate...

However, both should be lossless (and according to the properties of the files -
obtained with kdu_show), both images have been lossless encoded (Creversible =
yes)...

Does anyone have an explanation for this quite odd behaviour?

Thanks a lot,
dieter

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

From: kasana_s

To: kakadu_jpeg2000@yahoogroups.com

Sent: Sunday, November 15, 2009 4:58 AM

Subject: [kakadu_jpeg2000] header related question

 

Hi
I have a doubt about the header bytes used by Kakadu. Suppose I have an image of 128x128 and I want to compress it at the rate of 1 bit per pixel. So the compressed image will have total 2048 bytes. Then the bytes of jpeg2000 header is included in this total bytes or header bytes are extra.
In Kakadu, is there any command to find the total no of bytes consumed by the header? or I have to go through its code?

Thanks

Hi
I have a doubt about the header bytes used by Kakadu. Suppose I have an image of
128x128 and I want to compress it at the rate of 1 bit per pixel. So the
compressed image will have total 2048 bytes. Then the bytes of jpeg2000 header
is included in this total bytes or header bytes are extra.
In Kakadu, is there any command to find the total no of bytes consumed by the
header? or I have to go through its code?

Thanks

Hi,

I am trying to modify kdu_show such that the client can request multiple JP2
streams from different servers, which host a particular image, and then merge
those streams to form that image. My initial approach was to break down a
client's window request to smaller ones and then issue each of the smaller
request to a different server, but after looking at the code for kdu_client, I'm
not sure how to go about it. I was hoping to get some feedback from the
discussion group to see if anybody has an idea or an approach that could help me
with this. How can I modify kdu_client to support this feature?

Thanks,

Sajjad

Michael
This is exactly what I need to do.
(I have an image in memory that was created from
another source.

David suggested deriving from the kdu_compressed_source
abstract base class. Have you already done this?
Can you give any hints?

Thanks,
John Mellby


--- In kakadu_jpeg2000@yahoogroups.com, "gizwiz68" <yahoo@...> wrote:
>
> I'm trying to uncompress a JP2 file that's fully in memory.
>
> This is a test bench:
>
>  std::ifstream file;
>  file.open(argv[1], std::ios::binary); //open a JP2 file
>  file.seekg(0,std::ios::end);
>  int size=file.tellg();
>  char *data = new char[size];
>  file.seekg(0,std::ios::beg);
>  file.read(data,size);
>  file.close();
>
>  kdu_cache cache();
>
>  // point the kdu_cache to my buffered data using some woodoo
>         // PUT WOODOO HERE
>
>
>  jp2_family_src sourceFile;
>  sourceFile.open( &cache );
>  jp2_source input;
>  input.open( &sourceFile);
>  input.read_header();
>
> What should I replace "//PUT WOODOO HERE" with?
>
> Thanks :)
>
> //Michael
>

I resolved the issue that I posted about before, where I needed a way to
decompress from one in-memory buffer to another, with no file i/o involved.

My question concerns cpu usage. When I call the routine that does this in a loop
that runs thousands of times, using 2 threads on an Intel Core2 Duo, cpu usage
(as reported by Task Manager) never goes above about 85%. I would have thought
that a cpu-intensive algorithm like this would tend to use as much cpu as it
could get. What could account for it not using 100%?

Thanks,
Bill