Olympus .vsi download bug

[dominikl]

See Olympus .vsi download bug using OMERO.insight.

When Insight downloads a vsi image it puts the files into a directory, this should not happen. Example from the dataset mentioned in the forum post:
Download of vsi image (image id 149046 on demo):

Brain_DAPI_GFAP-488_IBA3-Cy3_MBP-647_coronal10x_coronal-slideA_03.vsi
_Brain_DAPI_GFAP-488_IBA3-Cy3_MBP-647_coronal10x_coronal-slideA_03_/stack1/frame_t_0.ets

ends up in:

frame_t_0.ets/Brain_DAPI_GFAP-488_IBA3-Cy3_MBP-647_coronal10x_coronal-slideA_03.vsi
frame_t_0.ets/_Brain_DAPI_GFAP-488_IBA3-Cy3_MBP-647_coronal10x_coronal-slideA_03_/stack1/frame_t_0.ets

This is not the case with omero downloader. I assume because downloader tries to replicate the managed repository structure locally as close as possible.
I wonder how OMERO.web handles that case?

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/olympus-vsi-download-bug-using-omero-insight/47413/4

[dominikl]

After some debugging I think I found the reason: For a multifile image Insight creates a directory for the files to be put in, using the image name as directory name. In some cases it picks up the vsi file first (correct) and in some cases it picks up the frame_t_0.ets file first (wrong). This is happening here:

omero-insight/src/main/java/org/openmicroscopy/shoola/env/data/OMEROGateway.java

Line 3162 in dfd2971

String imgFilename = set.getFilesetEntry(0).getOriginalFile()

But I can't fix this in Insight, because it's an issue of the Fileset class: getFilesetEntry(0) or the equivalent getPrimaryFilesetEntry() return in these cases the ets file instead of the vsi.

[CellKai]

Hi @dominikl thank your for looking into this issue (I wrote the post on image.sc).
Concerning this, we (@ehrenfeu @lguerard) think a possible solution from the user point of view would indeed be to NOT create the directory to put the files in in the first place . Actually, we think this would be even easier for the user to handle in the end. Do you think this could be a way to go for this issue?

[dominikl]

👍 I think that makes sense. Just openend a PR for that.

[CellKai]

super, that's awesome :) thank you very much!

[dominikl]

Further discussion see on now closed PR #217 .

[CellKai]

Hi @dominikl @jburel @pwalczysko , I'd like to bump this ticket again :)

As @pwalczysko summarized in PR #217, we are looking for a solution where OMERO.insight does not create any new folders that are not part of a given proprietary file format, but also does not skip the folders which are crucial for the proprietary file formats like vsi to function properly.

Thank you for your time and help!

[dominikl]

I'll have another look at this issue. Maybe I can figure out how Omero Web is doing it and completely overhaul the Image download code in Insight. Omero Web does exactly what you'd expect, is that correct @CellKai ?

[CellKai]

Hi @dominikl, thank you for picking up this issue again!
Omero Web is zipping the vsi files and companion folders and limits the total size to 1 GB, which I understand for the web, but should not be done in OMERO.insight I think.
In my tests, the file organization inside the zip from OMERO web was indeed correct though, so this might be a good reference.

[jburel]

@dominikl it might good to see the layout when downloading lionheart MRI DICOM from Web and compare if it is correct.
Your initial work done in #217 was fixing the problem described in this issue but it was breaking the lionheart MRI DICOM layout

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/download-vsi-files-from-omero-fails/83314/2