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...
Show off your group to the world. Share a photo of your group with us.

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 5968 - 5997 of 5997   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries   (Group by Topic) Sort by Date ^  
#5968 From: "yanghuyh" <yanghuyh@...>
Date: Wed Nov 4, 2009 3:19 am
Subject: kdu_compress for raw image
yanghuyh
Offline Offline
Send Email Send Email
 
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 Offline
Send Email Send Email
 
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 Offline
Send Email Send Email
 
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 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

#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 Online Now
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


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

#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

#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

#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


#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


#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

#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


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

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

#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

#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


#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


#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


#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

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

#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


#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

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

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

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

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

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

#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

#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

#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


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

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