[ome-users] ndpi-files: stack processing

Melissa Linkert melissa at glencoesoftware.com
Thu Jun 11 19:22:05 BST 2015


Hi Felix,

> We are currently trying to process stacks that are saved in the ndpi format. In the example I put on the dropbox
> https://dl.dropboxusercontent.com/u/18607042/test5_stack_ROI01.ndpi
> 
> if I open series 1 (Hyperstaack xycz, split channels, virtual stack), it is executed without error. However, it seems, that only one frame is opened, going through the stack all frames seem identical. This obviously is not the case.
> So Melissa pointed out to me that images can not have more than 2GB of pixels. But in this case a frame (of series 1) has ~4.5M pixels. The entire stack is ~2.1GB. Since there is no error in the imagej console, I assume the 2GB limit applies per frame. But I was unable to figure out why the frames in the stack look all the same…
> 
> I could use some information about how the stacks are handled in the current Bio-Formats.

As far as I can tell, the current behavior is correct.  The 2GB per
plane limit definitely shouldn't be an issue for this file.

Each of the Z planes is very similar - with visual inspection alone (especially at < 100%
zoom) they do appear identical.  I see the same thing in both
Hamamatsu's NDP.view2 and Aperio's ImageScope viewers.  Zooming in and
checking the pixel values, though, there are subtle differences in the
pixel values between Z planes.  Series 1, channel 0, pixel (4366,4496)
for example has a value of 19 in Z = 0, but a value of 15 in Z = 4 -
this is a little easier to see visually if the brightness/contrast is
adjusted.

Could you please confirm that you see a difference in the pixel values?
Note that the use of a virtual stack coupled with the size of the images
means that it may take a second or two for the image to update after the
Z slider is clicked.

Regards,
-Melissa

On Wed, Jun 10, 2015 at 11:35:39AM +0000, MEYENHOFER Felix wrote:
> Hi 
> 
> along the lines of the question that I raised in the thread:
> "java.lang.illegalArgumentException: Array size too large” (18. March 2015)
> 
> We are currently trying to process stacks that are saved in the ndpi format. In the example I put on the dropbox
> https://dl.dropboxusercontent.com/u/18607042/test5_stack_ROI01.ndpi
> 
> if I open series 1 (Hyperstaack xycz, split channels, virtual stack), it is executed without error. However, it seems, that only one frame is opened, going through the stack all frames seem identical. This obviously is not the case.
> So Melissa pointed out to me that images can not have more than 2GB of pixels. But in this case a frame (of series 1) has ~4.5M pixels. The entire stack is ~2.1GB. Since there is no error in the imagej console, I assume the 2GB limit applies per frame. But I was unable to figure out why the frames in the stack look all the same…
> 
> I could use some information about how the stacks are handled in the current Bio-Formats.
> 
> -------------------------------------
> Felix Meyenhofer
> University of Fribourg
> Departement of Medicine - Anatomy
> 1, Rte. Albert Gockel
> CH-1700 Fribourg 
> 
> Tel:  +41 26 300 85 45
> Web:  www.unifr.ch/anatomy
>       www.unifr.ch/bioimage
> -------------------------------------
> 
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users



More information about the ome-users mailing list