Windows vs Mac - Chrome browser - Issues recognizing Dicom file

[Rob Adlers]

Hey folks,

I haven't been able to find anything related to this anywhere. 

I have an issue where a Dicom file will fail to be recognized when using a Windows Chrome browser versus a Mac OS X Chrome browser.

Does this sound familiar to anyone? 

The check is as follows:

Important: This transmission is intended only for the use of the addressee and may contain confidential or legally privileged information. If you are not the intended recipient, you are notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify the author immediately and delete all copies of this transmission.

Rob Adlers​  |   809 Wellington St N, Unit 2 ,  Kitchener ON Canada ,  N2H 5L6

Important: This transmission is intended only for the use of the addressee and may contain confidential or legally privileged information. If you are not the intended recipient, you are notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify the author immediately and delete all copies of this transmission.

[Darcy Mason]

Hi, this doesn't seem to be a pydicom-related question since you are inspecting the file directly, but it kind of looks like you might truly have a difference in the files themselves - perhaps you are not uploading the exact same file in both cases?  Maybe one has the preamble and one doesn't, or is coming as corrupted in some way (text rather than binary, e.g.).  

Or perhaps someone else has some ideas...

As an aside re nomenclature, the `preamble` is the first 0x80, the 4 bytes after is called the `DICOM prefix`.

[Rob Adlers]

Yeah, I noticed the nomenclature item as well. I made mention of that. 

I tested against the same files for both Windows and Mac Chrome variants, and had confirmation from other people on my team that they were experiencing the same thing.

We are testing against de-identified files. I looked at the files, and the first 128 characters are NULL characters, followed by DICM as defined by the spec.
To see if it was our files, I also tested against DICOM files external to the company. Samples from the internet. Ran into the same problem.

Before I go further, I'm in a QA role, not a dev. I can read code, etc. but I've never been a developer professionally.

I didn't see anything in the code that would have put up a red flag, and it resembled examples already out in the wild used by other folks.

Part of me wondered if the browsers / OS had use of different character encoders when reading the files.
I didn't see where that could be a problem because of the original DICOM ISO encoding and subsequent incarnations including UTF-8 support NULL characters.
My thought was when the file was being read to check for DICM, depending on the OS/Browser being used, it didn't see the NULL characters in the preamble section, and started at DICM and went forward from there. 
This is a blackbox thought process. I have no idea how the file is read, and what is used to do the reading.
 
I use the example of looking at the file with Textedit in Mac OS X. There you can see the null characters displayed. Notepad, on the other hand, does not show those characters, and starts with DICM.

(I didn't resave these files in those editors btw). I understand reading and displaying are separate functions with the text editors, but they also have their own character encoding support capabilities too. 

I then thought about maybe having something dump out to a log file to say what it saw. That'd probably be the easiest way to figure out if I'm chasing the wrong rabbit.

Based on what I've brought up, does that spark any ideas of where/how I should check next?

I appreciate the quick response Darcy. 

Rob

Rob Adlers​  |   809 Wellington St N, Unit 2 ,  Kitchener ON Canada ,  N2H 5L6

--
You received this message because you are subscribed to a topic in the Google Groups "pydicom" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pydicom/4Pxoz9qIqK0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pydicom+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pydicom/c6e43634-8fbe-4f50-90ad-27456e0265den%40googlegroups.com.

--

Rob Adlers​  |   809 Wellington St N, Unit 2 ,  Kitchener ON Canada ,  N2H 5L6

Important: This transmission is intended only for the use of the addressee and may contain confidential or legally privileged information. If you are not the intended recipient, you are notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify the author immediately and delete all copies of this transmission.

[Steve Gregory]

Hi, The difference must be related to the files, browser or python interpreter / environment. In the python console in the browser, can you print the opening bytes / prefix / preamble? You might get a clue as to what is going wrong? Perhaps dicom_data isn't being opened as a binary file? If it works in one browser then the dicom aspects must be fine. So this might not be the best forum to help you. Good luck! Steve

[Rob Adlers]

Thanks Steve! Agreed. Thanks for the direction point as well. Cheers!

Rob

Rob Adlers​  |   809 Wellington St N, Unit 2 ,  Kitchener ON Canada ,  N2H 5L6

To view this discussion on the web visit https://groups.google.com/d/msgid/pydicom/acd1dd8c-55e8-4ac4-9595-c486365f21a6n%40googlegroups.com.

--

Rob Adlers​  |   809 Wellington St N, Unit 2 ,  Kitchener ON Canada ,  N2H 5L6

Important: This transmission is intended only for the use of the addressee and may contain confidential or legally privileged information. If you are not the intended recipient, you are notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify the author immediately and delete all copies of this transmission.