upgrade Omero5.02 to 5.0.4 resulted in silhouettes

[kennethgillen]

Just to clarify, I've imported the file you submitted into a 5.0.2 server, with a 5.0.2 Insight client, and it appears, to the eye at least, to be the same image as the 5.0.4 import. Investigation is still ongoing.

Was it OMERO.insight that was used to import them initially when they looked okay?

[jwarren]

OK thanks Kenny. More simply - I think if osirix can open it with sensible defaults then omero should be able to as well irrespective of version .02. vs.04. I've just found out that we now have over 46000 images and a great number will be dicom (as apposed to 1500 images a couple of days ago). So some of these images maybe new in my omero - so you may have to treat these as never having worked - but should work.

The uploading is going via a python script which loads jpgs and tiff files fine.

Sorry for any confusing info from my end.

[kennethgillen]

OK thanks Kenny. More simply - I think if osirix can open it with sensible defaults then omero should be able to as well irrespective of version .02. vs.04. I've just found out that we now have over 46000 images and a great number will be dicom (as apposed to 1500 images a couple of days ago). So some of these images maybe new in my omero - so you may have to treat these as never having worked - but should work.

The uploading is going via a python script which loads jpgs and tiff files fine.

Sorry for any confusing info from my end.

No worries. Thanks for working with us to try and diagnose the problem. Always a lot of back and forth to work out what's going on, so appreciate your continued communication and perseverance.

Best,

Kenny

[mlinkert]

Thanks again for clarifying - we now know the source of the problem. There is a ticket on our issue tracking system:

https://trac.openmicroscopy.org.uk/ome/ticket/12568

You will be automatically notified via email of any updates to that ticket; if you prefer not to be notified, please let us know.

[jwarren]

Thanks again Melissa and Kenny for your help and finding the issue.

Yes I def want to be notified of any progress on this bug

I will turn off loading of our dicom images as all seem to have this issue currently. I don't want to seem to pushy but is there an ETA for a patch for this? just for my info as we haven't pushed this into production yet - but will wish to in the next few weeks - Ideally within the next 4. An ETA will enable me to manage expectations of our stakeholders. If you need anymore sample images or any other way I can help just let me know.

Thanks

Jonathan.

[jwarren]

Hi

I've got the code from git for bioformats and if you give me some more pointers maybe I can fix this issue myself? I can run the ImageConverter main in eclipse and debug things from there. I'm just not sure where the most appropriate place to fix this bug is as searching on PixelType and int16 etc turns up in many places. We have 48,000 images that we can't use currently so any help I can be?

Cheers

Jonathan.

[jwarren]

We also have some xrays from other data centers which are not completely black and white like the previous example but have similar issues - so I'm not sure that one fix will fix all our dicoms from the different image sources.

bug id: 9552

[mlinkert]

We currently have this fix scheduled to be completed for 5.1.0-m2, which is in approximately 3 weeks.

We have a pretty good idea of what the issue is and how to fix it, but if you're interested in submitting a patch that would certainly be welcome. The bug is in components/formats-bsd/src/loci/formats/in/DicomReader.java; as noted in the ticket, the sign of the pixel values is set incorrectly, so an additional DICOM tag needs to be read to determine the correct sign value (denoted by the "signed" variable).

The file from QA 9552 does have the same signedness issue as the file from QA 9532 - it's just that the background values are much smaller in the 9552 file, so the image looks more correct as it is.

[jwarren]

Hi Melissa

I tried forcing the Signed to be true in the DicomReader and this then turns the PixelType to be 2 =FormatTools.int16. But this didn't fix the problem when converting from these dicoms to a tiff file they are still the same. So I guess I may leave this to you.. as i've not been able to fix it within a short amount of time.

3 Weeks is probably ok for us.

Output from running the Converter below:

Output file /Users/jwarren/Desktop/46310.tiff exists.
Do you want to overwrite it? ([y]/n)
y
/Users/jwarren/Desktop/46310.dcm
DicomReader initializing /Users/jwarren/Desktop/46310.dcm
Verifying DICOM format
Reading tags
signed=true
signed again=true
pixelTyppe formatReader=2
Calculating image offsets
Building file list
Populating metadata
pixelTyppe formatReader=2
pixelTyppe formatReader=2
[DICOM] -> /Users/jwarren/Desktop/46310.tiff [Tagged Image File Format]
pixelTyppe formatReader=2
pixelTyppe formatReader=2
pixelTyppe formatReader=2
pixelTyppe formatReader=2
get8BitLookupTable
pixelTyppe formatReader=2
pixelTyppe formatReader=2
get16BitLookupTable
pixelTyppe formatReader=2
pixel type=2
pixelTyppe formatReader=2
Returning null
Converted 1/1 planes (100%)
[done]
1.344s elapsed (79.0+574.0ms per plane, 688ms overhead)

[jwarren]

Hi Melissa

I see you have fixed the bug in the dev branch. Can you tell me how I can use the new version? I've tried building the develop branch, also the dev_5_0 and swapping DicomReader file with the contents of the one in the bug fix. However I find the conversion to TIFF using the ImageConverter.java still has a completely black and white image as before?

Do I need to wait for the next version of the server or can I apply the patch in some way to my server by updating the bsd jar from you?

Many thanks

Jonathan.