[FFmpeg-devel] [PATCH] Add DICOM Support

[Shivam]

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 ?.


Thank you,

Shivam Goyal