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: bfconvert generates bad DICOMs from SVS files #4161

Open
jcupitt opened this issue Mar 8, 2024 · 3 comments
Open

bug: bfconvert generates bad DICOMs from SVS files #4161

jcupitt opened this issue Mar 8, 2024 · 3 comments
Milestone

Comments

@jcupitt
Copy link

jcupitt commented Mar 8, 2024

Hello everyone, thank you for this nice thing.

While working on openslide, I've come across a bfconvert bug when generating DICOM files.

DICOM has a photometricinterpretation tag to indicate either RGB or YCbCr colorspace in tiles. This (according to the DICOM spec) is the place where the tile colourspace is kept, and NOT in the JPEG tiles themselves. On decode, you need to open each tile, and force the tile colorspace from the DICOM header.

If you use -precompressed, conversion will copy over the JPEG tiles untouched, so if the DICOM header and the tile colorspace were correct beforehand, they will still match in the converted image.

If you convert without the precompressed flag, bfconvert will reencode the JPEGs and may well change the photometric interpretation. For example, SVS is saved as RGB (no chroma subsample), but bfconvert will save as YCbCr (chroma subsample). Now the DICOM photometric interpretation will be RGB, but the tiles will be YCbCr, so users will see crazy colors.

tldr: when saving DICOM, if tiles are being recompressed, bfconvert needs to update the DICOM photometric interpretation tag.

Referring openslide issue: openslide/openslide#558

Referring libdicom issue: ImagingDataCommons/libdicom#80

@jcupitt jcupitt changed the title bfconvert should change DICOM photometricinterpretation tag when processing JPEG tiles bug: bfconvert generates bad DICOMs from SVS files Mar 8, 2024
@bgilbert
Copy link

bgilbert commented Mar 9, 2024

Also, even with -precompressed, bfconvert re-encodes the label and overview images to YCbCr but leaves their PhotometricInterpretation values as RGB.

@melissalinkert
Copy link
Member

Thanks for reporting this, @jcupitt / @bgilbert. Just to make sure I understand before implementing a fix, is the following what you would expect to be sufficient:

  • only the PhotometricInterpretation (i.e 0x0028,0004) needs to be changed
  • if there are 3 samples per pixel, -precompressed was used, and no re-encoding was performed, then PhotometricInterpretation should be RGB
  • if there are 3 samples per pixel, -compression JPEG was used, and either -precompressed was used but re-encoding needed to happen anyway or -precompressed was not used, then PhotometricInterpretation should be YBR_FULL_422
  • if there are 3 samples per pixel, -compression was omitted or set to something other than JPEG, then PhotometricInterpretation should be RGB
  • if there is 1 sample per pixel, PhotometricInterpretation should remain MONOCHROME2

/cc @dclunie, @fedorov

@jcupitt
Copy link
Author

jcupitt commented Mar 14, 2024

Hi @melissalinkert, thanks for working on this.

I think you can assume the input file is correct, so if you just copy over the JPEG images, you don't need to do anything.

If you do a decompress or compress, you need to look at and perhaps set the DICOM photometricinterpretation tag.

  1. On decompress you need to set the libjpeg input colorspace from the DICOM metadata (don't rely on libjpeg to get this right, it'll miss with eg. SVS) during decompressor setup.
  2. Conversely, on compress, you need to set the DICOM tag to the colourspace you compressed the JPEGs to.
  3. And as Benjamin says, this also applies to the thumbnail / macro / label etc.

@melissalinkert melissalinkert added this to the 8.0.0 milestone Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants