- From: Detlef Grittner <detlef.grittner@sohard.de>
- Date: Thu, 11 Jul 2024 18:46:57 +0200
- To: Erich Bremer <erich.bremer@stonybrook.edu>
- Cc: public-semweb-lifesci@w3.org, its@lists.HL7.org
Hi Erich, I have to come back to this issue of "OB or OW". The VR OB is defined as follows in the DICOM standard: "An octet-stream where the encoding of the contents is specified by the negotiated Transfer Syntax. OB is a VR that is insensitive to byte ordering (see Section 7.3). The octet-stream shall be padded with a single trailing NULL byte value (00H) when necessary to achieve even length." And the VR OW is defined as follows: "A stream of 16-bit words where the encoding of the contents is specified by the negotiated Transfer Syntax. OW is a VR that requires byte swapping within each word when changing byte ordering (see Section 7.3)." (https://dicom.nema.org/medical/dicom/current/output/html/part05.html#sect_6.2) We can resolve the problem of the endianess of OW by strictly using little endian and the DICOM standard supports it: "All nonretired Transfer Syntaxes in DICOM require the use of Little Endian Byte Ordering." (https://dicom.nema.org/medical/dicom/current/output/html/part05.html#sect_7.3) But if we use xsd:base64Binary, we still have the problem if a single value from the stream is a byte (8-Bit) for OB or 2 bytes (16-bit) for OW. Would this prevent us from relying solely on xsd datatypes and DICOM standard/ontology for standard attributes? Regards, Detlef -- Detlef Grittner, MSc ISM, M.A. CTO SOHARD Software GmbH Würzburger Str. 197 90766 Fürth Phone: +49 (0) 911 97341-54 Fax: +49 (0) 911 97341-10 E-Mail: detlef.grittner@sohard.de Geschäftsführer: Peter Feltens, Sebastian Schnitzenbaumer Sitz der Gesellschaft: Fürth Registergericht: Amtsgericht Fürth; HRB 11478
Received on Thursday, 11 July 2024 16:47:04 UTC