DICOM Deflated Explicit VR Little Endian (1.2.840.10008.1.2.1.99)

Question

Come sono organizzati i dati in questa sintassi di trasferimento? Una descrizione dello standard:

Questa sintassi di trasferimento si applica alla codifica dell'intero set di dati DICOM. L'intero set di dati viene prima codificato secondo le regole specificate nella sezione A.2. L'intero flusso di byte viene quindi compresso utilizzando l'algoritmo "Deflate" definito in Internet RFC 1951.

Inizialmente ho preso questo per significare che l'intero file DICOM stesso era gzip. Ma se l'intero file è compresso con gzip, inclusa l'intestazione che contiene la sintassi identificativa del trasferimento, in che modo un parser/visualizzatore può leggere la sintassi del trasferimento per sapere che è gzip?

Dal punto di vista di un visualizzatore a cui viene assegnato un file di questo tipo, come può sapere che si tratta di questa sintassi di trasferimento? Cerchi un'intestazione GZIP?

Esistono immagini campione disponibili pubblicamente che utilizzano questa sintassi di trasferimento?

Answer 1

Per gli esempi indicati da @ Springfield762, ciascuno dei file _dfl aveva un flusso di deflate valido da 300 byte, da alcuni byte dispari a otto byte dalla fine. Ognuno di essi è stato decompresso in base alla lunghezza del file corrispondente nell'archivio senza il suffisso _dfl, ma i dati non erano gli stessi. C'è una decodifica aggiuntiva necessaria per ottenere dai dati decompressi all'originale.

image_dfl ha un flusso di svuotamento che inizia con l'offset 334, report_dfl a 348 e wave_dfl a 314. Esse vengono decompressi rispettivamente a 262682, 6178 e 62408 byte.

Gli ultimi otto byte dopo ogni flusso di deflate sono gli stessi di un rimorchio gzip, ovvero il CRC-32 dei dati decompressi (quattro byte) seguiti dalla lunghezza non compressa nell'ordine little endian. Quelli entrambi corrispondono ai dati che risultano dalla decompressione del flusso di deflate.

I byte che precedono i dati di svuotamento sono non un'intestazione gzip.

Answer 2

È possibile scaricare alcune immagini di prova DICOM codificati in 1.2.840.10008.1.2.1.99 sintassi di trasferimento da qui:

http://www.dclunie.com/images/compressed/

Quando si estrae archivio, le immagini con sintassi di trasferimento Sgonfiato sono denominati: name_dfl

Quella sintassi di trasferimento è solo quella che comprime interi dati DICOM ma quando l'ho aperta in Hex Editor XVI32 sembra che i metadati del file dicom non siano compressi in modo da poter leggere la sintassi del trasferimento, ma non sono riuscito a trovare altre immagini codificate in quel trasferimento sintassi quindi non ne sono sicuro.

Answer 3

Se ricordo correttamente, DICOM divide la maggior parte dei flussi in due Dataset, il primo è la metadata del file DICOM, che è sempre codificata come Explicit VR Little Endian Transfer Syntax, il secondo Dataset è codificato come indicato nelle informazioni sul file meta .

Da:

http://medical.nema.org/dicom/2013/output/chtml/part10/chapter_7.html

Il tag description "Trasferimento Sintassi UID" è:

Identifica il trasferimento sintassi utilizzata per codificare il seguente set di dati. Questa sintassi di trasferimento non si applica al file Meta Informazioni.