[FFmpeg-devel] [PATCH] Add DICOM Support

[Michael Niedermayer]

On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote:
> 
> On 6/26/19 4:37 PM, Michael Niedermayer wrote:
> >On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote:
> >>On 6/26/19, Michael Niedermayer <michael at niedermayer.cc> wrote:
> >>>On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote:
> >>>>On 6/25/19 2:12 AM, Michael Niedermayer wrote:
> >>>>>On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote:
> >>>>>>Hi!
> >>>>>>
> >>>>>>     The code is to add DICOM Support. The patch is only for
> >>>>>>uncompressed
> >>>>>>dicom files using explicit value representation. I would extend it, once
> >>>>>>i
> >>>>>>clarify some doubts.     As dicom image files contain lots of metadata
> >>>>>>about
> >>>>>>the patient. So, should i display that data while demuxing or should i
> >>>>>>ignore and only demux the image data ?. In the current patch, i have
> >>>>>>made an
> >>>>>>option "-metadata", which when used will print the data on the terminal
> >>>>>>while demuxing.
> >>>>>metadata should be exported to be usable by applications.
> >>>>>
> >>>>>For teh API design a one test is that it should be possible to have a
> >>>>>dicom file as input and a format with similar features as output and not
> >>>>>loose any significant data.
> >>>>>Printing to the terminal cannot achieve that easily.
> >>>>So, should i export it to a csv file ?
> >>>does it fit into the metadata system we have ?
> >>>
> >>To clarify, you mean frame metadata system?
> >data that is specific to a frame would belong in the frame metadata
> >data that is specific to a stream would belong into that streams metadata
> >data that is specific to the container would belong to its metadata
> >
> >iam not sure if multiple streams or frames can be in a single dicom
> >"container" / file. If they can then it should be clear what goes where
> >if not then all 3 options would from the point of view of dicom be the
> >same. And in that case what is most convenient for interoperation with
> >other formats should be picked. That is lets introduce the least amount
> >of differences to how similar data is handled in other formats
> 
> Dicom files contain multiple frames, but number of streams is always one
> (video) like GIF,( I haven't done multiframe support yet i am working on it
> ), The data specific to image/frames/pixels can be fit in the three
> categories of our metadata system, 

> but their is extradata in DICOM files
> like : patient_name, medical_device_name , medical_procedure_done,
> study_date....

why could this not be fit in metadata ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190627/0e2f2ba4/attachment.sig>