Search the web
Sign In
New User? Sign Up
kakadu_jpeg2000 · Kakadu JPEG2000 Discussion Group
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
Messages 5971 - 6000 of 6008   Newest  |  < Newer  |  Older >  |  Oldest
Messages: Show Message Summaries   (Group by Topic) Sort by Date v  
#6000 From: "norrizuan" <norrizuan@...>
Date: Tue Dec 1, 2009 4:02 pm
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
norrizuan
Online Now Online Now
Send Email Send Email
 

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


--- In kakadu_jpeg2000@yahoogroups.com, David Taubman <d.taubman@...> wrote:
>
> Hi Rizuan,
>
> The easiest file format to use for high bit-depth representations
> is TIFF. Kakadu supports TIFF files of every bit-depth (not just
> the simple numbers like 8,12,16, etc.) and even floating-point.
> Of course, you can use raw files too. Just make sure you read
> the usage statements for these files first so you understand
> bit-alignment -- you can often adjust bit-alignment to suit your
> needs using "-fprec". Be sure to use version 6.3.1, not 6.3 since
> the latter had an accidentally introduced one-line bug for raw/TIFF
> writing at 8-bits precision under reversible compression
>
> Cheers,
> David
>
> On 25/11/2009, at 11:24 AM, norrizuan wrote:
>
> 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<mailto: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<mailto: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
>
>
>
>
>
>
> ------------------------------------
>
> For problems with your subscription in this group please email
> kakadu_jpeg2000-owner@yahoogroups.com<mailto:kakadu_jpeg2000-owner@yahoogroups.com.
> 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@...
>

#5999 From: David Taubman <d.taubman@...>
Date: Sun Nov 29, 2009 11:39 pm
Subject: Re: slow speed pack performance on one server compared to others?
taubman_ds
Offline Offline
Send Email Send Email
 
HI Paul,

What you observe generally for the
single CPU machine makes perfect sense and
agrees with my general observations.  Of course,
with only 4 CPU cores you can't do better than when
using 4 threads and of course there is a performance
hit to using threads -- this is something I hope to
significantly release in future versions, but it is
common to just about any multi-threaded program.

Incidentally, the kdu_v_expand demo app provides
a great way to investigate the trade-offs associated
with performing closely coupled work within a single
image using multi-threading, vs. decompressing
separate frames (could be tiles) in different threads.
That app allows you to specify how many frames
of a video sequence are to be decompressed in parallel
and also to specify how many threads are to be
dedicated to each frame.  The results I have obtained
on 8-core machines (dual Xeons) indicate that 2 threads
per frame (4 frames in parallel) works almost as well
as 1 thread per frame (8 frames), with half the memory
load and delay.

It would be nice to run a test using kdu_v_expand
on your machines to see if similar observations hold.

The obvious issue of concern with multiple physical
CPU's is the overhead associated with cache synchronization.
Kakadu tries to keep each thread working on jobs which
have close memory locality where possible, but since every
synchronization primative (e.g., mutex locking) is potentially
a resynchronization point, the way in which the operating
system handles thread scheduling is ultimately the main
concern.  I have never worked with the server versions of
Windows; it is possible they have a different scheduling
algorithm.  I have certainly noticed that thread performance
varies between different flavours of Unix/Linux.  For example,
at least until Snow Leopard, I noticed that the scheduling
algorithm (or perhaps synchronization overhead) in OSX (runs
on top of BSD) seemed noticeably less efficient than that
found in a 64-bit Linux platform I tested.  For windows, I only
tested under Windows XP in the past.

Sorry I cannot give you a more concrete answer right now,
but I would be very interested in results you might obtain with
kdu_v_expand, since it gives you a way to explore the impact
of thread affinity, threads per image and total load on your
machine.  You mention that you have been exploring thread
affinity without much success.  I wonder if it is really implemented
under Windows??

Anyway, like I say, getting more mileage out of multi-threading
on platforms with a large number of CPU's is certainly on
the plans.  When Kakadu's multi-threaded processing engine
was first created, the only platforms easily accessible with
multiple CPU resources had at most 2 CPU's (usually discrete
or one CPU with hyperthreading) and close to 100% utilization
was achieveable.

Cheers,
David


On 29/11/2009, at 5:52 PM, paulgwork wrote:

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



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

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


#5998 From: "paulgwork" <paulgwork@...>
Date: Sun Nov 29, 2009 6:52 am
Subject: slow speed pack performance on one server compared to others?
paulgwork
Offline Offline
Send Email Send Email
 
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

#5997 From: David Taubman <d.taubman@...>
Date: Wed Nov 25, 2009 11:20 pm
Subject: Re: Re: kdu_compress and kdu_expand for 16-bit .pgm file
taubman_ds
Offline Offline
Send Email Send Email
 
Hi Rizuan,

The easiest file format to use for high bit-depth representations
is TIFF.  Kakadu supports TIFF files of every bit-depth (not just
the simple numbers like 8,12,16, etc.) and even floating-point.
Of course, you can use raw files too.  Just make sure you read
the usage statements for these files first so you understand
bit-alignment -- you can often adjust bit-alignment to suit your
needs using "-fprec".  Be sure to use version 6.3.1, not 6.3 since
the latter had an accidentally introduced one-line bug for raw/TIFF
writing at 8-bits precision under reversible compression

Cheers,
David

On 25/11/2009, at 11:24 AM, norrizuan wrote:

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






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

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


#5996 From: Mathieu Malaterre <mathieu.malaterre@...>
Date: Wed Nov 25, 2009 3:29 pm
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
malat98
Offline Offline
Send Email Send Email
 
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

#5995 From: "Roland Sweet" <roland.sweet@...>
Date: Wed Nov 25, 2009 3:20 pm
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
roland_a_sweet
Offline Offline
Send Email Send Email
 
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

#5994 From: "Roland Sweet" <roland.sweet@...>
Date: Wed Nov 25, 2009 3:18 pm
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
roland_a_sweet
Offline Offline
Send Email Send Email
 
 
Rizuan,
 
Run
 
kdu_compress -usage > kdu_compress_usage.txt
 
This will give you a detailed explanation in the txt file of all of the input parameters for kdu_compress.

#5993 From: "norrizuan" <norrizuan@...>
Date: Wed Nov 25, 2009 12:24 am
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
norrizuan
Online Now Online Now
Send Email Send Email
 
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
> >
>

#5992 From: "mlepley_dance" <mlepley_dance@...>
Date: Wed Nov 25, 2009 4:36 am
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
mlepley_dance
Offline Offline
Send Email Send Email
 
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
>

#5991 From: "cornejoc" <cornejoc@...>
Date: Tue Nov 24, 2009 10:45 pm
Subject: Re: Kakadu Speedpack Performance
cornejoc
Offline Offline
Send Email Send Email
 
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@...>
>

#5990 From: "RolandS" <roland.sweet@...>
Date: Tue Nov 24, 2009 9:52 pm
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
roland_a_sweet
Offline Offline
Send Email Send Email
 
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
>

#5989 From: Mathieu Malaterre <mathieu.malaterre@...>
Date: Tue Nov 24, 2009 9:45 pm
Subject: Re: kdu_compress and kdu_expand for 16-bit .pgm file
malat98
Offline Offline
Send Email Send Email
 
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

#5988 From: "Roland Sweet" <roland.sweet@...>
Date: Tue Nov 24, 2009 9:40 pm
Subject: kdu_compress and kdu_expand for 16-bit .pgm file
roland_a_sweet
Offline Offline
Send Email Send Email
 
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


#5987 From: "norrizuan" <norrizuan@...>
Date: Tue Nov 24, 2009 3:32 pm
Subject: kdu_compress and kdu_expand for 16-bit .pgm file
norrizuan
Online Now Online Now
Send Email Send Email
 
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

#5986 From: David Burken <dburken@...>
Date: Tue Nov 24, 2009 2:07 pm
Subject: Threading results
drburken
Offline Offline
Send Email Send Email
 
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

#5985 From: David Burken <dburken@...>
Date: Tue Nov 24, 2009 1:50 pm
Subject: Re: nband jp2 file and colorspace ?
drburken
Offline Offline
Send Email Send Email
 
Hi David,

Thank you for the quick response.  That fixed me just doing a single band description if not 3 bands.  I will play with writing jpx when I get time.  My initial requirements were for jp2 though.  The plugin is coming along.  We now support j2k, jp2, nitf(j2k) read.  jp2 and nitf write and we have an overview builder that uses nitf.

Thanks again,
Dave


On 11/23/2009 08:17 PM, David Taubman wrote:
 

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


#5984 From: David Taubman <d.taubman@...>
Date: Tue Nov 24, 2009 1:17 am
Subject: Re: nband jp2 file and colorspace ?
taubman_ds
Offline Offline
Send Email Send Email
 
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


#5983 From: David Taubman <d.taubman@...>
Date: Tue Nov 24, 2009 1:06 am
Subject: Re: Kakadu Speedpack Performance
taubman_ds
Offline Offline
Send Email Send Email
 
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.
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


#5982 From: David Burken <dburken@...>
Date: Sun Nov 22, 2009 9:48 pm
Subject: nband jp2 file and colorspace ?
drburken
Offline Offline
Send Email Send Email
 
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

#5981 From: "cornejoc" <cornejoc@...>
Date: Mon Nov 23, 2009 7:42 pm
Subject: Kakadu Speedpack Performance
cornejoc
Offline Offline
Send Email Send Email
 
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.

#5980 From: Peter Murray <peter@...>
Date: Fri Nov 20, 2009 2:42 am
Subject: Re: Reversible?
p_e_murray
Offline Offline
Send Email Send Email
 
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/

#5979 From: David Taubman <d.taubman@...>
Date: Fri Nov 20, 2009 3:33 am
Subject: Re: Reversible?
taubman_ds
Offline Offline
Send Email Send Email
 
Hi Dieter,

Simple: Creverible=yes does not mean lossless; it only means reversible transform,
which is one pre-requisite for lossless.  The reason you did not get a lossless result
is the "slope" option provided 6 distortion-length slope thresholds for the 6 quality
layers, all of which limited the quality of those layers.  You should change (or add) one
layer to have a slope of 0.

Cheers,
David


On 19/11/2009, at 12:42 AM, dieter_vh23 wrote:

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_Properties]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




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

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


#5978 From: "dieter_vh23" <dieter_vh23@...>
Date: Wed Nov 18, 2009 1:42 pm
Subject: Reversible?
dieter_vh23
Offline Offline
Send Email Send Email
 
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

#5977 From: David Taubman <d.taubman@...>
Date: Fri Nov 20, 2009 1:53 am
Subject: Re: Re: point the kdu_cache to my buffered data using some woodoo
taubman_ds
Offline Offline
Send Email Send Email
 
The "jp2_input_box" object is an example of a
derived class which can act as a memory source
(it does a great deal more than that of course, but
you can ask it to pre-buffer the entire JP2 box
into an internal memory buffer which is then
extremely efficient for the decompressor to access
without I/O stalls).  That would be an example, but
you could make a much much simpler one.

Cheers,
David

On 13/11/2009, at 8:52 AM, johnmellby wrote:

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





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

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


#5976 From: "Roland Sweet" <roland.sweet@...>
Date: Mon Nov 16, 2009 3:36 pm
Subject: Re: header related question
roland_a_sweet
Offline Offline
Send Email Send Email
 
Kasana,
 
JPEG2000 file format is not that simple.  It doesn't consist of a simple header followed by a string of bits.  Basically, the file format consists of a series of boxes.  Each box has a precise definition and contains information related to its function.  For instance, there is a colorspace box that tells how to interpret the data in terms of color.  Each box also has overhead bytes.  For a small image, the overhead is considerable.
 
To more fully understand this file format you need to either consult a book (Taubman has written one) or look at the official JPEG2000 document that is available online for a fee.
 
Hope this helps.
 
Roland
 
----- Original Message -----
From: kasana_s
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


#5975 From: "kasana_s" <kasana_s@...>
Date: Sun Nov 15, 2009 10:58 am
Subject: header related question
kasana_s
Offline Offline
Send Email Send Email
 
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

#5974 From: "sajadt" <sajadt@...>
Date: Sat Nov 14, 2009 8:28 am
Subject: kdu_show: issuing requests to multiple servers
sajadt
Offline Offline
Send Email Send Email
 
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

#5973 From: "johnmellby" <jmellby@...>
Date: Thu Nov 12, 2009 9:52 pm
Subject: Re: point the kdu_cache to my buffered data using some woodoo
johnmellby
Offline Offline
Send Email Send Email
 
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
>

#5972 From: Pieter Van Nuffel <vannuffelpieter@...>
Date: Mon Nov 9, 2009 1:12 pm
Subject: follow up for visualisation mode and minor bug found
vannuffelpieter
Offline Offline
Send Email Send Email
 
Hi David

I would like to know how I can enable/disable the new method of the image precision when using JP2 files with multiple components. These components can be i97 or r53. Its very closely related to a post I made earlier: http://tech.groups.yahoo.com/group/kakadu_jpeg2000/message/5938.

The use of kakadu for my software no longer needs the functionality I asked about in that post, but since the rendering of images has changed since version 6.1.1 I wanted to know if something is possible. Please take a look at some screenshots from the same JP2 file, rendered once with version 6.1.1 and twice with version 6.3: http://img39.imageshack.us/img39/1470/kakadufiltering.png

The JP2 file used contains 4 components. I render all these into separate imagebuffers, so these are simple greyscale results. I do a for loop over all pixels and alpha-blend the various components together. The first two are i97 greyscale images, the second of which is displayed by only setting the red channel on the final imagebuffer that I want to display. The last two are r53 1 bit images, these are overlays to notify cell boundaries etc. For these I also choose a specific color (red and green).

The most important visual difference between the v 6.1.1 screenshot and the middle v6.3 screenshot is the seemingly use of (bi)linear filtering.

Using the old 6.1.1 rendering, I could easily detect when a pixel definately had an overlay color applied to that pixel (in this case a red or green dot). When that happened, I would not bother with alpha blending the various components, but only keep the last pixel value of the upper overlay. Since the overlay images are r53 1 bit images, a certain pixel is either 'on' or 'of' for that overlay.

This performance enhancement does not work anymore, as you can see on the bottom image. The filtering that's applied causes nearby pixels of the overlay lines to also contain a value different from the default value (showing up as black if I view the JP2 with kdu_winshow). This means that my code thinks there's a valid color in those pixels and the 'weak' value of that pixel is used for the final image. This is where the black lines come from. The middle v6.3 image on the screenshot forces all pixels to be alpha-blended anyway, regardless if there's a pixel with an overlay value or not.

I would like to be able to use this new rendering method for regular greyscale images since using that filtering/blending smooths out the pixel blocks when zooming in a lot. But I would not want to use this for the overlay components, since the resulting image is not correct anymore. Is there a way to specify the wanted behaviour for each component in my java JNI project?


Also, I found a minor bug in kdu_winshow. Normally the - and + keys are used to change the displayed component, but for some reason the insert key is specified for going to the previous component. This is defined in the file kdu_winshow.rc on line 217.


Kind regards

Pieter


#5971 From: "ursatz" <ursatz@...>
Date: Wed Nov 4, 2009 5:43 pm
Subject: CPU usage
ursatz
Offline Offline
Send Email Send Email
 
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

Messages 5971 - 6000 of 6008   Newest  |  < Newer  |  Older >  |  Oldest
Advanced
Add to My Yahoo!      XML What's This?

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help