Skip to main content

[JAI] Memory problem with real big Images?

30 replies [Last post]
Anonymous

Hi,
I am dealing with really big Medical Images. Each Image is around 60MB to
80MB. So Obviously the no.of Pixels is very high.
In my current algorithm I am allocating a single array to store all the
pixels. So this is giving me "OutofMemory error". I am forced to store the
pixels in a single array since I am making a DataBuffer with it. And this
DataBuffer is used to create the BufferedImage in return.
Is there any different way in which I can use the memory effectively? Any
different ways in which I can develop a BufferedImage?
Thanks in advance,
Kind Regards,
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Bob Deen

Okay this is getting WAY off topic...

>I don't mean to nit pick, but don't dereference an object in C
>because there aren't any objects in C :-)

nit nit nit object == allocated entity pick pick pick ;-}

>Java tries to create a fool proof programming environment but has
>created an environment
>where one *HAS* to rely on the work of others who might be tired or
>distracted at a
>crucial moment in the development process. And this discussion
>demonstrates that.

There are two kinds of memory issues:

1) Freeing something that is still in use
2) Failing to free something that is not in use

In C/C++ you have both problems. Java eliminates the first, leaving only
the second (and greatly reduces the problems with that, as well). What's
more, the first problem leads to memory corruption and crashes. The second
leads only to inaccessible memory.

It's a safety thing. It's far more robust to simply run out of resources
than it is to randomly crash. Not to diminish the problem of running out
of resources, but that is a much more well-behaved problem, much more
amenable to analysis with profiling tools, and much easier to trap at run-time
if necessary, than the problems associated with freeing something that is
still in use.

Just because a system isn't perfect is no reason to reject it in favor of
its predecessor when that predecessor shares the exact same problems, with
a host of far more serious ones besides.

-Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Bob Deen

>The problem with Java and memory management WRT: competence in
>engineering is exactly
>the same. But further, in Java, one doesn't always have access to the
>objects that have references
>to objects one thinks he has removed all references to -- that's kind of
>convoluted. What I mean
>is that you can't always entirely dereference an object.

Of course if you don't entirely dereference an object in C and free it
anyway, you're *really* hosed. So I don't see any difference in that
respect. It may be that some Java libraries hide away references you
don't know about, but that's the fault of the library and/or its
documentation, not the language.

>Based on recent experience -- Java 1.4.x -- I was as
>thorough as I could be in disposing of Image resources yet I could watch
>used memory grow each
>time I disposed of the previous Image and loaded a new Image. Likely
>this is incompetent programming
>on my part. Goes to show that Java is not as safe as people assert it is.

Try a memory profiler.

To bring this back to JAI, one thing to keep in mind is that JAI maintains
a tile cache. This cache will tend to grow until it reaches its own size
limit (which you can control). Therefore it may look like memory usage is
increasing (and in fact the heap IS increasing) as you process more images.
However, the references to tiles in the cache are supposed to be weak
references... meaning that the JVM should free them before throwing an
out of memory error. Of course there might be implementation bugs but
that's what is _supposed_ to happen.

I recall some discussion a few years ago that not all JVM's handled weak
references properly, but hopefully that's been resolved by now.

An interesting thing to try when you have memory problems with JAI is to
completely disable the cache. Performance will probably hit the toilet,
but if memory usage is stable, that tells you something.

-Bob Deen @ NASA-JPL Multimission Image Processing Lab
Bob.Deen@jpl.nasa.gov

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Ken Warner

Bob Deen wrote:

Of course if you don't entirely dereference an object in C and free it
anyway, you're *really* hosed. So I don't see any difference in that
respect.

I don't mean to nit pick, but don't dereference an object in C
because there aren't any objects in C :-)

If you don't free() a pointer to memory, that memory stays allocated and
cannot be
reallocated -- malloc()'ed -- again. That's the difference. Memory
leaks in C happen
when you fail to free() a pointer to memory and then use the same
pointer to point
to a different block of memory so you loose the reference to the first
block of memory
and you loose any way to free() that first block.

The difference is that memory allocation in C is more readily controlled
by the programmer
directly and programmatically than in Java. If a programmer is not good
enough to handle
that capability -- that's another problem.

In Java, no matter how good you are -- you can't always be thorough
because references
to objects can be out of reach. Even if you find the problem with a
memory profiler, that doesn't
mean you can fix the problem.

Java tries to create a fool proof programming environment but has
created an environment
where one *HAS* to rely on the work of others who might be tired or
distracted at a
crucial moment in the development process. And this discussion
demonstrates that.

Ken

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Robert Engels

Sorry, but you really need to start over with some basic programming
courses.

You have the same problem in any C "library" - actually worse, the person
that wrote that library might free your pointers, might perform invalid
pointer arithmetic leading to GPF, and/or generally corrupt your entire
execution environment.

This is actually far MUCH EASIER to do in C than in Java. For an easy
example you can look at Java's JAI - there are far more bugs in the 'native'
C code than in Java, and they seem to take twice as long to fix.

-----Original Message-----
From: Ken Warner [mailto:kwarner@uneedspeed.net]
Sent: Sunday, May 29, 2005 12:37 PM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Bob Deen wrote:

Of course if you don't entirely dereference an object in C and free it
anyway, you're *really* hosed. So I don't see any difference in that
respect.

I don't mean to nit pick, but don't dereference an object in C
because there aren't any objects in C :-)

If you don't free() a pointer to memory, that memory stays allocated and
cannot be
reallocated -- malloc()'ed -- again. That's the difference. Memory
leaks in C happen
when you fail to free() a pointer to memory and then use the same
pointer to point
to a different block of memory so you loose the reference to the first
block of memory
and you loose any way to free() that first block.

The difference is that memory allocation in C is more readily controlled
by the programmer
directly and programmatically than in Java. If a programmer is not good
enough to handle
that capability -- that's another problem.

In Java, no matter how good you are -- you can't always be thorough
because references
to objects can be out of reach. Even if you find the problem with a
memory profiler, that doesn't
mean you can fix the problem.

Java tries to create a fool proof programming environment but has
created an environment
where one *HAS* to rely on the work of others who might be tired or
distracted at a
crucial moment in the development process. And this discussion
demonstrates that.

Ken

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Aaron Bruegl

These guides are very helpful.

Java Deployment:
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/co...
ts.html

Java Web Start:
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/content...
ml

Web Start is the nicest thing since JAI, and sliced bread by the way. It
makes deployment easy if you are willing to spend a little time setting up a
web server.

-Aaron Bruegl

________________________________________
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Monday, May 30, 2005 8:51 AM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Hi,
Thank u once again. But how can the heap be set on a stand alone windows
system?
Thanks in Advance,
regards,
Rajesh Rapaka.

 
On 5/27/05, Paquette, Dan wrote:
It is quite simple.
 
@echo off
start java -Xmx100m -classpath %YOUR_CLASSPATH_HERE% -jar myApp.jar
 
 
This would start your application with a max heap size of ~100 MB. Then your
users can simply double click this batch file to run your program. There are
a million other ways to accomplish this, but you get the basic idea.
 
-----Original Message-----
From: R Rajesh [mailto: rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 4:01 PM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?
Hi all,
 
Thank u all for ur valuble time.
 
>Also, are you sure the software is no just loading the visible portion?
I.e. If you have a 1024x768x32bit image displayed, this will only require
approx 2.5 mb. You can use the pixel sampling method to read the image at
the displayed size.
Mr.Robert could u be a little elaborate on what u've said about the loading
the visible portion? or can u help me with a link from where I can learn
about it?
>setting aside the fact that you just made an ass of yourself to a...
Mr.Loki, I dont think sentences like these do not promote for a healthy
technical interaction. My terming of "Professionals" is an answer
to Robert's assumption of "computer/java beginers". I dont want ponder much
on this issue, but i failed to make sense from what u've written there. I'd
appreciate if u can go thru the earlier posts of this thread and understand
my requirement.
>You set the -Xmx???m switch when you call the java executable; so this is
not something you need to do on each computer. You just need to create a
batch file or shell script that launches your program and then you can put
what ever parameters you want to use in there when you call the program.
 
Dear Mr.Dan, can I have a link to a source about this to have a better Idea
of how to do this? I greatly appreciate ur help.
 
Thank u all friends.
regards
Rajesh Rapaka.
 
 

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

R Rajesh

Hi,
Thank u once again. But how can the heap be set on a stand alone windows
system?
Thanks in Advance,
regards,
Rajesh Rapaka.

On 5/27/05, Paquette, Dan wrote:
>
> It is quite simple.
> @echo off
> start java -Xmx100m -classpath %YOUR_CLASSPATH_HERE% -jar myApp.jar
> This would start your application with a max heap size of ~100 MB. Then
> your users can simply double click this batch file to run your program.
> There are a million other ways to accomplish this, but you get the basic
> idea.
> -----Original Message-----
> *From:* R Rajesh [mailto:rajesh.rapaka@gmail.com]
> *Sent:* Friday, May 27, 2005 4:01 PM
> *To:* interest@jai.dev.java.net
> *Subject:* Re: [JAI] Memory problem with real big Images?
>
> Hi all,
> Thank u all for ur valuble time.
> >Also, are you sure the software is no just loading the visible portion?
> I.e. If you have a 1024x768x32bit image displayed, this will only require
> approx 2.5 mb. You can use the pixel sampling method to read the image at
> the displayed size.
>
> Mr.Robert could u be a little elaborate on what u've said about the
> loading the visible portion? or can u help me with a link from where I can
> learn about it?
> >setting aside the fact that you just made an ass of yourself to a...
>
> Mr.Loki, I dont think sentences like these do not promote for a healthy
> technical interaction. My terming of "Professionals" is an answer to
> Robert's assumption of "computer/java beginers". I dont want ponder much on
> this issue, but i failed to make sense from what u've written there. I'd
> appreciate if u can go thru the earlier posts of this thread and understand
> my requirement.
> >You set the -Xmx???m switch when you call the java executable; so this is
> not something you need to do on each computer. You just need to create a
> batch file or shell script that launches your program and then you can put
> what ever parameters you want to use in there when you call the program.
> Dear Mr.Dan, can I have a link to a source about this to have a better
> Idea of how to do this? I greatly appreciate ur help.
> Thank u all friends.
> regards
> Rajesh Rapaka.
>
> --
> R.Rajesh,
> Computer Engineer (Java Developer),
> Eroglu Software Company,
> Eskisehir, Turkey.
>
>

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

loki der quaeler

http://www.google.com/search?
num=30&hl=en&q=deploying+java+applications+on+windows

On 30 May, 2005, at 15.50, R Rajesh wrote:

> Hi,
> Thank u once again. But how can the heap be set on a stand alone
> windows system?
> Thanks in Advance,
> regards,
> Rajesh Rapaka.
>
>  
> On 5/27/05, Paquette, Dan wrote: It is quite
> simple.
>>  
>> @echo off
>> start java -Xmx100m -classpath %YOUR_CLASSPATH_HERE% -jar myApp.jar
>>  
>>  
>> This would start your application with a max heap size of ~100 MB.
>> Then your users can simply double click this batch file to run your
>> program. There are a million other ways to accomplish this, but you
>> get the basic idea.
>>  
>> -----Original Message-----
>> From: R Rajesh [mailto: rajesh.rapaka@gmail.com]
>> Sent: Friday, May 27, 2005 4:01 PM
>> To: interest@jai.dev.java.net
>> Subject: Re: [JAI] Memory problem with real big Images?
>>
>>> Hi all,
>>>  
>>> Thank u all for ur valuble time.
>>>  
>>> >Also, are you sure the software is no just loading the visible
>>> portion? I.e. If you have a 1024x768x32bit image displayed, this
>>> will only require approx 2.5 mb. You can use the pixel sampling
>>> method to read the image at the displayed size.
>>>
>>> Mr.Robert could u be a little elaborate on what u've said about the
>>> loading the visible portion? or can u help me with a link from where
>>> I can learn about it?
>>> >setting aside the fact that you just made an ass of yourself to a...
>>>
>>> Mr.Loki, I dont think sentences like these do not promote for a
>>> healthy technical interaction. My terming of "Professionals" is an
>>> answer to Robert's assumption of "computer/java beginers". I dont
>>> want ponder much on this issue, but i failed to make sense from what
>>> u've written there. I'd appreciate if u can go thru the earlier
>>> posts of this thread and understand my requirement.
>>> >You set the -Xmx???m switch when you call the java executable; so
>>> this is not something you need to do on each computer. You just need
>>> to create a batch file or shell script that launches your program
>>> and then you can put what ever parameters you want to use in there
>>> when you call the program.
>>>  
>>> Dear Mr.Dan, can I have a link to a source about this to have a
>>> better Idea of how to do this? I greatly appreciate ur help.
>>>  
>>> Thank u all friends.
>>> regards
>>> Rajesh Rapaka.
>>>  
>>>  
>>>
>>> --
>>> R.Rajesh,
>>> Computer Engineer (Java Developer),
>>> Eroglu Software Company,
>>> Eskisehir, Turkey.
>
>
> --
> R.Rajesh,
> Computer Engineer (Java Developer),
> Eroglu Software Company,
> Eskisehir, Turkey.
[att1.dat]

R Rajesh

Hi,
yes as u've said I should be a little resonable in expecting. But this
memory issue might not have disturbed me much if I havent seen another
software (dont know which language is used) which is able to load 4 images
each of 54 MB i.e. 216MB just by using 23MB of memory. I am still not able
to figure out what their algorithm could have been.
and freeing the memory is another miracle. just within a millisec all the
30MB is regained(as soon as the window is closed).
The format of the images I am dealing with is the DICOM images. Well now I
can see in no way I can load the whole 54MB at once, But is there a way
using which I can free the memory Immediately as soon as i close the window.

I am using Internal frames in my program. I am setting all the resources to
null. and invoking the garbage in the window exit function. but the Garbage
collector waits for the memory to fall below cetain level. but the next
Image I open could be very huge and the allocations is not permited - thus
the OutOfMemoryException. How can I make the Garbagecollection get invoked
even if the memory doesnt fall under a defenite level!
Thank u for ur time.
thanks in Advance.
kind regards,
Rajesh Rapaka.
--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

Robert Engels

That is not true. You must still have a reference to the Image somewhere.
You a decent profiler tool to help you solve the problem. The Java runtime
system will make sure all objects that can be 'freed' are before throwing an
OutOfMemory error.
-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 10:06 AM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Hi,

yes as u've said I should be a little resonable in expecting. But this
memory issue might not have disturbed me much if I havent seen another
software (dont know which language is used) which is able to load 4 images
each of 54 MB i.e. 216MB just by using 23MB of memory. I am still not able
to figure out what their algorithm could have been.
and freeing the memory is another miracle. just within a millisec all the
30MB is regained(as soon as the window is closed).

The format of the images I am dealing with is the DICOM images. Well now I
can see in no way I can load the whole 54MB at once, But is there a way
using which I can free the memory Immediately as soon as i close the window.

I am using Internal frames in my program. I am setting all the resources
to null. and invoking the garbage in the window exit function. but the
Garbage collector waits for the memory to fall below cetain level. but the
next Image I open could be very huge and the allocations is not permited -
thus the OutOfMemoryException. How can I make the Garbagecollection get
invoked even if the memory doesnt fall under a defenite level!

Thank u for ur time.
thanks in Advance.
kind regards,
Rajesh Rapaka.
--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

lurch
Offline
Joined: 2006-06-21
Points: 0

just to bring this [i]completely[/i] back to the topic:
I've been using JAI to load images up to 2GB, its practically done for you if you use a format that supports tiling, I'm using (Geo)TIFF's.

I just use the default tile cache size and JVM heap size and it seems to work fine, slow of course when it has to go to disk for the tiles, but hey, when you get memory efficiencey like JAI provides you can't complain.

So perhaps you might want to convert (with an external tool) to a tiled/striped format, not very glamorous I know :(

Richard Smith

At least for Sun's JVM, the so-called "heap" has internal structure, such as
the distinction between New Eden and Tenured spaces. Therefore not all of the
heap memory can be used to hold a single object. However up to a limit, the
size of the heap can be expanded. An OutOfMemory means that the heap can be
expanded no further, and insufficient space could be freed via GC. Normally to
deal with images of 60-80MB you need to run with a larger than default maximum
heap size. A heap profile via hprof and printing out details about the heap each
GC can help diagnose what is happening with the virtual memory that the heap
consists of.

One possible approach to dealing with very large images, assuming its on-disk
format is suitable (e.g. the sample data is uncompressed with a regular layout),
might be to define a specialisation of DataBuffer (which is abstract) in which
the implementation uses a MappedByteBuffer to access directly the raw data out
of the on-disk file format. Memory management would then largely be outside of
the java heap, and be left up to the OS and its interaction with the filesystem.
This is only suggested for where the heap cannot be made big enough even when
using tiling.

The comments about C and memory management I think are specious. A free() of
a pointer in C doesn't actually "free" memory, but asserts that threads have
finished accessing it, so that it is safe to reallocate at some point in the
future. Java provides similar but safer functionality. You assert you have
finished with an object by ensuring you have no references to it. The memory
is then able to be reused. Its an implementation detail as to when it actually
gets reused, just as it is in various malloc() implementations. The amount of
buggy C and C++ code that illegally dereference freed pointers is scary, and
so I would argue its they that have "really huge problems with memory management".
I'm also aware of companies that have had to spend weeks chasing down those
problems despite having visibility of all relevant code. I'd concede that some
Java programmers are unaware of the tools and sources of information that can
be used to diagnose memory-related issues in JVMs.

Another aspect of C vs Java comparison for image manipulation is code compilation.
Compiled C and Java code tend not to be able to used the specialised packed integer
arithmetic instructions in MMX or VIS. These require assembler fragments, whether
via assembly code subroutines or embedded inline. Hence some of the implementations
of JAI include native optimised libraries that can be used transparently without
changing application code.

In any case you would expect the libraries to be compiled with reasonable
optimisation. Sometimes overlooked is that Sun's "JVM" is actually a pair of JVMs,
"client" and "server". The client(default) JVM does less optimisation of java
bytecode since its oriented towards fast startup. For image manipulation algorithms
written in Java I would expect the server JVM would be more appropriate, and the
extra time required to generate better native code from byte code would be more than
offset by shorter computation times.

--
============================================================================
,-_|\ Richard Smith - Technical Specialist
/ \ Sun Microsystems Australia Phone : +61 3 9869 6200
richard.smith@Sun.COM Direct : +61 3 9869 6224
\_,-._/ 476 St Kilda Road Fax : +61 3 9869 6290
v Melbourne Vic 3004 Australia
===========================================================================

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Ken Warner

Excellent reply --

A couple of points I'd like to discuss further:

1) The perennial question -- is there a book -- a good reference on
Java Memory Management?

2)

A free() of a pointer in C doesn't actually "free" memory, but
asserts that threads have
finished accessing it, so that it is safe to reallocate at some
point in the future. Java
provides similar but safer functionality. You assert you have
finished with an object by ensuring you have no references to it.

Yes, I know that free() only marks memory as available. A good C
programmer uses free()
appropriately. The standard criticism of C's memory management problems
always includes
bad engineering as the source of the problems. I'm assuming competent C
programmers.

The problem with Java and memory management WRT: competence in
engineering is exactly
the same. But further, in Java, one doesn't always have access to the
objects that have references
to objects one thinks he has removed all references to -- that's kind of
convoluted. What I mean
is that you can't always entirely dereference an object.

I don't know for sure if it is still the case but with anonymous
Threads, there used to be references
to that Thread object somewhere in the JVM and runtime Java that you
can't get to so
you can't dereference them. I've watched the number of Threads grow in
apps and applets that constantly
make anonymous Threads

I think there are similar issues with Images -- I think -- perhaps
Thread related.

Based on recent experience -- Java 1.4.x -- I was as
thorough as I could be in disposing of Image resources yet I could watch
used memory grow each
time I disposed of the previous Image and loaded a new Image. Likely
this is incompetent programming
on my part. Goes to show that Java is not as safe as people assert it is.

3)

These require assembler fragments,

Agreed, although I wasn't thinking of that when I suggested a purpose
built image processing
library. That would be another good reason to do so. Depending of
course on the target user
community. And if you suggest using the Server JVM, then I suppose you
know the target user community
quite well. Well enough to reconfigure their machines to run the
proposed Medical Imaging Application
under the Server JVM

And if you know that, then one could write the appropriate low level
code for those machines so to be
able to use the hardware of those machines advantageously.

I only write this note for the purposes of continuing an interesting
discussion.

I'd like to thank you for the interesting reply.

Ken Warner

Richard Smith wrote:

> At least for Sun's JVM, the so-called "heap" has internal structure,
> such as
> the distinction between New Eden and Tenured spaces. Therefore not all
> of the
> heap memory can be used to hold a single object. However up to a
> limit, the
> size of the heap can be expanded. An OutOfMemory means that the heap
> can be
> expanded no further, and insufficient space could be freed via GC.
> Normally to
> deal with images of 60-80MB you need to run with a larger than default
> maximum
> heap size. A heap profile via hprof and printing out details about the
> heap each
> GC can help diagnose what is happening with the virtual memory that
> the heap
> consists of.
>
> One possible approach to dealing with very large images, assuming its
> on-disk
> format is suitable (e.g. the sample data is uncompressed with a
> regular layout),
> might be to define a specialisation of DataBuffer (which is abstract)
> in which
> the implementation uses a MappedByteBuffer to access directly the raw
> data out
> of the on-disk file format. Memory management would then largely be
> outside of
> the java heap, and be left up to the OS and its interaction with the
> filesystem.
> This is only suggested for where the heap cannot be made big enough
> even when
> using tiling.
>
> The comments about C and memory management I think are specious. A
> free() of
> a pointer in C doesn't actually "free" memory, but asserts that
> threads have
> finished accessing it, so that it is safe to reallocate at some point
> in the
> future. Java provides similar but safer functionality. You assert you
> have
> finished with an object by ensuring you have no references to it. The
> memory
> is then able to be reused. Its an implementation detail as to when it
> actually
> gets reused, just as it is in various malloc() implementations. The
> amount of
> buggy C and C++ code that illegally dereference freed pointers is
> scary, and
> so I would argue its they that have "really huge problems with memory
> management".
> I'm also aware of companies that have had to spend weeks chasing down
> those
> problems despite having visibility of all relevant code. I'd concede
> that some
> Java programmers are unaware of the tools and sources of information
> that can
> be used to diagnose memory-related issues in JVMs.
>
> Another aspect of C vs Java comparison for image manipulation is code
> compilation.
> Compiled C and Java code tend not to be able to used the specialised
> packed integer
> arithmetic instructions in MMX or VIS. These require assembler
> fragments, whether
> via assembly code subroutines or embedded inline. Hence some of the
> implementations
> of JAI include native optimised libraries that can be used
> transparently without
> changing application code.
>
> In any case you would expect the libraries to be compiled with reasonable
> optimisation. Sometimes overlooked is that Sun's "JVM" is actually a
> pair of JVMs,
> "client" and "server". The client(default) JVM does less optimisation
> of java
> bytecode since its oriented towards fast startup. For image
> manipulation algorithms
> written in Java I would expect the server JVM would be more
> appropriate, and the
> extra time required to generate better native code from byte code
> would be more than
> offset by shorter computation times.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Robert Engels

After working with Java for nearly 6 years, and encountering numerous memory
leaks, all but one were caused by improper code on my part, and the other
was caused by improper code in the class libraries. None were caused by
errors in the JVM or Java specification.

As I became more familiar with good 'gc environment' programming practices
(watch out for static variables !), memory leaks have become a thing of the
past.

Almost all memory leaks are going to be caused by a static reference, or a
'inactive' thread (which should be reclaimed during the next cycle).

-----Original Message-----
From: Ken Warner [mailto:kwarner@uneedspeed.net]
Sent: Saturday, May 28, 2005 1:03 PM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Excellent reply --

A couple of points I'd like to discuss further:

1) The perennial question -- is there a book -- a good reference on
Java Memory Management?

2)

A free() of a pointer in C doesn't actually "free" memory, but
asserts that threads have
finished accessing it, so that it is safe to reallocate at some
point in the future. Java
provides similar but safer functionality. You assert you have
finished with an object by ensuring you have no references to it.

Yes, I know that free() only marks memory as available. A good C
programmer uses free()
appropriately. The standard criticism of C's memory management problems
always includes
bad engineering as the source of the problems. I'm assuming competent C
programmers.

The problem with Java and memory management WRT: competence in
engineering is exactly
the same. But further, in Java, one doesn't always have access to the
objects that have references
to objects one thinks he has removed all references to -- that's kind of
convoluted. What I mean
is that you can't always entirely dereference an object.

I don't know for sure if it is still the case but with anonymous
Threads, there used to be references
to that Thread object somewhere in the JVM and runtime Java that you
can't get to so
you can't dereference them. I've watched the number of Threads grow in
apps and applets that constantly
make anonymous Threads

I think there are similar issues with Images -- I think -- perhaps
Thread related.

Based on recent experience -- Java 1.4.x -- I was as
thorough as I could be in disposing of Image resources yet I could watch
used memory grow each
time I disposed of the previous Image and loaded a new Image. Likely
this is incompetent programming
on my part. Goes to show that Java is not as safe as people assert it is.

3)

These require assembler fragments,

Agreed, although I wasn't thinking of that when I suggested a purpose
built image processing
library. That would be another good reason to do so. Depending of
course on the target user
community. And if you suggest using the Server JVM, then I suppose you
know the target user community
quite well. Well enough to reconfigure their machines to run the
proposed Medical Imaging Application
under the Server JVM

And if you know that, then one could write the appropriate low level
code for those machines so to be
able to use the hardware of those machines advantageously.

I only write this note for the purposes of continuing an interesting
discussion.

I'd like to thank you for the interesting reply.

Ken Warner

Richard Smith wrote:

> At least for Sun's JVM, the so-called "heap" has internal structure,
> such as
> the distinction between New Eden and Tenured spaces. Therefore not all
> of the
> heap memory can be used to hold a single object. However up to a
> limit, the
> size of the heap can be expanded. An OutOfMemory means that the heap
> can be
> expanded no further, and insufficient space could be freed via GC.
> Normally to
> deal with images of 60-80MB you need to run with a larger than default
> maximum
> heap size. A heap profile via hprof and printing out details about the
> heap each
> GC can help diagnose what is happening with the virtual memory that
> the heap
> consists of.
>
> One possible approach to dealing with very large images, assuming its
> on-disk
> format is suitable (e.g. the sample data is uncompressed with a
> regular layout),
> might be to define a specialisation of DataBuffer (which is abstract)
> in which
> the implementation uses a MappedByteBuffer to access directly the raw
> data out
> of the on-disk file format. Memory management would then largely be
> outside of
> the java heap, and be left up to the OS and its interaction with the
> filesystem.
> This is only suggested for where the heap cannot be made big enough
> even when
> using tiling.
>
> The comments about C and memory management I think are specious. A
> free() of
> a pointer in C doesn't actually "free" memory, but asserts that
> threads have
> finished accessing it, so that it is safe to reallocate at some point
> in the
> future. Java provides similar but safer functionality. You assert you
> have
> finished with an object by ensuring you have no references to it. The
> memory
> is then able to be reused. Its an implementation detail as to when it
> actually
> gets reused, just as it is in various malloc() implementations. The
> amount of
> buggy C and C++ code that illegally dereference freed pointers is
> scary, and
> so I would argue its they that have "really huge problems with memory
> management".
> I'm also aware of companies that have had to spend weeks chasing down
> those
> problems despite having visibility of all relevant code. I'd concede
> that some
> Java programmers are unaware of the tools and sources of information
> that can
> be used to diagnose memory-related issues in JVMs.
>
> Another aspect of C vs Java comparison for image manipulation is code
> compilation.
> Compiled C and Java code tend not to be able to used the specialised
> packed integer
> arithmetic instructions in MMX or VIS. These require assembler
> fragments, whether
> via assembly code subroutines or embedded inline. Hence some of the
> implementations
> of JAI include native optimised libraries that can be used
> transparently without
> changing application code.
>
> In any case you would expect the libraries to be compiled with reasonable
> optimisation. Sometimes overlooked is that Sun's "JVM" is actually a
> pair of JVMs,
> "client" and "server". The client(default) JVM does less optimisation
> of java
> bytecode since its oriented towards fast startup. For image
> manipulation algorithms
> written in Java I would expect the server JVM would be more
> appropriate, and the
> extra time required to generate better native code from byte code
> would be more than
> offset by shorter computation times.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Paquette, Dan

You also may want to look into picking up a book on this issue. The one
that I used is "Building Imaging Applications with Java Technology" by
Lawrence H. Rodrigues. The ISBN number is 0-201-70074-3.

There may be newer or better references out there, but this one gives a
good overview of imaging in Java and covers AWT Imaging, Java 2D as well
as JAI. It might be a better place to start learning to develop this
kind of application in Java rather than this mailing list.

-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 4:01 PM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Hi all,

Thank u all for ur valuble time.

>Also, are you sure the software is no just loading the visible
portion? I.e. If you have a 1024x768x32bit image displayed, this will
only require approx 2.5 mb. You can use the pixel sampling method to
read the image at the displayed size.

Mr.Robert could u be a little elaborate on what u've said about
the loading the visible portion? or can u help me with a link from where
I can learn about it?

>setting aside the fact that you just made an ass of yourself to
a...

Mr.Loki, I dont think sentences like these do not promote for a
healthy technical interaction. My terming of "Professionals" is an
answer to Robert's assumption of "computer/java beginers". I dont want
ponder much on this issue, but i failed to make sense from what u've
written there. I'd appreciate if u can go thru the earlier posts of this
thread and understand my requirement.

>You set the -Xmx???m switch when you call the java executable;
so this is not something you need to do on each computer. You just need
to create a batch file or shell script that launches your program and
then you can put what ever parameters you want to use in there when you
call the program.

Dear Mr.Dan, can I have a link to a source about this to have a
better Idea of how to do this? I greatly appreciate ur help.

Thank u all friends.
regards
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

[att1.html]

Brian Burkhalter

Reading the documentation is always a good thing. ;-)

In addition to the book mentioned by Dan, there are also two books available
on Java 2D, one by Vincent Hardy and one from O'Reilly. It is essential to
understand the imaging portions of Java2D to work effectively with JAI.

While we are acutely aware of the need for a JAI documentation update,
meanwhile there is this stuff:

API docs (the definitive source):

http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/in...

The 1.0.1 programmer's guide:

http://java.sun.com/products/java-media/jai/forDevelopers/jai1_0_1guide-...

Tech articles:

http://java.sun.com/products/java-media/jai/reference/techart/index.html

Misc (see documentation section):

http://java.sun.com/products/java-media/jai/utilities/jaiutils.html

On Fri, 27 May 2005, Paquette, Dan wrote:

> You also may want to look into picking up a book on this issue. The one
> that I used is "Building Imaging Applications with Java Technology" by
> Lawrence H. Rodrigues. The ISBN number is 0-201-70074-3.
>
> There may be newer or better references out there, but this one gives a
> good overview of imaging in Java and covers AWT Imaging, Java 2D as well
> as JAI. It might be a better place to start learning to develop this
> kind of application in Java rather than this mailing list.

----------------
Brian Burkhalter
Advanced Development, Graphics and Media
Software Chief Technology Office
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Brian Burkhalter

I forgot one URL:

http://java.sun.com/products/java-media/jai/collateral/index.html

In particular the SIGGRAPH notes might be of use.

Brian

On Fri, 27 May 2005, Brian Burkhalter wrote:

> Reading the documentation is always a good thing. ;-)
>
> In addition to the book mentioned by Dan, there are also two books available
> on Java 2D, one by Vincent Hardy and one from O'Reilly. It is essential to
> understand the imaging portions of Java2D to work effectively with JAI.
>
> While we are acutely aware of the need for a JAI documentation update,
> meanwhile there is this stuff:
>
> API docs (the definitive source):
>
> http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/in...
>
> The 1.0.1 programmer's guide:
>
> http://java.sun.com/products/java-media/jai/forDevelopers/jai1_0_1guide-...
>
> Tech articles:
>
> http://java.sun.com/products/java-media/jai/reference/techart/index.html
>
> Misc (see documentation section):
>
> http://java.sun.com/products/java-media/jai/utilities/jaiutils.html
>
> On Fri, 27 May 2005, Paquette, Dan wrote:
>
> > You also may want to look into picking up a book on this issue. The one
> > that I used is "Building Imaging Applications with Java Technology" by
> > Lawrence H. Rodrigues. The ISBN number is 0-201-70074-3.
> >
> > There may be newer or better references out there, but this one gives a
> > good overview of imaging in Java and covers AWT Imaging, Java 2D as well
> > as JAI. It might be a better place to start learning to develop this
> > kind of application in Java rather than this mailing list.
>
> ----------------
> Brian Burkhalter
> Advanced Development, Graphics and Media
> Software Chief Technology Office
> Sun Microsystems, Inc.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This email message is for the sole use of the intended recipient(s)
> and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
> For additional commands, e-mail: interest-help@jai.dev.java.net
>
>

----------------
Brian Burkhalter
Advanced Development, Graphics and Media
Software Chief Technology Office
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Paquette, Dan

It is quite simple.

@echo off
start java -Xmx100m -classpath %YOUR_CLASSPATH_HERE% -jar myApp.jar

This would start your application with a max heap size of ~100 MB. Then
your users can simply double click this batch file to run your program.
There are a million other ways to accomplish this, but you get the basic
idea.

-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 4:01 PM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Hi all,

Thank u all for ur valuble time.

>Also, are you sure the software is no just loading the visible
portion? I.e. If you have a 1024x768x32bit image displayed, this will
only require approx 2.5 mb. You can use the pixel sampling method to
read the image at the displayed size.

Mr.Robert could u be a little elaborate on what u've said about
the loading the visible portion? or can u help me with a link from where
I can learn about it?

>setting aside the fact that you just made an ass of yourself to
a...

Mr.Loki, I dont think sentences like these do not promote for a
healthy technical interaction. My terming of "Professionals" is an
answer to Robert's assumption of "computer/java beginers". I dont want
ponder much on this issue, but i failed to make sense from what u've
written there. I'd appreciate if u can go thru the earlier posts of this
thread and understand my requirement.

>You set the -Xmx???m switch when you call the java executable;
so this is not something you need to do on each computer. You just need
to create a batch file or shell script that launches your program and
then you can put what ever parameters you want to use in there when you
call the program.

Dear Mr.Dan, can I have a link to a source about this to have a
better Idea of how to do this? I greatly appreciate ur help.

Thank u all friends.
regards
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

[att1.html]

Brian Burkhalter

Also see the .bat files in the jai-demos project.

On Fri, 27 May 2005, Paquette, Dan wrote:

> It is quite simple.
>
> @echo off
> start java -Xmx100m -classpath %YOUR_CLASSPATH_HERE% -jar myApp.jar
>
>
> This would start your application with a max heap size of ~100 MB. Then
> your users can simply double click this batch file to run your program.
> There are a million other ways to accomplish this, but you get the basic
> idea.
>
> -----Original Message-----
> From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
> Sent: Friday, May 27, 2005 4:01 PM
> To: interest@jai.dev.java.net
> Subject: Re: [JAI] Memory problem with real big Images?
>
>
>
> Hi all,
>
> Thank u all for ur valuble time.
>
> >Also, are you sure the software is no just loading the visible
> portion? I.e. If you have a 1024x768x32bit image displayed, this will
> only require approx 2.5 mb. You can use the pixel sampling method to
> read the image at the displayed size.
>
> Mr.Robert could u be a little elaborate on what u've said about
> the loading the visible portion? or can u help me with a link from where
> I can learn about it?
>
> >setting aside the fact that you just made an ass of yourself to
> a...
>
> Mr.Loki, I dont think sentences like these do not promote for a
> healthy technical interaction. My terming of "Professionals" is an
> answer to Robert's assumption of "computer/java beginers". I dont want
> ponder much on this issue, but i failed to make sense from what u've
> written there. I'd appreciate if u can go thru the earlier posts of this
> thread and understand my requirement.
>
> >You set the -Xmx???m switch when you call the java executable;
> so this is not something you need to do on each computer. You just need
> to create a batch file or shell script that launches your program and
> then you can put what ever parameters you want to use in there when you
> call the program.
>
> Dear Mr.Dan, can I have a link to a source about this to have a
> better Idea of how to do this? I greatly appreciate ur help.
>
> Thank u all friends.
> regards
> Rajesh Rapaka.
>
>
>
> --
> R.Rajesh,
> Computer Engineer (Java Developer),
> Eroglu Software Company,
> Eskisehir, Turkey.
>
>

----------------
Brian Burkhalter
Advanced Development, Graphics and Media
Software Chief Technology Office
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Paquette, Dan

You set the -Xmx???m switch when you call the java executable; so this
is not something you need to do on each computer. You just need to
create a batch file or shell script that launches your program and then
you can put what ever parameters you want to use in there when you call
the program.

As for memory usage. You really need to look into how that prototype is
working. I doubt that the entirety of those images is loaded into RAM
(since they would take at least as much space in RAM assuming they do
not have some kind of negative compression or loads of metadata).

There is nothing magic to any of this. You just have to make sure that
you only load the pieces of the image that are relevent at a given time.
This is what makes the JAI method so appealing. Since this is a pull
model only the relevent pixel information needs to exist at any given
time (and through the joys of the tile cache you can at least keep as
much of it around in RAM as you have spare RAM).

If you need to create a lower resolution version of an image to display
on the screen you may have to load pieces (or tiles) of the image at a
time into RAM and convert those to the lower resolution tiles that you
build the full low resolution image out of. If your data does not
support tiling nativly then you'll just have to build yourself some code
that can tile it for you on the fly. I'm not familiar with your data
type at all so I can't really speak to that.

-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 11:11 AM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Hi Robert,
Thank u for ur time. But Professionals in Java do not prefer to
change the heap settings. Because they will be writing softwares that
will work on 500 to 800 computers. and one cant expect the programmer to
go the every computer and set the Heap. I am looking for a much
practical solution.

check my previous reply, in which i've written about a prototype
that's utilising only 23MB to load images of 216MB.

thank u for ur time.
kind regards,
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

[att1.html]

Nidel, Mike

Other people have written Java/JAI apps that process images like yours. However, I don't think you will
succeed under the constraint that you only use 30MB of RAM. I think that your expectations of the
performance of software under those constraints is unreasonable.

As I have said before, if you need to have every pixel of the image in memory at once, then you need
to have enough RAM to hold it. That applies to any piece of software, whether written in Java or any
other language.

You haven't mentioned the details of your format yet, which is an important factor. Certain image
formats make it easier to load only a portion of the image into memory because they are divided into
tiles or strips. JAI's operators provide a tile caching mechanism which will manage the memory needed
for your operations. If your image is tiled, then I suggest you look at loading it only a few tiles at a time,
and using a tile cache for the operations.

About the garbage collector: If you are allocating memory and the VM decides that there is not enough
free memory remaining, it will perform garbage collection. At this point, any objects that you had
previously allocated, which are no longer referenced, will be garbage collected. If garbage collection is
not freeing up memory then you must be keeping a reference to the objects somewhere.

Please give us some more information about your images so we can help you. It might be helpful for
you to do some more analysis of your application to understand where your memory requirements are
and how you can squeeze an application into 30MB of RAM. Even Microsoft Outlook takes up that much
memory on my computer, and it doesn't need to load any 60MB chunks of data ;-)

Mike

-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 2:20 AM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

I am trying to develop a medical image editor using JAVA ! But it seems that JAVA is a bad option for Image processing. Because it is allocating huge amounts of memory and is not freeing them at once. we are supposed to wait for the Garbage collector to collect. This could be straight away disqualifying my software.

The problem now is that I am trying to load and display huge images and perform functions like, Zoom, Brightening, darkening, marking etc. But the Images are not loaded because of the requirement of huge memory space. around 60MB. And these image do not get loaded. and I get an out of memory exception. How can i load these image and display them using JAVA on a machine with 512MB ram? where the free ram is only 30MB.

hope u can help me with it.
thanks in Advance.
Regards,
Rajesh Rapaka.

On 5/26/05, Nidel, Mike < mike.nidel@lmco.com> wrote:

The problem seems to be a very simple physical one: if you need to have the entire image in memory at once,
you will need a heap large enough to hold it. Even if you break the image into many smaller images, if you load
them all at the same time then you will not be able to escape the memory requirement. And if you "append" them
all back together, you'll spend a lot of time copying data.

You should provide more information on what you are trying to do with the image, since it is not clear from your
descriptions thus far. Why do you need to append two BufferedImages? What you ultimately want to do with the
image or learn from it should determine how you load and manipulate it.

What is the format of the image? Are you using one of the built-in ImageReaders/Codecs? Or are you writing
custom code to load your image?

-----Original Message-----
From: R Rajesh [mailto: rajesh.rapaka@gmail.com]
Sent: Thursday, May 26, 2005 9:12 AM
To: interest@jai.dev.java.net

Subject: Re: [JAI] Memory problem with real big Images?

Hi,
Is it possible to make small BufferedImages, and later add them into one BufferedImage? In this way atleast the huge pixel arrays will be deleted from use. But the huge memory required for the BufferedImage will still be there.

I would like to know if it is possible to add or truely speaking append two bufferedimages and produce one bufferedImage.

Thanks in advance,
regards,
Rajesh Rapaka.

On 5/25/05, Nidel, Mike < mike.nidel@lmco.com > wrote:

First off, if you want to avoid loading the entire image into memory, you do not want to use BufferedImage.
This is because BufferedImage will always load the whole image.

Your ability to load only part of the image at a time will depend on the format of the image. If it is a tiled format,
or if there is an ImageReader that allows reading a subregion of the image, then you should be able to do what
you want.

If you really do need to create a DataBuffer with the entire image data, then there is no way you can do this
without storing it all in memory (at least not that I know).

-----Original Message-----
From: R Rajesh [mailto: rajesh.rapaka@gmail.com]
Sent: Wednesday, May 25, 2005 5:36 AM
To: interest@jai.dev.java.net
Subject: [JAI] Memory problem with real big Images?

Hi,

I am dealing with really big Medical Images. Each Image is around 60MB to 80MB. So Obviously the no.of Pixels is very high.
In my current algorithm I am allocating a single array to store all the pixels. So this is giving me "OutofMemory error". I am forced to store the pixels in a single array since I am making a DataBuffer with it. And this DataBuffer is used to create the BufferedImage in return.
Is there any different way in which I can use the memory effectively? Any different ways in which I can develop a BufferedImage?

Thanks in advance,
Kind Regards,
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

[att1.html]

Robert Engels

I only state this because some people still don't know this (Java/computer
beginners)...

Although your machine has 512mb of RAM, that does not mean that is how much
is available to your Java program.

The maximum heap used by Java (for the most part this is equal the programs
dynamic memory), is controlled via the setting

-XmxNNNNm

where NNNN is the number of megabytes. If you do not set this, you are
usually limited to 64mb by default. When you factor out the program and the
runtime, you may be left with 30mb. You need to set this option when dealing
with large images.

Also, you can set this number to a number higher than the physical ram in
the machine. You will pay a performance penalty, but it may be the only only
option.

-----Original Message-----
From: Nidel, Mike [mailto:mike.nidel@lmco.com]
Sent: Friday, May 27, 2005 7:51 AM
To: interest@jai.dev.java.net
Subject: RE: [JAI] Memory problem with real big Images?

Other people have written Java/JAI apps that process images like yours.
However, I don't think you will
succeed under the constraint that you only use 30MB of RAM. I think that
your expectations of the
performance of software under those constraints is unreasonable.

As I have said before, if you need to have every pixel of the image in
memory at once, then you need
to have enough RAM to hold it. That applies to any piece of software,
whether written in Java or any
other language.

You haven't mentioned the details of your format yet, which is an
important factor. Certain image
formats make it easier to load only a portion of the image into memory
because they are divided into
tiles or strips. JAI's operators provide a tile caching mechanism which
will manage the memory needed
for your operations. If your image is tiled, then I suggest you look at
loading it only a few tiles at a time,
and using a tile cache for the operations.

About the garbage collector: If you are allocating memory and the VM
decides that there is not enough
free memory remaining, it will perform garbage collection. At this point,
any objects that you had
previously allocated, which are no longer referenced, will be garbage
collected. If garbage collection is
not freeing up memory then you must be keeping a reference to the objects
somewhere.

Please give us some more information about your images so we can help you.
It might be helpful for
you to do some more analysis of your application to understand where your
memory requirements are
and how you can squeeze an application into 30MB of RAM. Even Microsoft
Outlook takes up that much
memory on my computer, and it doesn't need to load any 60MB chunks of data
;-)

Mike

-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 2:20 AM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

I am trying to develop a medical image editor using JAVA ! But it seems
that JAVA is a bad option for Image processing. Because it is allocating
huge amounts of memory and is not freeing them at once. we are supposed to
wait for the Garbage collector to collect. This could be straight away
disqualifying my software.

The problem now is that I am trying to load and display huge images and
perform functions like, Zoom, Brightening, darkening, marking etc. But the
Images are not loaded because of the requirement of huge memory space.
around 60MB. And these image do not get loaded. and I get an out of memory
exception. How can i load these image and display them using JAVA on a
machine with 512MB ram? where the free ram is only 30MB.

hope u can help me with it.
thanks in Advance.
Regards,
Rajesh Rapaka.

On 5/26/05, Nidel, Mike wrote:
The problem seems to be a very simple physical one: if you need to
have the entire image in memory at once,
you will need a heap large enough to hold it. Even if you break the
image into many smaller images, if you load
them all at the same time then you will not be able to escape the
memory requirement. And if you "append" them
all back together, you'll spend a lot of time copying data.

You should provide more information on what you are trying to do with
the image, since it is not clear from your
descriptions thus far. Why do you need to append two BufferedImages?
What you ultimately want to do with the
image or learn from it should determine how you load and manipulate
it.

What is the format of the image? Are you using one of the built-in
ImageReaders/Codecs? Or are you writing
custom code to load your image?

-----Original Message-----
From: R Rajesh [mailto: rajesh.rapaka@gmail.com]
Sent: Thursday, May 26, 2005 9:12 AM
To: interest@jai.dev.java.net

Subject: Re: [JAI] Memory problem with real big Images?

Hi,
Is it possible to make small BufferedImages, and later add them into
one BufferedImage? In this way atleast the huge pixel arrays will be deleted
from use. But the huge memory required for the BufferedImage will still be
there.

I would like to know if it is possible to add or truely speaking
append two bufferedimages and produce one bufferedImage.

Thanks in advance,
regards,
Rajesh Rapaka.

On 5/25/05, Nidel, Mike wrote:
First off, if you want to avoid loading the entire image into
memory, you do not want to use BufferedImage.
This is because BufferedImage will always load the whole image.

Your ability to load only part of the image at a time will depend
on the format of the image. If it is a tiled format,
or if there is an ImageReader that allows reading a subregion of
the image, then you should be able to do what
you want.

If you really do need to create a DataBuffer with the entire image
data, then there is no way you can do this
without storing it all in memory (at least not that I know).
-----Original Message-----
From: R Rajesh [mailto: rajesh.rapaka@gmail.com]
Sent: Wednesday, May 25, 2005 5:36 AM
To: interest@jai.dev.java.net
Subject: [JAI] Memory problem with real big Images?

Hi,

I am dealing with really big Medical Images. Each Image is
around 60MB to 80MB. So Obviously the no.of Pixels is very high.
In my current algorithm I am allocating a single array to store
all the pixels. So this is giving me "OutofMemory error". I am forced to
store the pixels in a single array since I am making a DataBuffer with it.
And this DataBuffer is used to create the BufferedImage in return.
Is there any different way in which I can use the memory
effectively? Any different ways in which I can develop a BufferedImage?

Thanks in advance,
Kind Regards,
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

R Rajesh

Hi Robert,
Thank u for ur time. But Professionals in Java do not prefer to change the
heap settings. Because they will be writing softwares that will work on 500
to 800 computers. and one cant expect the programmer to go the every
computer and set the Heap. I am looking for a much practical solution.
check my previous reply, in which i've written about a prototype that's
utilising only 23MB to load images of 216MB.
thank u for ur time.
kind regards,
Rajesh Rapaka.
--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

Robert Engels

Depending on how you deploy the application, you do not need to go to each
computer and change the heap setting. Most Java professionals would know
that.

As for working with anything that requires 54mb of memory. If you don't have
54mb of memory available, you cannot process it UNLESS you process it in
chunks, most likely reading a chunk for the image on disk directly. There is
no MAGIC in computers, do the math.

Also, are you sure the software is no just loading the visible portion? I.e.
If you have a 1024x768x32bit image displayed, this will only require approx
2.5 mb. You can use the pixel sampling method to read the image at the
displayed size.
-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Friday, May 27, 2005 10:11 AM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Hi Robert,
Thank u for ur time. But Professionals in Java do not prefer to change the
heap settings. Because they will be writing softwares that will work on 500
to 800 computers. and one cant expect the programmer to go the every
computer and set the Heap. I am looking for a much practical solution.

check my previous reply, in which i've written about a prototype that's
utilising only 23MB to load images of 216MB.

thank u for ur time.
kind regards,
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

Nidel, Mike

The problem seems to be a very simple physical one: if you need to have the entire image in memory at once,
you will need a heap large enough to hold it. Even if you break the image into many smaller images, if you load
them all at the same time then you will not be able to escape the memory requirement. And if you "append" them
all back together, you'll spend a lot of time copying data.

You should provide more information on what you are trying to do with the image, since it is not clear from your
descriptions thus far. Why do you need to append two BufferedImages? What you ultimately want to do with the
image or learn from it should determine how you load and manipulate it.

What is the format of the image? Are you using one of the built-in ImageReaders/Codecs? Or are you writing
custom code to load your image?

-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Thursday, May 26, 2005 9:12 AM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

Hi,
Is it possible to make small BufferedImages, and later add them into one BufferedImage? In this way atleast the huge pixel arrays will be deleted from use. But the huge memory required for the BufferedImage will still be there.

I would like to know if it is possible to add or truely speaking append two bufferedimages and produce one bufferedImage.

Thanks in advance,
regards,
Rajesh Rapaka.

On 5/25/05, Nidel, Mike < mike.nidel@lmco.com> wrote:

First off, if you want to avoid loading the entire image into memory, you do not want to use BufferedImage.
This is because BufferedImage will always load the whole image.

Your ability to load only part of the image at a time will depend on the format of the image. If it is a tiled format,
or if there is an ImageReader that allows reading a subregion of the image, then you should be able to do what
you want.

If you really do need to create a DataBuffer with the entire image data, then there is no way you can do this
without storing it all in memory (at least not that I know).

-----Original Message-----
From: R Rajesh [mailto: rajesh.rapaka@gmail.com]
Sent: Wednesday, May 25, 2005 5:36 AM
To: interest@jai.dev.java.net
Subject: [JAI] Memory problem with real big Images?

Hi,

I am dealing with really big Medical Images. Each Image is around 60MB to 80MB. So Obviously the no.of Pixels is very high.
In my current algorithm I am allocating a single array to store all the pixels. So this is giving me "OutofMemory error". I am forced to store the pixels in a single array since I am making a DataBuffer with it. And this DataBuffer is used to create the BufferedImage in return.
Is there any different way in which I can use the memory effectively? Any different ways in which I can develop a BufferedImage?

Thanks in advance,
Kind Regards,
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

[att1.html]

R Rajesh

I am trying to develop a medical image editor using JAVA ! But it seems that
JAVA is a bad option for Image processing. Because it is allocating huge
amounts of memory and is not freeing them at once. we are supposed to wait
for the Garbage collector to collect. This could be straight away
disqualifying my software.
The problem now is that I am trying to load and display huge images and
perform functions like, Zoom, Brightening, darkening, marking etc. But the
Images are not loaded because of the requirement of huge memory space.
around 60MB. And these image do not get loaded. and I get an out of memory
exception. How can i load these image and display them using JAVA on a
machine with 512MB ram? where the free ram is only 30MB.
hope u can help me with it.
thanks in Advance.
Regards,
Rajesh Rapaka.

On 5/26/05, Nidel, Mike wrote:
>
> The problem seems to be a very simple physical one: if you need to have
> the entire image in memory at once,
> you will need a heap large enough to hold it. Even if you break the image
> into many smaller images, if you load
> them all at the same time then you will not be able to escape the memory
> requirement. And if you "append" them
> all back together, you'll spend a lot of time copying data.
> You should provide more information on what you are trying to do with the
> image, since it is not clear from your
> descriptions thus far. Why do you need to append two BufferedImages? What
> you ultimately want to do with the
> image or learn from it should determine how you load and manipulate it.
> What is the format of the image? Are you using one of the built-in
> ImageReaders/Codecs? Or are you writing
> custom code to load your image?
>
> -----Original Message-----
> *From:* R Rajesh [mailto:rajesh.rapaka@gmail.com]
> *Sent:* Thursday, May 26, 2005 9:12 AM
> *To:* interest@jai.dev.java.net
> *Subject:* Re: [JAI] Memory problem with real big Images?
>
> Hi,
> Is it possible to make small BufferedImages, and later add them into one
> BufferedImage? In this way atleast the huge pixel arrays will be deleted
> from use. But the huge memory required for the BufferedImage will still be
> there.
> I would like to know if it is possible to add or truely speaking append
> two bufferedimages and produce one bufferedImage.
> Thanks in advance,
> regards,
> Rajesh Rapaka.
>
> On 5/25/05, Nidel, Mike wrote:
> >
> > First off, if you want to avoid loading the entire image into memory,
> > you do not want to use BufferedImage.
> > This is because BufferedImage will always load the whole image.
> > Your ability to load only part of the image at a time will depend on
> > the format of the image. If it is a tiled format,
> > or if there is an ImageReader that allows reading a subregion of the
> > image, then you should be able to do what
> > you want.
> > If you really do need to create a DataBuffer with the entire image
> > data, then there is no way you can do this
> > without storing it all in memory (at least not that I know).
> >
> > -----Original Message-----
> > *From:* R Rajesh [mailto: rajesh.rapaka@gmail.com]
> > *Sent:* Wednesday, May 25, 2005 5:36 AM
> > *To:* interest@jai.dev.java.net
> > *Subject:* [JAI] Memory problem with real big Images?
> >
> > Hi,
> > I am dealing with really big Medical Images. Each Image is around 60MB
> > to 80MB. So Obviously the no.of Pixels is very high.
> > In my current algorithm I am allocating a single array to store all the
> > pixels. So this is giving me "OutofMemory error". I am forced to store the
> > pixels in a single array since I am making a DataBuffer with it. And this
> > DataBuffer is used to create the BufferedImage in return.
> > Is there any different way in which I can use the memory effectively?
> > Any different ways in which I can develop a BufferedImage?
> > Thanks in advance,
> > Kind Regards,
> > Rajesh Rapaka.
> >
> > --
> > R.Rajesh,
> > Computer Engineer (Java Developer),
> > Eroglu Software Company,
> > Eskisehir, Turkey.
> >
> >
>
>
> --
> R.Rajesh,
> Computer Engineer (Java Developer),
> Eroglu Software Company,
> Eskisehir, Turkey.
>
>

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

Ken Warner

R Rajesh wrote:

>I am trying to develop a medical image editor using JAVA ! But it seems that
>JAVA is a bad option for Image processing. Because it is allocating huge
>amounts of memory and is not freeing them at once. we are supposed to wait
>for the Garbage collector to collect. This could be straight away
>disqualifying my software.
>
>
I've had similar problems. IMHO you probably should go to straight C
(not C++; not C#) Straight C
is still the only language that gives one the absolute control of memory
allocation and deallocation.

Java gives you really nice interface building tools but seems to have
really huge problems with
memory management. The trouble is that Java's memory management is
deeply hidden in the JVM
where you can't get to it to diagnose and fix the problems.

Off the top of my head, a native image handling library in C combined
with a Java interface would
be the best of both worlds. Interface development can take a really
long time and be really expensive
in C. But building a purpose built image processing library in C would
be easier than trying to force
Java to do something it doesn't do well.

That's just my own personal analysis based on my own limited
experience. I invite all of you
to tell me how dumb I am...

Ken Warner
Mammoth Lakes, CA

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

Robert Engels

Sorry, but you are dumb. We have image processing software written in Java
(using ImageIO tools), and it consistently out-performs most native
applications written in C/other - including the GIMP, and Microsoft's Image
& Fax Viewer. When dealing with large images, the algorithms and data
structures chosen are almost always more significant than any inherent
"speed" of the language used to write/run the software. That said, Java does
have "native" C support for many of the time-critical aspects of image
processing.

-----Original Message-----
From: Ken Warner [mailto:kwarner@uneedspeed.net]
Sent: Friday, May 27, 2005 12:34 PM
To: interest@jai.dev.java.net
Subject: Re: [JAI] Memory problem with real big Images?

R Rajesh wrote:

>I am trying to develop a medical image editor using JAVA ! But it seems
that
>JAVA is a bad option for Image processing. Because it is allocating huge
>amounts of memory and is not freeing them at once. we are supposed to wait
>for the Garbage collector to collect. This could be straight away
>disqualifying my software.
>
>
I've had similar problems. IMHO you probably should go to straight C
(not C++; not C#) Straight C
is still the only language that gives one the absolute control of memory
allocation and deallocation.

Java gives you really nice interface building tools but seems to have
really huge problems with
memory management. The trouble is that Java's memory management is
deeply hidden in the JVM
where you can't get to it to diagnose and fix the problems.

Off the top of my head, a native image handling library in C combined
with a Java interface would
be the best of both worlds. Interface development can take a really
long time and be really expensive
in C. But building a purpose built image processing library in C would
be easier than trying to force
Java to do something it doesn't do well.

That's just my own personal analysis based on my own limited
experience. I invite all of you
to tell me how dumb I am...

Ken Warner
Mammoth Lakes, CA

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net
For additional commands, e-mail: interest-help@jai.dev.java.net

R Rajesh

Hi all,
Thank u all for ur valuble time.
>Also, are you sure the software is no just loading the visible portion?
I.e. If you have a 1024x768x32bit image displayed, this will only require
approx 2.5 mb. You can use the pixel sampling method to read the image at
the displayed size.

Mr.Robert could u be a little elaborate on what u've said about the loading
the visible portion? or can u help me with a link from where I can learn
about it?
>setting aside the fact that you just made an ass of yourself to a...

Mr.Loki, I dont think sentences like these do not promote for a healthy
technical interaction. My terming of "Professionals" is an answer to
Robert's assumption of "computer/java beginers". I dont want ponder much on
this issue, but i failed to make sense from what u've written there. I'd
appreciate if u can go thru the earlier posts of this thread and understand
my requirement.
>You set the -Xmx???m switch when you call the java executable; so this is
not something you need to do on each computer. You just need to create a
batch file or shell script that launches your program and then you can put
what ever parameters you want to use in there when you call the program.
Dear Mr.Dan, can I have a link to a source about this to have a better Idea
of how to do this? I greatly appreciate ur help.
Thank u all friends.
regards
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]

Nidel, Mike

First off, if you want to avoid loading the entire image into memory, you do not want to use BufferedImage.
This is because BufferedImage will always load the whole image.

Your ability to load only part of the image at a time will depend on the format of the image. If it is a tiled format,
or if there is an ImageReader that allows reading a subregion of the image, then you should be able to do what
you want.

If you really do need to create a DataBuffer with the entire image data, then there is no way you can do this
without storing it all in memory (at least not that I know).

-----Original Message-----
From: R Rajesh [mailto:rajesh.rapaka@gmail.com]
Sent: Wednesday, May 25, 2005 5:36 AM
To: interest@jai.dev.java.net
Subject: [JAI] Memory problem with real big Images?

Hi,

I am dealing with really big Medical Images. Each Image is around 60MB to 80MB. So Obviously the no.of Pixels is very high.
In my current algorithm I am allocating a single array to store all the pixels. So this is giving me "OutofMemory error". I am forced to store the pixels in a single array since I am making a DataBuffer with it. And this DataBuffer is used to create the BufferedImage in return.
Is there any different way in which I can use the memory effectively? Any different ways in which I can develop a BufferedImage?

Thanks in advance,
Kind Regards,
Rajesh Rapaka.

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.

[att1.html]

R Rajesh

Hi,
Is it possible to make small BufferedImages, and later add them into one
BufferedImage? In this way atleast the huge pixel arrays will be deleted
from use. But the huge memory required for the BufferedImage will still be
there.
I would like to know if it is possible to add or truely speaking append two
bufferedimages and produce one bufferedImage.
Thanks in advance,
regards,
Rajesh Rapaka.

On 5/25/05, Nidel, Mike wrote:
>
> First off, if you want to avoid loading the entire image into memory, you
> do not want to use BufferedImage.
> This is because BufferedImage will always load the whole image.
> Your ability to load only part of the image at a time will depend on the
> format of the image. If it is a tiled format,
> or if there is an ImageReader that allows reading a subregion of the
> image, then you should be able to do what
> you want.
> If you really do need to create a DataBuffer with the entire image data,
> then there is no way you can do this
> without storing it all in memory (at least not that I know).
>
> -----Original Message-----
> *From:* R Rajesh [mailto:rajesh.rapaka@gmail.com]
> *Sent:* Wednesday, May 25, 2005 5:36 AM
> *To:* interest@jai.dev.java.net
> *Subject:* [JAI] Memory problem with real big Images?
>
> Hi,
> I am dealing with really big Medical Images. Each Image is around 60MB to
> 80MB. So Obviously the no.of Pixels is very high.
> In my current algorithm I am allocating a single array to store all the
> pixels. So this is giving me "OutofMemory error". I am forced to store the
> pixels in a single array since I am making a DataBuffer with it. And this
> DataBuffer is used to create the BufferedImage in return.
> Is there any different way in which I can use the memory effectively? Any
> different ways in which I can develop a BufferedImage?
> Thanks in advance,
> Kind Regards,
> Rajesh Rapaka.
>
> --
> R.Rajesh,
> Computer Engineer (Java Developer),
> Eroglu Software Company,
> Eskisehir, Turkey.
>
>

--
R.Rajesh,
Computer Engineer (Java Developer),
Eroglu Software Company,
Eskisehir, Turkey.
[att1.html]