We're Hiring!

Large OME-Tiffs exported by Zeiss ZEN 2

General user discussion about using the OMERO platform to its fullest. Please ask new questions at https://forum.image.sc/tags/omero
Please note:
Historical discussions about OMERO. Please look for and ask new questions at https://forum.image.sc/tags/omero

There are workflow guides for various OMERO functions on our help site - http://help.openmicroscopy.org

You should find answers to any basic questions about using the clients there.

Large OME-Tiffs exported by Zeiss ZEN 2

Postby dsudar » Sat Oct 03, 2015 8:17 pm

Hi,

On our Zeiss Axioscan slide scanner, we generate very large images (50k by 60k pixels in 4 fl. colors). Understood that the default jpeg-xr compression in Zeiss's CZI is not supported in BioFormats, I tried exporting the files as OME-Tiffs using the BIGTIFF checkbox checked and Stitching on. The resulting file is large (20+ GB) and I tried to use the CLI importer to import into OMERO 5.1.4. In the Pixel-Data.log at first it all looks good but then there's a NullPointer exception:

2015-10-03 12:22:24,066 INFO [ ome.io.nio.FilePathResolver] (2-thread-1) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/dsudar_2/2015-10/03/12-11-02.553/Stitched_NewOUtput_s1.ome.tiff
2015-10-03 12:22:24,066 INFO [ ome.io.nio.FilePathResolver] (2-thread-5) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/dsudar_2/2015-10/03/12-11-02.553/Stitched_NewOUtput_s1.ome.tiff
2015-10-03 12:22:24,088 WARN [ ome.services.pixeldata.PixelDataHandler] (2-thread-5) Pixels:312801 -- Already locked! /data/OMERO.data/Pixels/Dir-312/.312801_pyramid.pyr_lock
2015-10-03 12:22:25,072 INFO [ ome.io.nio.PixelsService] (2-thread-1) Creating BfPixelBuffer: /data/OMERO.data/ManagedRepository/dsudar_2/2015-10/03/12-11-02.553/Stitched_NewOUtput_s1.ome.tiff Series: 0
2015-10-03 12:22:25,073 INFO [ ome.io.nio.PixelsService] (2-thread-1) Destination pyramid tile size: java.awt.Dimension[width=1664,height=1232]
2015-10-03 12:22:25,074 INFO [ ome.io.nio.PixelsService] (2-thread-1) Pyramid creation for Pixels:312801 1/6888 (0%).
2015-10-03 12:22:25,774 INFO [ loci.formats.in.MinimalTiffReader] (2-thread-1) Reading IFDs
2015-10-03 12:22:25,776 INFO [ loci.formats.in.MinimalTiffReader] (2-thread-1) Populating metadata
2015-10-03 12:22:25,844 INFO [ loci.formats.in.JPEG2000MetadataParser] (2-thread-1) Unknown JPEG 2000 box 0x2900 at 28002
2015-10-03 12:22:25,845 INFO [ loci.formats.in.JPEG2000MetadataParser] (2-thread-1) File is a raw codestream not a JP2.
2015-10-03 12:22:25,854 INFO [ loci.formats.in.TiffReader] (2-thread-1) Checking comment style
2015-10-03 12:22:25,856 INFO [ loci.formats.in.BaseTiffReader] (2-thread-1) Populating OME metadata
2015-10-03 12:22:28,922 ERROR [ ome.services.pixeldata.PixelDataHandler] (2-thread-1) Failed to handle pixels 312801
java.lang.NullPointerException: null
at loci.common.RandomAccessInputStream.getFilePointer(RandomAccessInputStream.java:198) ~[formats-common.jar:5.1.4]
at loci.formats.tiff.OnDemandLongArray.toArray(OnDemandLongArray.java:79) ~[formats-bsd.jar:5.1.4]
at loci.formats.tiff.TiffParser.getSamples(TiffParser.java:858) ~[formats-bsd.jar:5.1.4]
at loci.formats.tiff.TiffParser.getSamples(TiffParser.java:785) ~[formats-bsd.jar:5.1.4]
at loci.formats.in.OMETiffReader.openBytes(OMETiffReader.java:314) ~[formats-bsd.jar:5.1.4]
at loci.formats.ImageReader.openBytes(ImageReader.java:453) ~[formats-api.jar:5.1.4]
at loci.formats.ChannelFiller.openBytes(ChannelFiller.java:156) ~[formats-bsd.jar:5.1.4]
at loci.formats.ChannelSeparator.openBytes(ChannelSeparator.java:225) ~[formats-bsd.jar:5.1.4]
at loci.formats.ReaderWrapper.openBytes(ReaderWrapper.java:349) ~[formats-api.jar:5.1.4]
at loci.formats.ReaderWrapper.openBytes(ReaderWrapper.java:349) ~[formats-api.jar:5.1.4]
at loci.formats.MinMaxCalculator.openBytes(MinMaxCalculator.java:269) ~[formats-bsd.jar:5.1.4]
at ome.io.bioformats.BfPixelsWrapper.getTile(BfPixelsWrapper.java:345) ~[romio.jar:na]
at ome.io.bioformats.BfPixelBuffer.getTile(BfPixelBuffer.java:475) ~[romio.jar:na]
at ome.io.nio.PixelsService$1.run(PixelsService.java:418) ~[romio.jar:na]
at ome.io.nio.Utils.forEachTile(Utils.java:88) ~[romio.jar:na]
at ome.io.nio.Utils.forEachTile(Utils.java:39) ~[romio.jar:na]
at ome.io.nio.PixelsService.performWrite(PixelsService.java:402) ~[romio.jar:na]
at ome.io.nio.PixelsService.makePyramid(PixelsService.java:306) ~[romio.jar:na]
at ome.services.pixeldata.PixelDataHandler.process(PixelDataHandler.java:146) [server.jar:na]
at ome.services.pixeldata.PixelDataHandler.handleEventLog(PixelDataHandler.java:113) [server.jar:na]
at ome.services.pixeldata.PixelDataThread$HandleEventLog.doWork(PixelDataThread.java:246) [server.jar:na]
at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_79]
at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_79]
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at ome.services.util.Executor$Impl$Interceptor.invoke(Executor.java:566) [server.jar:na]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at ome.security.basic.NullEventHandler.invoke(NullEventHandler.java:39) [server.jar:na]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at org.springframework.orm.hibernate3.HibernateInterceptor.invoke(HibernateInterceptor.java:111) [org.springframework.orm.jar:3.0.1.RELEASE-A]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:108) [org.springframework.transaction.jar:3.0.1.RELEASE-A]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at ome.tools.hibernate.ProxyCleanupFilter$Interceptor.invoke(ProxyCleanupFilter.java:249) [server.jar:na]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at ome.services.util.ServiceHandler.invoke(ServiceHandler.java:121) [server.jar:na]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) [org.springframework.aop.jar:3.0.1.RELEASE-A]
at com.sun.proxy.$Proxy71.doWork(Unknown Source) [na:na]
at ome.services.util.Executor$Impl.execute(Executor.java:447) [server.jar:na]
at ome.services.util.Executor$Impl.execute(Executor.java:391) [server.jar:na]
at ome.services.pixeldata.PixelDataThread.go(PixelDataThread.java:255) [server.jar:na]
at ome.services.pixeldata.PixelDataThread.access$000(PixelDataThread.java:52) [server.jar:na]
at ome.services.pixeldata.PixelDataThread$1.call(PixelDataThread.java:203) [server.jar:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_79]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_79]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
2015-10-03 12:22:29,000 INFO [ ome.io.nio.FilePathResolver] (2-thread-5) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/dsudar_2/2015-10/03/12-11-02.553/Stitched_NewOUtput_s1.ome.tiff
2015-10-03 12:22:29,000 INFO [ ome.io.nio.FilePathResolver] (2-thread-3) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/dsudar_2/2015-10/03/12-11-02.553/Stitched_NewOUtput_s1.ome.tiff
2015-10-03 12:25:16,036 INFO [ ome.io.nio.FilePathResolver] (2-thread-5) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/dsudar_2/2015-10/03/12-11-02.553/Stitched_NewOUtput_s1.ome.tiff


This file was 20+ GB but I'll try to create a file that gives the same error that is a little smaller. And I'll upload that to the QA system.

Thanks,
- Damir
dsudar
 
Posts: 235
Joined: Mon May 14, 2012 8:43 pm
Location: Berkeley, CA, USA

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby sbesson » Mon Oct 05, 2015 3:34 pm

Hi Damir,

thanks for submitting a sample OME-TIFF file. Using it, we can definitely reproduce the stack trace you observed in PixelData.log on our CI servers at import time. We have limited bandwidth today due to some testing but we will investigate this issue and get back to you as soon as possible.


Best,
Sebastien
User avatar
sbesson
Team Member
 
Posts: 421
Joined: Tue Feb 28, 2012 7:20 pm

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby dsudar » Mon Oct 05, 2015 4:45 pm

Hi Sebastien,

Thanks for looking into this. Since I hadn't received a confirmation of yesterday's upload, I uploaded the same file again (QA record: 16828). Sorry for the duplication.

This file gave fewer errors (and no clear java exceptions) in the PixelData.log but also gave an error:
2015-10-04 12:36:28,346 INFO [ loci.formats.in.BaseTiffReader] (2-thread-4) Populating OME metadata
2015-10-04 12:36:29,335 ERROR [ ome.services.pixeldata.PixelDataHandler] (2-thread-4) Failed to handle pixels 312991
java.lang.NullPointerException: null
2015-10-04 12:36:44,029 INFO [ ome.io.nio.FilePathResolver] (2-thread-2) Metadata only file, resulting path: /data/OMERO.data/Managed
Repository/dsudar_2/2015-10/04/12-35-35.479/A1_Stitch_BIGTIFF_s1.ome.tiff


With Fiji (w/ Bioformats 5.1.4) the file loads fine so it appears unrelated to BioFormats itself.

No hurry and thanks.
- Damir
dsudar
 
Posts: 235
Joined: Mon May 14, 2012 8:43 pm
Location: Berkeley, CA, USA

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby sbesson » Tue Oct 06, 2015 12:33 pm

Hi Damir,

investigating a bit further, it is a problem at the Bio-Formats level which I can reproduce with the following MATLAB snippet:

Code: Select all
% Create a Bio-Formats reader with a memoizer
r = loci.formats.Memoizer(bfGetReader(),0);
r.setId('/path/to/A1_Stitch_BIGTIFF_s1.ome.tiff');

% Read a tile twice - passes
I=bfGetPlane(r, 1, 1700, 7000, 100, 100);
I=bfGetPlane(r, 1, 1700, 7000, 100, 100);

% Close the reader
r.close();

% Reload the reader from the memo file
r.setId('/path/to/A1_Stitch_BIGTIFF_s1.ome.tiff');

% Read a tile twice - the second call throws the NullPointerException
I=bfGetPlane(r, 1, 1700, 7000, 100, 100);
I=bfGetPlane(r, 1, 1700, 7000, 100, 100);


The fact you do not see the error in ImageJ is expected since the Bio-Formats plugin is not using the Memoizer wrapper to cache the reader as opposed to OMERO. I will capture the issue in a ticket or card and assign it to an upcoming milestone of Bio-Formats.

Best,
Sebastien
User avatar
sbesson
Team Member
 
Posts: 421
Joined: Tue Feb 28, 2012 7:20 pm

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby sbesson » Tue Oct 06, 2015 2:58 pm

Hi Damir,

as a follow up, the reference card for this issue is https://trello.com/c/kjQdHktu/38-ome-ti ... ion-issues.

Best,
Sebastien
User avatar
sbesson
Team Member
 
Posts: 421
Joined: Tue Feb 28, 2012 7:20 pm

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby dsudar » Thu Jan 21, 2016 10:01 pm

Hi Sebastien,

I was wondering if there is any progress yet on this issue. I just tried another one of these OME-TIFF files exported by Zeiss's ZEN (a 4-channel fluorescence image of 24123 x 16771 pixels) on a OMERO 5.2.1 server and got the same error in Pixeldata.log

2016-01-21 13:50:32,446 INFO [ ome.io.nio.FilePathResolver] (2-thread-4) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/13-48-15.828/subset_s1.ome.tiff
2016-01-21 13:50:32,451 INFO [ ome.io.nio.FilePathResolver] (2-thread-5) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/13-48-15.828/subset_s1.ome.tiff
2016-01-21 13:50:32,647 WARN [ ome.services.pixeldata.PixelDataHandler] (2-thread-5) Pixels:82889 -- Already locked! /data/OMERO/Pixels/Dir-082/.82889_pyramid.pyr_lock
2016-01-21 13:50:34,165 INFO [ ome.io.nio.PixelsService] (2-thread-4) Creating BfPixelBuffer: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/13-48-15.828/subset_s1.ome.tiff Series: 0
2016-01-21 13:50:34,166 INFO [ ome.io.nio.PixelsService] (2-thread-4) Destination pyramid tile size: java.awt.Dimension[width=256,height=256]
2016-01-21 13:50:34,167 INFO [ ome.io.nio.PixelsService] (2-thread-4) Pyramid creation for Pixels:82889 1/25080 (0%).
2016-01-21 13:50:35,359 INFO [ loci.formats.in.MinimalTiffReader] (2-thread-4) Reading IFDs
2016-01-21 13:50:35,360 INFO [ loci.formats.in.MinimalTiffReader] (2-thread-4) Populating metadata
2016-01-21 13:50:35,526 INFO [ loci.formats.in.JPEG2000MetadataParser] (2-thread-4) Unknown JPEG 2000 box 0x2900 at 100770
2016-01-21 13:50:35,527 INFO [ loci.formats.in.JPEG2000MetadataParser] (2-thread-4) File is a raw codestream not a JP2.
2016-01-21 13:50:35,535 INFO [ loci.formats.in.TiffReader] (2-thread-4) Checking comment style
2016-01-21 13:50:35,535 INFO [ loci.formats.in.BaseTiffReader] (2-thread-4) Populating OME metadata
2016-01-21 13:50:41,054 ERROR [ ome.services.pixeldata.PixelDataHandler] (2-thread-4) Failed to handle pixels 82889
java.lang.NullPointerException: null
at loci.common.RandomAccessInputStream.getFilePointer(RandomAccessInputStream.java:198) ~[formats-common.jar:5.1.7]
at loci.formats.tiff.OnDemandLongArray.toArray(OnDemandLongArray.java:79) ~[formats-bsd.jar:5.1.7]
at loci.formats.tiff.TiffParser.getSamples(TiffParser.java:858) ~[formats-bsd.jar:5.1.7]
at loci.formats.tiff.TiffParser.getSamples(TiffParser.java:785) ~[formats-bsd.jar:5.1.7]
at loci.formats.in.OMETiffReader.openBytes(OMETiffReader.java:330) ~[formats-bsd.jar:5.1.7]
at loci.formats.ImageReader.openBytes(ImageReader.java:453) ~[formats-api.jar:5.1.7]
at loci.formats.ChannelFiller.openBytes(ChannelFiller.java:156) ~[formats-bsd.jar:5.1.7]
at loci.formats.ChannelSeparator.openBytes(ChannelSeparator.java:225) ~[formats-bsd.jar:5.1.7]
at loci.formats.ReaderWrapper.openBytes(ReaderWrapper.java:349) ~[formats-api.jar:5.1.7]
at loci.formats.ReaderWrapper.openBytes(ReaderWrapper.java:349) ~[formats-api.jar:5.1.7]
at loci.formats.MinMaxCalculator.openBytes(MinMaxCalculator.java:269) ~[formats-bsd.jar:5.1.7]
at ome.io.bioformats.BfPixelsWrapper.getTile(BfPixelsWrapper.java:343) ~[romio.jar:na]
<SNIP>
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_91]
2016-01-21 13:50:41,067 WARN [ ome.services.util.ServiceHandler] (2-thread-4) Method interface ome.services.util.Executor$Work.doWork invocation took 8742
2016-01-21 13:52:00,053 INFO [ ome.io.nio.FilePathResolver] (2-thread-2) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/13-48-15.828/subset_s1.ome.tiff
2016-01-21 13:52:00,075 INFO [ ome.io.nio.FilePathResolver] (2-thread-5) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/13-48-15.828/subset_s1.ome.tiff


For a bit of background info: this data comes from a Zeiss Axioscan slide scanner. Its default output format .CZI is not supported properly by BioFormats so we would like to export the files as OME-TIFF (as ZEN does that) and import those into OMERO.

Thanks,
- Damir
dsudar
 
Posts: 235
Joined: Mon May 14, 2012 8:43 pm
Location: Berkeley, CA, USA

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby jmoore » Fri Jan 22, 2016 10:58 am

Hi Damir,

The card referenced above was fixed by PR:2031 which was part of Bio-Formats 5.1.6. If you're still seeing the problem, then there must be a secondary issue.

Thanks for the heads up,
~Josh.
User avatar
jmoore
Site Admin
 
Posts: 1591
Joined: Fri May 22, 2009 1:29 pm
Location: Germany

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby dsudar » Fri Jan 22, 2016 11:02 pm

Hi Josh,

I also tried the same file that I had uploaded to the QA system before. Hopefully you can still find it in there. It's called: A1_Stitch_BIGTIFF_s1.ome.tiff
When importing into OMERO 5.2.1 I get in the PixelData-0.log:
2016-01-21 14:38:00,040 INFO [ ome.io.nio.FilePathResolver] (2-thread-2) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/14-37-15.093/A1_Stitch_BIGTIFF_s1.ome.tiff
2016-01-21 14:38:00,232 INFO [ ome.io.nio.PixelsService] (2-thread-2) Creating BfPixelBuffer: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/14-37-15.093/A1_Stitch_BIGTIFF_s1.ome.tiff Series: 0
2016-01-21 14:38:00,232 INFO [ ome.io.nio.PixelsService] (2-thread-2) Destination pyramid tile size: java.awt.Dimension[width=256,height=256]
2016-01-21 14:38:00,232 INFO [ ome.io.nio.PixelsService] (2-thread-2) Pyramid creation for Pixels:82890 1/9600 (0%).
2016-01-21 14:38:00,575 INFO [ loci.formats.in.MinimalTiffReader] (2-thread-2) Reading IFDs
2016-01-21 14:38:00,576 INFO [ loci.formats.in.MinimalTiffReader] (2-thread-2) Populating metadata
2016-01-21 14:38:00,612 INFO [ loci.formats.in.JPEG2000MetadataParser] (2-thread-2) Unknown JPEG 2000 box 0x2900 at 38850
2016-01-21 14:38:00,613 INFO [ loci.formats.in.JPEG2000MetadataParser] (2-thread-2) File is a raw codestream not a JP2.
2016-01-21 14:38:00,614 INFO [ loci.formats.in.TiffReader] (2-thread-2) Checking comment style
2016-01-21 14:38:00,614 INFO [ loci.formats.in.BaseTiffReader] (2-thread-2) Populating OME metadata
2016-01-21 14:38:01,639 ERROR [ ome.services.pixeldata.PixelDataHandler] (2-thread-2) Failed to handle pixels 82890
java.lang.NullPointerException: null
2016-01-21 14:38:04,030 INFO [ ome.io.nio.FilePathResolver] (2-thread-5) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/14-37-15.093/A1_Stitch_BIGTIFF_s1.ome.tiff
2016-01-21 14:38:04,030 INFO [ ome.io.nio.FilePathResolver] (2-thread-3) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/13-48-15.828/subset_s1.ome.tiff
2016-01-21 14:38:08,025 INFO [ ome.io.nio.FilePathResolver] (2-thread-1) Metadata only file, resulting path: /data/OMERO/ManagedRepository/dsudar_2/2016-01/21/13-48-15.828/subset_s1.ome.tiff


Interestingly that last part about the Metadata only file, resulting path .... repeats again hours later and again and again.

Thanks,
- Damir
dsudar
 
Posts: 235
Joined: Mon May 14, 2012 8:43 pm
Location: Berkeley, CA, USA

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby sbesson » Mon Jan 25, 2016 2:33 pm

Hi Damir,

thanks for following up on this thread, the stack trace you are seeing in PixelData-0.log looks related to the issue that was reported and addressed in PR 2196. We have rebased this fix in PR 2209 for inclusion in Bio-Formats 5.1.8 and this should be bundled as part of the upcoming OMERO 5.2.2.


Best,
Sebastien
User avatar
sbesson
Team Member
 
Posts: 421
Joined: Tue Feb 28, 2012 7:20 pm

Re: Large OME-Tiffs exported by Zeiss ZEN 2

Postby dsudar » Wed Mar 02, 2016 8:36 pm

Hi Sebastien,

I just installed 5.2.2 and indeed, for at least some of those offending files, the import and pyramid creation appears to proceed fine (albeit slowly).

One question: from earlier attempts (before the 5.2.2 upgrade) and from other folks trying to import those types of files, there are a lot of them in the database waiting for "pyramid levels to be created, please check back later". I noticed that PixelData.log knows about them and reports the following on a regular basis:
2016-02-25 11:34:48,117 INFO [ ome.io.nio.FilePathResolver] (2-thread-1) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/linkja_657/2016-02/24/12-11-41.091/4145 Y69 LOW Fused_s2.ome.tiff
2016-02-25 11:34:48,194 INFO [ ome.io.nio.FilePathResolver] (2-thread-3) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/linkja_657/2016-02/24/12-10-33.679/4145 Y69 HI Fused_s1.ome.tiff
2016-02-25 11:34:52,019 INFO [ ome.io.nio.FilePathResolver] (2-thread-2) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/linkja_657/2016-02/24/12-10-54.743/4145 Y69 HI Fused_s2.ome.tiff
2016-02-25 11:34:52,024 INFO [ ome.io.nio.FilePathResolver] (2-thread-1) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/linkja_657/2016-02/24/12-11-08.821/4145 Y69 HI Fused_s3.ome.tiff
2016-02-25 11:34:56,021 INFO [ ome.io.nio.FilePathResolver] (2-thread-5) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/linkja_657/2016-02/24/12-11-26.680/4145 Y69 LOW Fused_s1.ome.tiff
2016-02-25 11:34:56,021 INFO [ ome.io.nio.FilePathResolver] (2-thread-2) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/linkja_657/2016-02/24/12-11-56.816/4145 Y69 LOW Fused_s3.ome.tiff
2016-02-25 11:35:00,092 INFO [ ome.io.nio.FilePathResolver] (2-thread-4) Metadata only file, resulting path: /data/OMERO.data/ManagedRepository/linkja_657/2016-02/24/12-11-56.816/4145 Y69 LOW Fused_s3.ome.tiff


Is there a way to tell OMERO 5.2.2 to now go back to those files and try again?

Thanks,
- Damir
dsudar
 
Posts: 235
Joined: Mon May 14, 2012 8:43 pm
Location: Berkeley, CA, USA

Next

Return to User Discussion

Who is online

Users browsing this forum: No registered users and 1 guest