[FFmpeg-devel] [PATCH] Add DICOM Support

[Michael Niedermayer]

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.


Thanks

[...]
-- 
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/20190629/db2f5e0f/attachment.sig>