DICOM xáo trộn rõ ràng VR Little Endian (1.2.840.10008.1.2.1.99)

Question

Dữ liệu trong cú pháp chuyển giao này được tổ chức như thế nào? Mô tả từ tiêu chuẩn:

Cú pháp chuyển này áp dụng cho mã hóa toàn bộ Tập dữ liệu DICOM. Toàn bộ Tập dữ liệu được mã hóa đầu tiên theo các quy tắc được chỉ định trong Phần A.2. Toàn bộ luồng byte sau đó được nén bằng thuật toán "Deflate" được xác định trong Internet RFC 1951.

Ban đầu tôi lấy điều này có nghĩa là toàn bộ tệp DICOM đã được nén. Nhưng nếu toàn bộ tập tin được gzipped, bao gồm cả tiêu đề có chứa cú pháp chuyển giao xác định, làm thế nào một phân tích cú pháp/người xem có thể đọc cú pháp chuyển giao để biết nó được gzipped?

Từ góc nhìn của người xem được cung cấp một tệp thuộc loại này, làm cách nào để biết tệp này có cú pháp chuyển giao này? Tìm tiêu đề GZIP?

Có bất kỳ hình ảnh mẫu có sẵn công khai nào sử dụng cú pháp chuyển này không?

Answer 1

Đối với các ví dụ được trỏ đến bởi @ Springfield762, mỗi tệp _dfl có luồng làm lệch hợp lệ từ 300 byte lẻ đến 8 byte từ cuối. Họ từng giải nén một cái gì đó về độ dài của tập tin tương ứng trong kho lưu trữ mà không có hậu tố _dfl, nhưng dữ liệu không giống nhau. Có thêm giải mã cần thiết để lấy dữ liệu đã giải nén về bản gốc.

image_dfl có luồng giảm phát bắt đầu tại offset 334, report_dfl ở 348 và wave_dfl ở 314. Chúng giải nén tương ứng là 262682, 6178 và 62408 byte.

Tám byte cuối cùng sau mỗi luồng làm lệch cũng giống như đoạn giới thiệu gzip, nghĩa là CRC-32 của dữ liệu được giải nén (bốn byte) theo sau là độ dài không nén theo thứ tự cuối nhỏ. Cả hai đều khớp với dữ liệu kết quả từ việc giải nén luồng làm lệch hướng.

Các byte trước dữ liệu làm lệch hướng là không phải là tiêu đề gzip.

Answer 2

Bạn có thể tải một số hình ảnh thử nghiệm DICOM mã hóa trong cú pháp chuyển 1.2.840.10008.1.2.1.99 từ đây:

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

Khi bạn giải nén lưu trữ, hình ảnh với cú pháp chuyển xì hơi được đặt tên: name_dfl

Cú pháp chuyển giao đó chỉ là cú pháp nén toàn bộ dữ liệu DICOM nhưng khi tôi mở nó trong Hex Editor XVI32 thì có vẻ như siêu dữ liệu của tệp dicom không nén nên bạn có thể đọc cú pháp chuyển, nhưng tôi không thể tìm thấy hình ảnh khác được mã hóa trong đó chuyển cú pháp vì vậy tôi không chắc chắn.

Answer 3

Nếu tôi nhớ lại chính xác, DICOM chia hầu hết các luồng thành hai Tập dữ liệu, thông tin meta đầu tiên của tệp DICOM, luôn được mã hóa dưới dạng Cú pháp chuyển giao ít rõ ràng VR, Tập dữ liệu thứ hai được mã hóa như được chỉ ra trong thông tin meta tệp .

Từ:

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

Các "Chuyển Cú pháp UID" tag mô tả là:

Độc đáo xác định Chuyển Cú pháp sử dụng để mã hóa như sau Tập dữ liệu. Cú pháp Chuyển này không áp dụng cho Thông tin về Tập tin Meta .