Re: [djatoka-general] Compres.sh out of memory

[A. B. <ar...@zo...>]

Hi, first, thanks for this quick answer.


You can find one of my test file here:
http://www.picdo.net/fichiers/2009/10/14/98081c07-54b3-4533-96af-8f9b361b1e68_test.tif
(5,2 mo, jpeg compression).


I have try to run the app with different tiff files: jpeg compression,
lzw compression and no compression. The result is the same.


I have also check the log4j properties file and set it to DEBUG. I
don't get any additional information (exact same output as before). The
error message and app crash happend immediately after it start. No
delay like memory loading or anything else.


Here is the output of my java -version:


java version "1.6.0_15"

Java(TM) SE Runtime Environment (build 1.6.0_15-b03)

Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode)


My little test images are tiff images created with gimp from original .jpeg image (Sony camera).


I have made only modification i have made is in compress.sh, i have add
those 2 options into the "java.." line  : "-Xmx1024m -Xss1024m"


The information you provide about how djatoka compress work is very
interesting, maybe you could add it to the compress description page in
the wiki.


I'm going to try with more parameters to bypass the first step.


Also i'm interested in informations about kakadu command line parameters that could be usefull with djatoka.


Arnaud

----------------------------------------
De: "Ryan Chute" <rc...@gm...>
Envoyé: mercredi 14 octobre 2009 16:57
A: ar...@zo...
Objet: Re: [djatoka-general] Compres.sh out of memory 

Sorry to hear you're having an issue with the compress app.

 I'll need a bit more info to diagnose the issue:
* Is the sample TIFF image compressed (i.e. LZW)?
* What modifications have been made to env.sh and/or compress.sh?
* How were your test images created?
* Is the log4j.rootCategory in log4j.properties in the bin dir set to DEBUG?
- If not, would you mind running the process again with DEBUG enables
and posting the results?
* Would it be possible for you to make a copy of the 2MB TIFF test
file available?

The reason I ask these questions... when a tiff is passed to djatoka
as the input, the djatoka compress app passes the TIFF directly off to
the Kakadu command-line executable with two caveats; 1) if the number
of resolution levels is not defined, it uses JAI to determine the
pixel dimension and then calculate the djatoka-based resolution level
count and 2) uses ImageJ's TiffDecoder to determine if the TIFF is
compressed.  If compressed djatoka needs to created an intermediate
uncompressed TIFF that can be piped into the Kakadu compression
application.  Neither of these would cause an issue for the 2MB file,
but may cause an OutOfMemory exception for the 600MB file.  Also,
regarding large uncompressed TIFF files, you may want to consider
using the Kakadu compress application directly to compress the images,
then use djatoka as usual for all extraction operations.  I can
provide tips on the various Kakadu command line properties necessary
to mimic djatoka if anyone is interested.

Let me know,
Ryan

On Wed, Oct 14, 2009 at 3:16 AM, A. Babilone  wrote:
> Hi,
>
> I'm actually trying to find out how does Djatoka work. I have been hable to
> configure tomcat server and successfully test the viewer with the demo
> image.
>
> Now i'm trying to get my own image in jp2 format.
>
> When i run the test with the image in /etc/, the compress.sh utility work
> good.
>
> If i try with my own picture, it give me an out of memory error message as
> display below:
>
> f@linux-k894:~/.../adore-djatoka-1.1/bin> ./compress.sh -i test.tif -o
> test.jp2
> Error occurred during initialization of VM
> java.lang.OutOfMemoryError: unable to create new native thread
>     at java.lang.Thread.start0(Native Method)
>     at java.lang.Thread.start(Thread.java:597)
>     at java.lang.ref.Reference.(Reference.java:145)
>
> I get this even if a work with a big image file (~600mo), or a quite small
> (~2mo).
>
> I've set the Xmx and Xss parameter both to 1024m but nothing change.
>
> Does anybody have an idea ?
>
> Thanks in advance
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> djatoka-general mailing list
> dja...@li...
> https://lists.sourceforge.net/lists/listinfo/djatoka-general
>
>