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