On 6/29/19, Michael Niedermayer <mich...@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 <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.
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. > _______________________________________________ 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".
