Best-effort resolution of transfer syntax of DICOM files without file meta group

[Enet4]

The current file reading implementation requires DICOM files to have a file meta group. The only way to open it would be by specifying the expected transfer syntax (introduced in #84). Although to the best of my knowledge the lack of this group is non-standard, it is known that some implementations are capable of resolving this anyway.

• Make file opening more flexible by continuing the process even without finding enough elements for a compliant file meta group table, by assuming a flexible transfer syntax.
  • As a best effort, this is something that can be reiterated as we stumble upon more files to test with, but it should go along something like trying Explicit VR Little Endian first, then Implicit VR Little Endian if the outcome of the former did not make sense.
• Leave a warning (see #49) in the case that the file meta group is missing.

One could start by writing tests for the test files in dicom-test-files without a file meta group (see example in #48), then working your way into making them pass.

[BastienVigneron]

Hello,

On trying to open a file with this transfert syntax : 1.2.840.10008.1.2.1

    let obj = open_file(&in_file)?;

I get : [ERROR] Unsupported transfer syntax 1.2.840.10008.1.2.1 ``

I assume this is linked to this issue ?

[Enet4]

Hello,

On trying to open a file with this transfert syntax : 1.2.840.10008.1.2.1

    let obj = open_file(&in_file)?;

I get : [ERROR] Unsupported transfer syntax 1.2.840.10008.1.2.1 ``

I assume this is linked to this issue ?

That is odd. The unsupported transfer syntax error suggests that the file has a file meta group, but the transfer syntax UID was not recognized. Can you check whether this attribute has any whitespace? A fully compliant value would be even lengthed with a null character \0 for any eventual padding.

[BastienVigneron]

I think you got it, with dcmtk dcmdump : W: DcmUniqueIdentifier: Element TransferSyntaxUID (0002,0010) contains one or more space characters, which were removed.

May be we can trim this particular tag value ?

In meta.rs :

                // Transfer Syntax
                Tag(0x0002, 0x0010) => builder.transfer_syntax(
                    read_str_body(&mut file, &text, &mut group_length_remaining, elem_len)?
                        .trim()?,
                ),

[Enet4]

There are two key components in this particular interaction:

• The standard transfer syntax registry, which is prepared to receive at most a single null character at the end of the UID string, and nothing else. Implementations at this end could be a bit more flexible without compromising the rest of the system.
• The file meta table builder, which retains the values as they were encoded. Changing this so that the values are trimmed may be possible, but the consequences may need to be further evaluated.

I have filed issue #148 to host this new matter. This particular issue is for handling files which do not have a file meta group at all.

[BastienVigneron]

Agree for a :

        if uid.as_bytes().last().cloned() == Some(b'\0') || uid.ends_with(' ') {
            &uid[..uid.len() - 1]
        } else {
            &uid
        }

in lib.rs:68 ?

If yes I can make a PR.

[Enet4]

@bastien-solutions I'd probably do it like this:

uid.trim_end_matches(|c| c.is_whitespace() || c == '\0')

But certainly, a pull request would be much appreciated!

[BastienVigneron]

No problem, can you give me the authorization to create / push on branch ?

[Enet4]

No problem, can you give me the authorization to create / push on branch ?

That will not be necessary if you create a pull request from your own fork. Feel free to follow up on this over at #148 if you get stuck.