Início / coding / Perguntas / 78842605
Accepted
simon
Asked: 2024-08-07 16:29:45 +0800 CST

Deslocamento de 16 bytes na exportação de vídeo MPEG-4 do arquivo DICOM

  • 772

Versão curta : De onde vem o deslocamento de 16 bytes ao exportar um fluxo de vídeo MPEG-4 de um arquivo DICOM por Pydicommeio do código a seguir? (E, pergunta bônus, é sempre um deslocamento de 16 bytes?)

from pathlib import Path
import pydicom

in_dcm_filename: str = ...
out_mp4_filename: str = ...

ds = pydicom.dcmread(in_dcm_filename)
Path(out_mp4_filename).write_bytes(ds.PixelData[16:])  # 16-byte offset necessary

Para reprodutibilidade, pode-se usar, por exemplo, este arquivo DICOM que encontrei nesta antiga discussão nos Grupos do Google (aviso de conteúdo: o vídeo mostra o cérebro aberto em uma intervenção neurocirúrgica).

Versão longa

Eu tenho vários arquivos DICOM contendo fluxos de vídeo cirúrgicos MPEG-4 (sintaxe de transferência UID 1.2.840.10008.1.2.4.102 – MPEG-4 AVC/H.264 High Profile / Level 4.1 ). Eu queria exportar os fluxos de vídeo dos arquivos DICOM para facilitar o manuseio em tarefas posteriores.

Depois de pesquisar um pouco no Google, encontrei a seguinte discussão , sugerindo o uso de dcmdumpfrom DCMTK, da seguinte maneira (que consegui reproduzir):

  • Correr dcmdump +P 7fe0,0010 <in_dcm_filename> +W <out_folder>.
  • Dos dois arquivos resultantes em <out_folder>, mpeg4.dcm.0.rawe mpeg4.dcm.1.raw, descarte o primeiro, que tem tamanho de 0 bytes, e mantenha o segundo (potencialmente alterando seu sufixo para .mp4), que é um arquivo de vídeo normal e reproduzível.

Pelo que vi no dcmdumpcomando, concluí que era apenas um despejo bruto de tag 7fe0,0010(que é o atributo Pixel Data ), então pensei em reproduzir isso com Pydicom. Minha primeira tentativa foi usar Path(out_mp4_filename).write_bytes(ds.PixelData)(veja o exemplo de código acima para detalhes completos); no entanto, acabei com um arquivo que não pôde ser reproduzido. Em seguida, comparei um despejo hexadecimal do dcmdumpresultado e do Pydicomresultado:

$ hd ./dcmdump.mp4 | head
00000000  00 00 00 20 66 74 79 70  69 73 6f 6d 00 00 02 00  |... ftypisom....|
00000010  69 73 6f 6d 69 73 6f 32  61 76 63 31 6d 70 34 31  |isomiso2avc1mp41|
00000020  00 00 00 08 66 72 65 65  00 ce 97 1d 6d 64 61 74  |....free....mdat|
...
$ hd ./pydicom.mp4 | head
00000000  fe ff 00 e0 00 00 00 00  fe ff 00 e0 3e bc ce 00  |............>...|
00000010  00 00 00 20 66 74 79 70  69 73 6f 6d 00 00 02 00  |... ftypisom....|
00000020  69 73 6f 6d 69 73 6f 32  61 76 63 31 6d 70 34 31  |isomiso2avc1mp41|
...

A partir disso, percebi que minha Pydicomexportação continha 16 bytes extras anteriores. Depois de removê-los por meio do Path(out_mp4_filename).write_bytes(ds.PixelData[16:]), obtive exatamente a mesma exportação de vídeo reproduzível que o dcmdump.

Então, novamente, minha pergunta é: de onde vêm esses 16 bytes extras, qual é o seu significado e estou seguro simplesmente removê-los?

python

1 respostas

  1. Best Answer

    A razão pela qual você vê esses bytes é que os dados do pixel são encapsulados . O uso do dcmdump mostra isso claramente:

    (7fe0,0010) OB (PixelSequence #=2)                      # u/l, 1 PixelData
  (fffe,e000) pi (no value available)                     #   0, 1 Item
  (fffe,e000) pi 00\00\00\20\66\74\79\70\69\73\6f\6d\00\00\02\00\69\73\6f\6d\69\73... # 13548606, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem

    Se você verificar os bytes iniciais removidos, poderá ver que eles contêm as respectivas tags delimitadoras, conforme mostrado na saída do dump. Você também pode ver que há 2 itens contidos, o primeiro deles vazio - esses são os que você obtém usando o dcmtk.

    Para obter o conteúdo encapsulado, você pode usar encaps.defragment_datano pydicom 2.x, que retorna todos os fragmentos contidos em um bloco de dados (no pydicom 3, a interface mudará para produzir um fragmento por vez):

        from pydicom import dcmread, encaps

    ds = dcmread"test_720.dcm")
    with open("test_720.mpeg4", "wb") as f:
        f.write(encaps.defragment_data(ds.PixelData))

    Observe que, em geral, os fragmentos são partes de dados multiquadro (no caso mais comum, um fragmento por quadro) e você pode querer tratá-los separadamente. No caso do MPEG4, há apenas um fluxo de dados contínuo com os dados de vídeo, e a fusão de quaisquer fragmentos em que este possa ser dividido é a maneira correta de lidar com isso.

    • 2

relate perguntas