Hi Matthias,<div><br></div><div>Thanks for the additional information. The stack trace was helpful in quickly finding the problem.</div><div><br></div><div>It is a bug in ITKBridgePipes (the Java side of BF-ITK), which does not call the method openBytes(no, x, y, w, h) but rather always openBytes(no) and then crops after the fact, as you suspected.</div>
<div><br></div><div>I have a pushed a proposed (untested) fix:</div><div> <a href="https://github.com/ctrueden/bioformats/commit/eb83ace0f0a121c8c44e3fb8b95ec5040f029c55">https://github.com/ctrueden/bioformats/commit/eb83ace0f0a121c8c44e3fb8b95ec5040f029c55</a></div>
<div><br></div><div>I have uploaded a build for you to test at:</div><div> <a href="http://dev.loci.wisc.edu/curtis/2012-07-12-itk-crop/loci_tools.jar">http://dev.loci.wisc.edu/curtis/2012-07-12-itk-crop/loci_tools.jar</a></div>
<div><br></div><div>Just replace your old loci_tools.jar and let us know how it goes! If all is well, I will file a PR to merge the fix into the mainline.</div><div><br></div><div>Regards,</div><div>Curtis</div><div><br>
<br>
<div class="gmail_quote">On Thu, Jul 12, 2012 at 3:52 PM, Matthias Noll <span dir="ltr"><<a href="mailto:matthias.noll@igd.fraunhofer.de" target="_blank">matthias.noll@igd.fraunhofer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Curtis,<br>
I used the IORegion to set a subimage region for reading e.g.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ImageType2D::SizeType smallSize;<br>
smallSize.Fill(500);<br>
ImageType2D::IndexType index;<br>
index.Fill(0);<br>
ImageType2D::RegionType region(index, smallSize);<br>
try{<br>
m_reader->GetOutput()-><u></u>SetRequestedRegion(region);<br>
m_reader->Update();<br>
}catch(itk::ExceptionObject &e){return;}<br>
</blockquote>
<br>
<br>
The debug window shows that the region is set correctly. Also the read command consists of filename and selected image region.<br>
So I would say the itk side of the reader is well in order. At least as far as I can tell right now.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Debug: In j:\itk4_1_bio\itk4.1.0\src\<u></u>modules\io\imagebase\include\<u></u>itkImageIOBase.h, line 161<br>
BioFormatsImageIO (0000000003689390): setting IORegion to ImageIORegion (0000000000B1F2D8)<br>
Dimension: 2<br>
Index: 0 0<br>
Size: 500 500<br>
<br>
Debug: In J:\ITK4_1_Bio\bioformats\src\<u></u>components\native\bf-itk-pipe\<u></u>itkBioFormatsImageIO.cxx, line 647<br>
BioFormatsImageIO (0000000003689390): BioFormatsImageIO::Read<br>
<br>
Debug: In J:\ITK4_1_Bio\bioformats\src\<u></u>components\native\bf-itk-pipe\<u></u>itkBioFormatsImageIO.cxx, line 668<br>
BioFormatsImageIO (0000000003689390): BioFormatsImageIO::Read command: read D:/CD45ROdk_c03H1665-8_n1_RS2 - 2010-11-30-largest.ome.tif 0 500 0 500 0 1 0 1 0 1<br>
<br>
Debug: In J:\ITK4_1_Bio\bioformats\src\<u></u>components\native\bf-itk-pipe\<u></u>itkBioFormatsImageIO.cxx, line 284<br>
BioFormatsImageIO (0000000003689390): BioFormatsImageIO::<u></u>DestroyJavaProcess killing java process<br>
<br>
Debug: In J:\ITK4_1_Bio\bioformats\src\<u></u>components\native\bf-itk-pipe\<u></u>itkBioFormatsImageIO.cxx, line 289<br>
BioFormatsImageIO (0000000003689390): BioFormatsImageIO::<u></u>DestroyJavaProcess destroying java process<br>
</blockquote>
<br>
But looking at the following error message of the piped java exception, the openBytes() function in FormatReader.java tries to allocate an array of the dimension 69632 x 37888 x 3 x 1 whereas is should only allocate the requested 500x500x3x1.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
itk::ERROR: BioFormatsImageIO(<u></u>0000000003689390): BioFormatsImageIO: 'ITKBridgePipe read' exited abnormally. Exception in thread "main" loci.formats.FormatException: Image plane too large. Only 2GB of data can be extracted at one time. You can workaround the problem by opening the plane in tiles; for further details, see: <a href="http://www.openmicroscopy.org/site/support/faq/bio-formats/i-see-an-outofmemory-or-negativearraysize-error-message-when-attempting-to-open-an-svs-or-jpeg-2000-file.-what-does-this-mean" target="_blank">http://www.openmicroscopy.org/<u></u>site/support/faq/bio-formats/<u></u>i-see-an-outofmemory-or-<u></u>negativearraysize-error-<u></u>message-when-attempting-to-<u></u>open-an-svs-or-jpeg-2000-file.<u></u>-what-does-this-mean</a><br>
at loci.formats.FormatReader.<u></u>openBytes(FormatReader.java:<u></u>760)<br>
at loci.formats.FormatReader.<u></u>openBytes(FormatReader.java:<u></u>739)<br>
at loci.formats.ImageReader.<u></u>openBytes(ImageReader.java:<u></u>393)<br>
at loci.formats.itk.<u></u>ITKBridgePipes.read(<u></u>ITKBridgePipes.java:325)<br>
at loci.formats.itk.<u></u>ITKBridgePipes.executeCommand(<u></u>ITKBridgePipes.java:133)<br>
at loci.formats.itk.<u></u>ITKBridgePipes.waitForInput(<u></u>ITKBridgePipes.java:94)<br>
at loci.formats.itk.<u></u>ITKBridgePipes.main(<u></u>ITKBridgePipes.java:554)<br>
Caused by: java.lang.<u></u>IllegalArgumentException: Array size too large: 69632 x 37888 x 3 x 1<br>
at loci.common.DataTools.<u></u>safeMultiply32(DataTools.java:<u></u>888)<br>
at loci.common.DataTools.<u></u>allocate(DataTools.java:862)<br>
at loci.formats.FormatReader.<u></u>openBytes(FormatReader.java:<u></u>757)<br>
... 6 more<br>
</blockquote>
<br>
I'm not sure where this problem arises, since I can't debug the java part, at least I'm not sure how to. Maybe the java part of the reader resets the image region with the actual image header information, reads out everything and crops the result later, if the reading worked.<br>
I tested this with a smaller image of the dimensions 19000x8000 and the same requested region. This worked but the read took a while. And also I had to change the java vm memory from 265MB to 1024MB which points also to a large amount of data allocation.<br>
<br>
Best regards,<br>
Matthias<br>
<br>
<br>
Am 12/07/2012 21:44, schrieb Curtis Rueden:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matthias,<br>
<br>
<br><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now I encountered another problem. With normal sized images everything<br>
works fine. But since I pretty much only have images that are larger than<br>
2GB, the Java machine has not enough memory to "load" the whole image<br>
plane. However this is not really what I want to do anyway. It seems that<br>
itk has a way to manage large files by opening them using streams. An image<br>
is split into pieces on read so that large images can be processes<br>
sequentially. I'm not sure but this functionality seems not to be<br>
implemented down to the wrapping bioformat reader for itk.<br>
</blockquote>
<br>
As you observed, Bio-Formats has the capability to read in only a subset of<br>
image data, including a cropped region of each XY plane. The BF-ITK plugin<br>
is supposed to provide this capability as well, using the "IORegion"<br>
feature of ITK ImageIO. That said, we have not really tested this feature,<br>
and there may be a problem with it. I am actually not even sure how the<br>
calling code should go about specifying the IORegion. But I suggest you<br>
give it a try (ask on ITK-users if you need assistance) and then report<br>
back if you find any problems with it.<br>
<br>
HTH,<br>
Curtis<br>
<br>
<br>
On Wed, Jul 11, 2012 at 3:54 AM, Matthias Noll <<br>
<a href="mailto:matthias.noll@igd.fraunhofer.de" target="_blank">matthias.noll@igd.fraunhofer.<u></u>de</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Churtis,<br>
<br>
I managed to apply the reader after deregistration of other readers that<br>
were interfering in the reader selection.<br>
<br>
Now I encountered another problem. With normal sized images everything<br>
works fine. But since I pretty much only have images that are larger than<br>
2GB, the Java machine has not enough memory to "load" the whole image<br>
plane. However this is not really what I want to do anyway. It seems that<br>
itk has a way to manage large files by opening them using streams. An image<br>
is split into pieces on read so that large images can be processes<br>
sequentially. I'm not sure but this functionality seems not to be<br>
implemented down to the wrapping bioformat reader for itk.<br>
<br></div></div>
itk::ERROR: BioFormatsImageIO(**<u></u>0000000003815B60): BioFormatsImageIO:<div class="im"><br>
'ITKBridgePipe read' exited abnormally. Exception in thread "main"<br>
loci.formats.FormatException: Image plane too large. Only 2GB of data can<br>
be extracted at one time.<br>
<br>
Looking at the error message, the Java wrapped code obviously wants to<br>
read in the whole image. The cropping seems to be done after the complete<br>
image is read.<br>
<br>
I also found this page using the error output.<br>
</div><a href="http://www.openmicroscopy.org/**site/support/faq/bio-formats/**" target="_blank">http://www.openmicroscopy.org/<u></u>**site/support/faq/bio-<u></u>formats/**</a><br>
i-see-an-outofmemory-or-**<u></u>negativearraysize-error-**<br>
message-when-attempting-to-**<u></u>open-an-svs-or-jpeg-2000-file.<u></u>**<br>
-what-does-this-mean<<a href="http://www.openmicroscopy.org/site/support/faq/bio-formats/i-see-an-outofmemory-or-negativearraysize-error-message-when-attempting-to-open-an-svs-or-jpeg-2000-file.-what-does-this-mean" target="_blank">http://<u></u>www.openmicroscopy.org/site/<u></u>support/faq/bio-formats/i-see-<u></u>an-outofmemory-or-<u></u>negativearraysize-error-<u></u>message-when-attempting-to-<u></u>open-an-svs-or-jpeg-2000-file.<u></u>-what-does-this-mean</a>><div class="im">
<br>
<br>
I could use the option to increase the JVM memory space but this would<br>
only help me so far. With really large images that exceed my memory I would<br>
still have a problem. Is there a way to get around the complete read-in of<br>
the input with the itk reader that I've misses so far?<br>
<br>
Best Regards,<br>
Matthias<br>
<br>
Am 7/2/2012 7:25 PM, schrieb Curtis Rueden:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hi Matthias,<br>
<br>
I want to use the cpp wrapped bioformat reader with itk to read<br>
ome.tif files. The interfacing with itk however is kind of not<br>
working properly. First I have to unregister the base readers (jpg,<br></div>
png etc. )using the command itk::ObjectFactoryBase::__**<u></u>ReHash(); If<div class="im"><br>
I<br>
<br>
don't do this, one of base readers will try to load the tiff image.<br>
Namely the TiffImageIO. Since the image in question is tiled, this<br>
read operation will fail. And therfore the bioformat reader will<br>
never be activated. If I use the ReHash() function, the bioformat<br>
reading works, but all other reader/writers are unregistered in the<br>
ObjectFactoryBase. In registering them manually for e.g. png saving<br>
a output region of the read ome.tiff image. The bioformat reader<br>
will always tell itk that he can write the input image. But he sould<br>
not, since I choose .png as the output format. I'm not quite shure<br>
what I'm doing wrong concerning the reader. I thought the plugin<br>
should behave as a normal itk reader/writer.<br>
<br>
<br>
I am CCing the ITK-users list, since I think your question is a more<br>
general one about the ITK ImageIO plugin mechanism. It seems to me that<br>
all you really need is a simple way to reshuffle the order of the<br>
available ImageIO plugins—in this case, to give the Bio-Formats ITK<br>
plugin a higher priority than the built-in TIFF ImageIO plugin. Does<br>
anyone know a good way to do this?<br>
<br>
Thanks,<br>
Curtis<br>
<br>
P.S. The ImageIO plugin Matthias is talking about is here:<br>
</div><a href="http://loci.wisc.edu/bio-**formats/itk" target="_blank">http://loci.wisc.edu/bio-**<u></u>formats/itk</a><<a href="http://loci.wisc.edu/bio-formats/itk" target="_blank">http://loci.wisc.<u></u>edu/bio-formats/itk</a>><br>
<br>
<br>
On Mon, Jul 2, 2012 at 11:09 AM, <matthias.noll@igd.fraunhofer.<u></u>**de<<a href="mailto:matthias.noll@igd.fraunhofer.de" target="_blank">matthias.noll@igd.<u></u>fraunhofer.de</a>><br>
<mailto:<a href="mailto:matthias.noll@igd." target="_blank">matthias.noll@igd.</a>**<a href="http://fraunhofer.de" target="_blank">fr<u></u>aunhofer.de</a><<a href="mailto:matthias.noll@igd.fraunhofer.de" target="_blank">matthias.noll@igd.<u></u>fraunhofer.de</a>>>><div class="im">
<br>
wrote:<br>
<br>
Matthias Noll sent a message using the contact form at<br>
<a href="http://loci.wisc.edu/contact" target="_blank">http://loci.wisc.edu/contact</a>.<br>
<br>
Hello,<br>
I want to use the cpp wrapped bioformat reader with itk to read<br>
ome.tif files. The interfacing with itk however is kind of not<br>
working properly. First I have to unregister the base readers (jpg,<br></div>
png etc. )using the command itk::ObjectFactoryBase::__**<u></u>ReHash(); If<div class="im"><br>
I<br>
<br>
don't do this, one of base readers will try to load the tiff image.<br>
Namely the TiffImageIO. Since the image in question is tiled, this<br>
read operation will fail. And therfore the bioformat reader will<br>
never be activated. If I use the ReHash() function, the bioformat<br>
reading works, but all other reader/writers are unregistered in the<br>
ObjectFactoryBase. In registering them manually for e.g. png saving<br>
a output region of the read ome.tiff image. The bioformat reader<br>
will always tell itk that he can write the input image. But he sould<br>
not, since I choose .png as the output format. I'm not quite shure<br>
what I'm doing wrong concerning the reader. I thought the plugin<br>
should behave as a normal itk reader/writer.<br>
I'm greatful for any kind of help.<br>
Thanks Matthias<br>
<br>
<br>
<br>
</div></blockquote></blockquote></blockquote>
<br>
<br>
</blockquote></div><br></div>