kakadu_jpeg2000 : Messages : 5968-5997 of 5997

Hi,

I am sorry for sending this question again, since I forgot to give the details
in last message. I am using kakadu v6_2_1-00167L on a linux system.

I want to compress a greyscale raw image into jp2 with this command:

[Yang@localhost Linux-x86-32-gcc]$ ./kdu_compress -i lena.raw -o lena.jp2
Sprecision=8 Ssigned=no Sdims={512,512} Qstep=0.0001 -rate 1.0

And I got the following error:

Kakadu Core Error:
Malformed attribute string, "Sdims=512"!
Problem encountered at "512".
Records must be enclosed by curly braces, i.e., '{' and '}'.
[Yang@localhost Linux-x86-32-gcc]$

I think the error came from params.cpp Line 2205. I tried to debug with GDB, but
it seems that there were no necessary information for debugging.

I have two questions here.
-- What is the problem with the command line above?
-- How to compile on linux to generate the information for debugging with GDB?

Thank you.
Yang

#5969

From: David Taubman <d.taubman@...>
Date: Wed Nov 4, 2009 6:21 am
Subject: Re: kdu_compress for raw image

taubman_ds

Offline

Solution is very simple. The Unix shell you are

using gives a special meaning to curly braces (and

all kinds of other symbols). So you need to take

the generic command and then escape any such special

symbols (e.g., use \{ and \}) and all will be well.

cheers,

David

On 04/11/2009, at 2:19 PM, yanghuyh wrote:

Hi,

I am sorry for sending this question again, since I forgot to give the details in last message. I am using kakadu v6_2_1-00167L on a linux system.

I want to compress a greyscale raw image into jp2 with this command:

[Yang@localhost Linux-x86-32-gcc]$ ./kdu_compress -i lena.raw -o lena.jp2 Sprecision=8 Ssigned=no Sdims={512,512} Qstep=0.0001 -rate 1.0

And I got the following error:

Kakadu Core Error:
Malformed attribute string, "Sdims=512"!
Problem encountered at "512".
Records must be enclosed by curly braces, i.e., '{' and '}'.
[Yang@localhost Linux-x86-32-gcc]$

I think the error came from params.cpp Line 2205. I tried to debug with GDB, but it seems that there were no necessary information for debugging.

I have two questions here.
-- What is the problem with the command line above?
-- How to compile on linux to generate the information for debugging with GDB?

Thank you.
Yang

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

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:
   mailto:kakadu_jpeg2000-digest@yahoogroups.com
   mailto: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

#5970

From: David Taubman <d.taubman@...>
Date: Thu Nov 5, 2009 1:02 am
Subject: Release of version 6.3 and a minor bug

taubman_ds

Offline

Dear Kakadu users,

By now, most of you should have received your release of Kakadu version 6.3.

This new release contains many features, some of which are listed in the summary

I provide below. Unfortunately, a small bug was accidentally included in one of the

many cases involved with writing output image files with the "kdu_expand" demo apps.

Thanks to Greg Coats for compiling immediately and discovering this bug. The fix

is extremely simple, as follows:

In "image_out.cpp", find the function `convert_shorts_to_words'. In that function,

find the case "if (sample_bytes == 1)" and then the test "if ((upshift == 0) && (downshift == 0))"

which is identified as the "Common case". Unfortunately, the "for" loop was

ommitted from the statement block following this test. Just insert the following

line of code immediately underneath the "if ((upshift == 0) && (downshift == 0))"

statement:

"for (; num > 0; num--, src++, dest+=inter_sample_bytes)"

Finally, I would like to mention that I am away for the next week on a conference

trip and will not be able to update the Kakadu web-site with demo executables

and other information until I return. Also, there will be a version 6.3 release

of the Kakadu speed-pack coming very shortly after I return, which contains all

the same features.

Regards,

David

---

Extract from Kakadu's "Overview.txt":

NEW in v6.3

-----------

The new features and improvements in this release fall into three

categories:

1) A major overhaul of the `kdu_region_decompressor' and

`kdu_region_compositor' high level rendering objects, with the

following important innovations:

a) All high level API's in Kakadu now support everything from fast

low precision processing through to full floating-point precision

processing. This has always been true of the core system, but is

now true even for objects like `kdu_region_compositor' which

perform sophisticated rescaling, re-orientation, compositing and

animation of multiple images from multiple codestreams, with

potentially very different internal properties.

b) These objects now implement completely arbitrary scaling (in each

dimension) of the underlying imagery, selecting the most appropriate

original resolution to decompress and using disciplined signal

processing techniques to scale to any target resolution whatsoever,

over any region of the original image. Previously, only bilinear

upscaling was implemented. Now you can even render an image which

only one native compressed resolution at any arbitrary size without

having to worry about the mechanics. These features are demonstrated

in a simple way by adding an arbitrary "-scale" argument to all six

demonstration code fragments inside the "kdu_render" demo app. More

significantly, "kdu_winshow" and "kdu_macshow" take advantage of the

features to produce much higher quality compositions when images

with non-power-of-2-related resolutions are composed on a single

surface. Moreover, these tools now robustly scale to any resolution

at all, providing all the appropriate safe guards as the scaled

resolution approaches ridiculous values (ridiculously large or

ridiculously small). Try zooming or out massively in one of these

viewers if you like, while viewing the image size in the status bar

(you may have to toggle the status mode using ^t or Cmd-t), or try

zooming by small amounts by holding the shift key down together

with the zoom accelerators.

c) The processing of metadata overlay imagery in `kdu_region_compositor'

has been completely re-implemented so as to provide much higher

throughput when there is a massive amount of metadata with regions

of interest to be highlighted. The new implementation provides

disciplined sequencing of the overlay painting process so that there

is little or no risk of large overlay regions concealing smaller ones

and the appearance of overlay data does not depend on the order in

which metadata becomes available in an interactive client-server

session. Dynamic adjustment of the overlay blending

strength is now provided in a very efficient and almost transparent

manner, so you can animate the overlay content in a display without

much processing overhead -- this is what "kdu_winshow" and

"kdu_macshow" now do by default, but you can (as always) toggle the

overlay mode to a non-animated one. Finally, overlay painting now

comes with a much more flexible customization interface so that you

can generate lots of interesting effects without having to

implement your own `kdu_region_compositor::paint_overlay' override.

d) The `kdu_region_compositor' object now offers a function which

can synthesize the imagery aspects of a JPIP request to match

its current configuration, over a defined region of interest on

the rendering surface. This is very important, since correct

synthesis of JPIP requests for complex compositions can be a

very challenging matter, especially since JPIP's interpretation

of resolution does not generally correspond to the resolution

which will produce the highest quality rendition at a given

(arbitrary) scale -- it is based on canvas coordinates, which may

involve sampling factors that are not related to true resolution

(in the signal processing sense).

2) There is a more robust and uniform approach to exception handling

throughout Kakadu, involving a special exception type `kdu_exception'

and preservation of exception codes across Java interfaces via

the "kdu_jni/KduException" class. Everything is backward compatible,

but there are some new guidelines for the throwing of exceptions

within error handlers, which implementors are encouraged to review --

the Kakadu demo applications adhere to these guidelines. As part of

the overhaul of exception handling within Kakadu, close attention has

been given to memory allocation, ensuring that appropriate exceptions

(std::bad_alloc in C++) will be thrown wherever memory allocation fails,

ensuring that such exceptions are passed across thread boundaries during

multi-threaded processing, and ensuring that memory allocation failure

should not leave the system in a state where resources cannot be

properly cleaned up after catching such an exception.

3) Enhancements to the various demo applications:

a) kdu_winshow and kdu_macshow have now completed there convergence,

offering identical features in a uniform manner. Improvements

have been made to: the rendering of region-of-interest overlays;

the transporting of focus boxes across frame changes; the

preservation of state during window duplication actions; presentation

of and navigation within the metadata catalog side bar; and quite

a few other things. The new arbitrary scaling features of the

core workhorse `kdu_region_compositor' are now put to good use in

each of these applications to produce high quality imagery under

all circumstances.

b) kdu_merge offers the capability to easily merge a large number of

codestreams (or other JPEG2000 compressed sources) into a single

JPX/MJ2 file.

c) kdu_merge now offers a more powerful "-album" mode which creates

multiple up-front splash sheets and adds a lot of metadata which

can serve as a template for subsequent editing of the metadata in

"kdu_winshow" or "kdu_macshow".

d) kdu_render now offers a "-scale" option and an additional demo

fragment to illustrate high precsision processing with

`kdu_region_compsositor'.

e) kdu_server now properly supports case-sensitive serving of files,

using a command-line switch which can be applied to change the

default policy under Windows or Unix operating systems.

Finally, this version comes with quite a few bug fixes for the core system,

as well as higher level API's and demo applications. There are some very

important bug fixes for "kdu_server", for example. There are also some

simple but critical bug fixes to the TIFF file I/O implementation used

by the "kdu_compress" and "kdu_expand" demo apps.

#5971

From: "ursatz" <ursatz@...>
Date: Wed Nov 4, 2009 5:43 pm
Subject: CPU usage

ursatz

Offline

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

#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

Online Now

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

#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

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
>

Reply | Forward | Messages in this Topic (5)

#5974

From: "sajadt" <sajadt@...>
Date: Sat Nov 14, 2009 8:28 am
Subject: kdu_show: issuing requests to multiple servers

sajadt

Offline

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

#5975

From: "kasana_s" <kasana_s@...>
Date: Sun Nov 15, 2009 10:58 am
Subject: header related question

kasana_s

Offline

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

#5976

From: "Roland Sweet" <roland.sweet@...>
Date: Mon Nov 16, 2009 3:36 pm
Subject: Re: header related question

roland_a_sweet

Offline

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

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

#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

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

Reply | Forward | Messages in this Topic (5)

#5978

From: "dieter_vh23" <dieter_vh23@...>
Date: Wed Nov 18, 2009 1:42 pm
Subject: Reversible?

dieter_vh23

Offline

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

#5979

From: David Taubman <d.taubman@...>
Date: Fri Nov 20, 2009 3:33 am
Subject: Re: Reversible?

taubman_ds

Offline

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

#5980

From: Peter Murray <peter@...>
Date: Fri Nov 20, 2009 2:42 am
Subject: Re: Reversible?

p_e_murray

Offline

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/

#5981

From: "cornejoc" <cornejoc@...>
Date: Mon Nov 23, 2009 7:42 pm
Subject: Kakadu Speedpack Performance

cornejoc

Offline

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.

#5982

From: David Burken <dburken@...>
Date: Sun Nov 22, 2009 9:48 pm
Subject: nband jp2 file and colorspace ?

drburken

Offline

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

#5983

From: David Taubman <d.taubman@...>
Date: Tue Nov 24, 2009 1:06 am
Subject: Re: Kakadu Speedpack Performance

taubman_ds

Offline

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

#5984

From: David Taubman <d.taubman@...>
Date: Tue Nov 24, 2009 1:17 am
Subject: Re: nband jp2 file and colorspace ?

taubman_ds

Offline

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

#5985

From: David Burken <dburken@...>
Date: Tue Nov 24, 2009 1:50 pm
Subject: Re: nband jp2 file and colorspace ?

drburken

Offline

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

d.taubman@unsw.edu.au

#5986

From: David Burken <dburken@...>
Date: Tue Nov 24, 2009 2:07 pm
Subject: Threading results

drburken

Offline

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

#5987

From: "norrizuan" <norrizuan@...>
Date: Tue Nov 24, 2009 3:32 pm
Subject: kdu_compress and kdu_expand for 16-bit .pgm file

norrizuan

Offline

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

#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

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

#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

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

#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

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
>

#5991

From: "cornejoc" <cornejoc@...>
Date: Tue Nov 24, 2009 10:45 pm
Subject: Re: Kakadu Speedpack Performance

cornejoc

Offline

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@...>
>

#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

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
>

#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

Offline

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

#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

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.

#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

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

#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

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

#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

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