Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] PDF appear dark (wont properly load) #4118

Closed
niirdan opened this issue May 12, 2024 · 17 comments
Closed

[Bug] PDF appear dark (wont properly load) #4118

niirdan opened this issue May 12, 2024 · 17 comments
Assignees
Labels
Bug Verified Bug reported, reproducible, and verified.

Comments

@niirdan
Copy link

niirdan commented May 12, 2024

Describe the Bug

Screenshot 2024-05-12 101944
Looks like pdf couldn't be loaded properly

Steps to Reproduce

open a study containing pdf document

*note! i am using google healthcare api .

The current behavior

pdf viewer inside ohif wont load

The expected behavior

pdf presented correctly

OS

window 11

Node version

v18.17.1

Browser

latest chrome update

@niirdan niirdan added the Awaiting Reproduction Can we reproduce the reported bug? label May 12, 2024
@sedghi
Copy link
Member

sedghi commented May 14, 2024

What is your server? can you provide the anonymized data?

Could you kindly provide the data if it has been anonymized and you can confirm that there is no patient health information present in any of the headers or embedded within the pixel data?

@niirdan
Copy link
Author

niirdan commented May 15, 2024

@sedghi hey sedghi , i am not sure i understood you 100% , but i attach the dicom's meta data (censoring its patient info )
I am using dcmtk for encapsulating the pdf to dicom and dcmtk dcmodify to add necessary information about the study and patient
Screenshot 2024-05-15 090416

@niirdan
Copy link
Author

niirdan commented May 28, 2024

good morning, popping up due that it is still appears in the latest version

@sedghi
Copy link
Member

sedghi commented May 28, 2024

Could you kindly provide the data if it has been anonymized and you can confirm that there is no patient health information present in any of the headers or embedded within the pixel data?

@niirdan
Copy link
Author

niirdan commented May 28, 2024 via email

@sedghi
Copy link
Member

sedghi commented May 28, 2024

No i meant the actual dicom file, do you have it and can you share it?

@niirdan
Copy link
Author

niirdan commented May 28, 2024

No i meant the actual dicom file, do you have it and can you share it?
Yes Of course !
unfortunately github doesn't allow dcm format so i will upload it here :
https://www.jumbomail.me/l/en/gallery/697273696E617777705662464B3342347436653838673D3D/1181030228
let me know if you have an issue downloading it

@sedghi
Copy link
Member

sedghi commented May 28, 2024

So when i drag and drop it in local it works fine https://viewer-dev.ohif.org/localbasic

CleanShot 2024-05-28 at 18 10 46@2x

What server are you using?
these things are most likely server depndent

Have you seen this
https://docs.ohif.org/configuration/datasources/dicom-web/#singlepart

@sedghi
Copy link
Member

sedghi commented May 28, 2024

I saw you use google healthcare

I uploaded your data to our google healthcare and i see the instance is this

CleanShot 2024-05-28 at 18 18 26@2x

And basically this comes back undefined

 const pdfUrl = dataSource.retrieve.directURL({
      instance,
      tag: 'EncapsulatedDocument',
      defaultType: MIMETypeOfEncapsulatedDocument || 'application/pdf',
      singlepart: 'pdf',
    });

Since there is not EncapsulatedDocument tag that google sends back and as I understand this is a type 1 attribute

https://dicom.innolitics.com/ciods/encapsulated-pdf/encapsulated-document/00420011

Our demo server (static dicom web) provides a bulkDataURI

CleanShot 2024-05-28 at 18 20 58@2x

And Orthanc provides this too

CleanShot 2024-05-28 at 18 22 01@2x

So i believe this is a issue with how google is responding back.

Tagging @jasonklotzer to see if he knows more about DICOM PDF on Google Healthcare

@jasonklotzer
Copy link
Member

BulkDataURI is only available when using the beta API right now. Please try it out and tell me how it goes.

@niirdan
Copy link
Author

niirdan commented May 29, 2024

BulkDataURI is only available when using the beta API right now. Please try it out and tell me how it goes.

Hey jason @jasonklotzer , thanks for responding
do to mean to change this by adding beta1 to the version section of this url ? (v1beta1) ?
'https://healthcare.googleapis.com/v1/projects/XXXX/locations/me-west1/datasets/XX-dataset/dicomStores/XX-datastore/dicomWeb' on ohif's google.js settings ?
as far as i understand it still return undefined due to the fact that the file's meta data haven't changed ..
I will be happy for a tiny explanation what to change in this process ?

@jasonklotzer
Copy link
Member

@sedghi It would be helpful for you to take a look at the API and validate whether that conforms to the OHIF expectations for interacting with a BulkDataURI provider?

@niirdan Yes, the Google Healthcare API DICOM store added support for generating BulkDataURI's and retrieving their referenced payload, and that support is currently in the v1beta1 version of the API. The underlying database has also been populated (backfilled) with any relevant bulk data references, so upon using this version of the API you should see BulkDataURI references.

@sedghi
Copy link
Member

sedghi commented May 29, 2024

Interesting, I'll check

@sedghi sedghi added Bug Verified Bug reported, reproducible, and verified. and removed Awaiting Reproduction Can we reproduce the reported bug? labels May 29, 2024
@sedghi sedghi self-assigned this May 29, 2024
@niirdan
Copy link
Author

niirdan commented May 31, 2024

@sedghi It would be helpful for you to take a look at the API and validate whether that conforms to the OHIF expectations for interacting with a BulkDataURI provider?

@niirdan Yes, the Google Healthcare API DICOM store added support for generating BulkDataURI's and retrieving their referenced payload, and that support is currently in the v1beta1 version of the API. The underlying database has also been populated (backfilled) with any relevant bulk data references, so upon using this version of the API you should see BulkDataURI references.

Thanks for the response , after using v1beta1 looks like it's still returning undefined

@niirdan
Copy link
Author

niirdan commented Jun 3, 2024

@sedghi
Hey Alizera , just to make sure,
does it appear to be a bug in ohif ? or it seems to be a bad behavior of google's api ?
I tried using the beta version of the api as @jasonklotzer told , and it is still seems to appear dark .

@sedghi
Copy link
Member

sedghi commented Jun 6, 2024

I see the bulkDataURI in the v1beta1

CleanShot 2024-06-05 at 22 57 22@2x

and i was able to render it

CleanShot 2024-06-05 at 23 02 17@2x

these are the changes required

CleanShot 2024-06-05 at 23 02 32@2x

Note the bulkDataURI enabled

@niirdan Would you be able to add a section to our documentation with a pull request describing the v1beta1 and bulkDataURI?

Maybe here https://docs.ohif.org/configuration/datasources/dicom-web/#bulkdatauri

@niirdan
Copy link
Author

niirdan commented Jun 6, 2024

I see the bulkDataURI in the v1beta1

CleanShot 2024-06-05 at 22 57 22@2x

and i was able to render it

CleanShot 2024-06-05 at 23 02 17@2x

these are the changes required

CleanShot 2024-06-05 at 23 02 32@2x

Note the bulkDataURI enabled

@niirdan Would you be able to add a section to our documentation with a pull request describing the v1beta1 and bulkDataURI?

Maybe here https://docs.ohif.org/configuration/datasources/dicom-web/#bulkdatauri

Done ! issue has been fixed , you can close this issue, Thanks!

@sedghi sedghi closed this as completed Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Verified Bug reported, reproducible, and verified.
Projects
None yet
Development

No branches or pull requests

3 participants