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 <mich...@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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
