bioformats tools generates DICOM resulting in "data element not assigned a value - element tag 00280030 has not been assigned a value"

[arngaillard]

Hi,

I have seen already existing issues on openslide / libdicom and bioformats (openslide/openslide#558 / #80) , but I am not sure how related to this specific issue they are. Plus, the versions of openslide / libdicom I used seem to include those fixes.

What I used:

bfconvert:

./bfconvert -version
Version: 8.3.0
Build date: 5 August 2025
VCS revision: 91a71077ee170e18594f8a367f4752381f9343a3

openslide : https://github.com/jcupitt/openslide/tree/add-dicom-concatenations
libdicom: 1.2.0

I used a WSI from there https://openslide.cs.cmu.edu/download/openslide-testdata/Hamamatsu/

$ ./bfconvert  -noflat -precompressed -series 0 CMU-1.ndpi converted.0.dcm
CMU-1.ndpi
NDPIReader initializing CMU-1.ndpi
Reading IFDs
Populating metadata
Populating OME metadata
Implicitly using compression = JPEG
[Hamamatsu NDPI] -> converted.0.dcm [DICOM]
More than 4GB of pixel data, compression will need to be used
Tile size = 2048 x 512
	Converted 1/1 planes (100%)
Tile size = 512 x 512
	Converted 1/1 planes (100%)
Tile size = 128 x 128
	Converted 1/1 planes (100%)
Tile size = 800 x 596
	Converted 1/1 planes (100%)
[done]
3.288s elapsed (2.0+703.0ms per plane, 366ms overhead)
$ ls *dcm
converted.0_0_0.dcm  converted.0_0_1.dcm  converted.0_0_2.dcm  converted.0_0_3.dcm

If I try to read the DICOM files with my installed openslide, I get libdicom Invalid parameter: data element not assigned a value - element tag 00280030 has not been assigned a value, whilst the .ndpi opens just fine.

Note that the output DICOM file opens "fine" in orthanc (https://www.orthanc-server.com/). "Fine" as in, I can navigate through the files and I can see the pixel data.

Please tell me if you need me to specify more information regarding this issue (or if this issue rather lays on bioformats side)

Best regards and thank you very much,
Arnaud

[jcupitt]

Hi @arngaillard, thanks for reporting this, I'll take a look.

[jcupitt]

I see the same error here with the current version of all packages:

• bftools 8.3.0
• libdicom master -- 1.2 plus a few commits that should not affect this
• openslide master -- 4.0.0 plus a few commits

It looks like bfconvert is writing the PixelSpacing as:

        (0028,0030) DS [4.564125969876768E-4\4.550625711035267E-4] #  42, 2 PixelSpacing

But libdicom is seeing:

    (0028,0030) PixelSpacing | DS | 42   ]

ie. it's failing to parse the floating point 4.564125969876768E-4 value correctly. I'll keep digging.

[jcupitt]

Ah, found it, the DICOM spec says that ValueType DS is 16 bytes maximum, but bfconvert is writing 20 bytes in this case, so the file is failing libdicom validation.

I'm not exactly sure what to do. I suppose the possibilities are:

1. libdicom is currently not reporting validation failure, which seems bad. We should at least make it issue a warning and document that values which fail validation will not be set.

2. libdicom could stop enforcing capacity validation. However, this would mean passing strings to downstream programs which might be longer than expected, and that could cause them to crash. openslide handles strings that are too large correctly, but other programs may not.

3. I think bfconvert should have written this string as 4.56412596988E-4 (ie. 16 chars only), this is probably a bug.

Given that there are now quite a few DICOMs which fail capacity tests, I suppose libdicom has to allow them.

@dclunie, could I ping you on this? How strict would you expect readers be on maximum length?

[fedorov]

@arngaillard @jcupitt it is very unfortunate we missed this when DICOM support was being implemented in bioformats, or perhaps it is a new regression... Could one of you please open an issue in https://github.com/ome/bioformats to report this?

[arngaillard]

Hi @fedorov , I'll open the issue on bioformats' side, referencing this issue. I am not sure if this issue (on libdicom) needs to be kept alive. I'll let you guys decide

[dclunie]

Hi John Thanks for investigating. Postel's principle: read anything, write perfect [1]. Arnaud, can you open an issue with BioFormats, which seems to be the culprit here? What does dciodvfy [2] say about the bfconvert created files? We definitely tested BioFormats bfconvert output with dciodvfy for this sort of thing when DICOM writing support was being added, but I am not sure that it was tested with NDPI input files (as distinct from SVS) so this might be related to something specific about the input file (format). I just tried CMU-1.svs with bfconvert from 8.3.0 and the DICOM output was fine. With CMU-1.ndpi I get the error as described in the issue and dciodvfy says: Error - </SharedFunctionalGroupsSequence(5200,9229)[1]/PixelMeasuresSequence(0028,9110)[1]/PixelSpacing(0028,0030)[1]> - Value invalid for this VR [DS] = <4.564125969876768E-4> - Length invalid for this VR = <20> - expected <= 16 Error - </SharedFunctionalGroupsSequence(5200,9229)[1]/PixelMeasuresSequence(0028,9110)[1]/PixelSpacing(0028,0030)[2]> - Value invalid for this VR [DS] = <4.550625711035267E-4> - Length invalid for this VR = <20> - expected <= 16 I tried 8.2.0 and got the same error, so this is probably not a regression. David 1. https://en.wikipedia.org/wiki/Robustness_principle 2. https://www.dclunie.com/dicom3tools/dciodvfy.html

…

On 10/21/25 7:31 AM, John Cupitt wrote: *jcupitt* left a comment (ImagingDataCommons/libdicom#105) <#105 (comment)> Ah, found it, the DICOM spec says that ValueType |DS| is 16 bytes maximum, but |bfconvert| is writing 20 bytes in this case, so the file is failing libdicom validation. I'm not exactly sure what to do. I suppose the possibilities are: 1. libdicom is currently not reporting validation failure, which seems bad. We should at least make it issue a warning and document that values which fail validation will not be set. 2. libdicom could stop enforcing capacity validation. However, this would mean passing strings to downstream programs which might be longer than expected, and that could cause them to crash. openslide handles strings that are too large correctly, but other programs may not. 3. I think |bfconvert| should have written this string as |4.56412596988E-4| (ie. 16 chars only), this is probably a bug. Given that there are now quite a few DICOMs which fail capacity tests, I suppose libdicom has to allow them. @dclunie <https://github.com/dclunie>, could I ping you on this? How strict would you expect readers be on maximum length? — Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBLYVIHZHGDLY2SPBOP6ML3YYKPXAVCNFSM6AAAAACJYQ5742VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMRWGEZDENZWG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jcupitt]

@dclunie thank you!

So I propose:

1. Change libdicom to issue a warning, but to pass the long strings downstream.

2. Add a note to the docs to say that maximum length is only advisory and that downstream libraries must be prepared (ie. not crash) for any length value in any field.

3. I'll keep the other libdicom validation tests (ie. not make libdicom completely permissive) since they've not caused problems so far.

Does that sound OK to everyone?

This is just a guess, but could the bfconvert bug be related to printf()-style handling of precision specification? The %.yg format conversion does not include the characters for the e-4 exponent, so it's easy to generate more output that you expect with numbers small enough to push it into scientific notation.

[jcupitt]

Sigh of course when I came to make the PR I discovered (I'd forgotten!) that libdicom is supposed to already have this behaviour, it was just broken. I've credited you for the fix in the CHANGELOG @arngaillard, I hope that's OK.

I now see:

$ vipsheader converted.0_0_0.dcm
converted.0_0_0.dcm: 51200x38144 uchar, 4 bands, srgb, openslideload

ie. everything works by default. I added a -w flag to display warnings and with that I see:

$ dcm-dump -w converted.0_0_0.dcm > log
WARNING  [Tue Oct 21 15:35:04 2025] - Data Element capacity check failed -- Value of Data Element '00280030' exceeds maximum length of Value Representation (16)

And dcm-dump output shows:

    (0028,0030) PixelSpacing | DS | 42 | 2 | [4.564125969876768E-4, 4.550625711035267E-4]

ie. the out of spec value is handled correctly.

[arngaillard]

Yes, all good @jcupitt
Thank you very much for the fast support, I have tested this with my own openslide build and the .dcm open fine.

[jcupitt]

Thanks for testing! I'll merge the PR and close this issue.