[FFmpeg-devel] [PATCH] Add DICOM Support

[Shivam]

On 6/29/19 3:39 AM, Paul B Mahol wrote:
> 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.

Ok,

Thank You

Shivam Goyal