[FFmpeg-devel] [PATCH] Add DICOM Support

[Paul B Mahol]

On 6/29/19, Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Fri, Jun 28, 2019 at 02:02:29PM +0530, Shivam wrote:
>>
>> On 6/27/19 9:21 PM, Michael Niedermayer wrote:
>> >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 ?
>>
>> Yeah this can fit in the key, value pair of our AVDictionaryEntry (and
>> can
>> be written with "-f ffmetadata"). So, should i assign this to streams
>> metadata or containers metadata as this data is not stream specific or
>> container specific ?.
>
> whatever paul preferrs, if he has an oppinion on it. Otherwise choose
> what feels better to you.

Depends where is metadata stored, if its on container level, then
obviously as stream metadata, otherwise as frame metadata.

>
>
> Thanks
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>