Reply To: Error: java.lang.NegativeArraySizeException

Activity Forums Astrosoftware Astro Pixel Processor Error: java.lang.NegativeArraySizeException Reply To: Error: java.lang.NegativeArraySizeException

#15104
Haverkamp
Participant

@whwang,

“It still shows an out of memory error.  What’s funny is that I once successfully stitched all the panels together using a computer with just 16 GB of RAM.  ”

By looking at the error, I think I know what’s happening. My initial guess would be that:

After registration, APP finds a field of view that is too large too fit into the image structure that I currently use in APP. The limit now is that the amount of pixels of an image can’t exceed 2^31 = 2,147,483,648 = 2 billion pixels. So the image can’t be created. The amount of memory is not the limitation here. You are the first one that triggers this if my guess is correct.

If you are using the calibrated projective registration model and use equirectangular projection in the integration then I am a bit surprised though that this is triggered with your 40 panels mosaic,

With 2 billion pixels being the limit at the moment, this means that for an RGB image of 2 billion pixel in 32bits float format, this image needs a memory allocation of = (2^31) * 4 (8bits bytes to 32bits floats) * 3 (3 channels) = 24GBs of memory..

For stacking or other operations, APP would need this amount times three = 72GBs  currently. I set this conservatively at the moment. So the 80GBs of memory should handle such an image I think.

To prevent this error from happening and still being able to create the image within the 2GB limit, I need APP to automatically adjust the scale of the composition so it would fit into the 2GB limitation on the amount of pixels. Then the error is not thrown, the user will get a proper warning and the image would still be created although at a smaller scale. I’ll fix this today.

“Another potential bug. On this computer, I closed APP after the out of memory error. Then I launched it again. The RAM assigned to APP went back to 1 GB automatically, instead of 80 GB.  This happened once on my other computer yesterday.  It will be nice to force this setting unchanged every time, unless the users changes it.”

This is strange, especially since the default value is 2GB. If the user override isn’t working it should default to 2GB. I know that if you open the CFG menu, it always starts at 1GB, is this what you are seeing? Or do you actually see “mem x / 1024” at the top left after having set the memory at a certain value and a restart of APP?

This setting should be forced indeed, I have tested this on Windows, MacOS en Linux and it works on my systems. I set it once and it always works.

“Feature request:  it will be nice if the “set work directory” button remembers the work directory from last time. At this moment, it goes to the home directory every time I launch APP and click the “set work directory” button. It will be much more convenient if it stays where it was. Even if we want to use a different work directory every time, going from where it was will still be faster than going from home, since astronomical files tend to sit in a more confined region in a big computer.”

Will add this to the RFC, is quite usefull indeed.

“Finally, the launching time of APP on this second computer is just a few seconds, many many times faster than on the other computer. However, this computer is not faster than the previously one.  It has more cores and much more RAM, but these shouldn’t affect how fast an app launches.”

Yes, I agree, it’s strange behaviour and possibly due to some OS configuration in combination with APP startup parameters. You are the first to report this. I’ll build the next version with slightly different startup parameters to see if it has some influence. I will also investigate if it somehow relates to license verification.

Thank you for your feedback Wei-Hao ?

Mabula

Scroll to Top