Valid header data differences when ditto key = 0

[jycm205]

We have some DPX files that produce the following warning message when trying to RAWcook them:

non-conforming DPX ditto key is set to "same as the previous frame" but header data differs

If I run mediatrace on two of the files and then diff the results, I get the following:

11,12c11,12
<         <data offset="36" name="FileName">0086400.dpx</data>
<         <data offset="136" name="Creation Date">2022:12:16:20:10:52UTC</data>
---
>         <data offset="36" name="FileName">0086401.dpx</data>
>         <data offset="136" name="Creation Date">2022:12:16:20:10:53UTC</data>
50,51c50,51
<         <data offset="1432" name="Source image filename">0086400</data>
<         <data offset="1532" name="Source image date/time">2022:12:16:20:10:52UTC</data>
---
>         <data offset="1432" name="Source image filename">0086401</data>
>         <data offset="1532" name="Source image date/time">2022:12:16:20:10:53UTC</data>
77c77
<         <data offset="1712" name="Frame position in sequence">0</data>
---
>         <data offset="1712" name="Frame position in sequence">1</data>
87c87
<         <data offset="1920" name="SMPTE time code">16777216</data>
---
>         <data offset="1920" name="SMPTE time code">16777217</data>

These are files that have been processed and exported from restoration software before RAWcooking, so the metadata differences look accurate to me, but I noticed that some of these fields ("Source image filename", "Source image date/time") aren't specifically mentioned in the Ditto Key section of FADGI's Guidelines for Embedded Metadata within DPX File Headers. Are those fields most likely what is causing the warning here? And -- this is maybe a more open-ended question -- if that is the cause of the warning, is flagging these files as non-conforming accurate?

[JeromeMartinez]

The DPX spec, and FADGI's Guidelines copy that, does not include Source image filename and Source image date/time in the list of fields authorized to change if the ditto key is 0, but it makes sense that theses field are specific per frame so should change as Image filename and Image date/time do (theses ones are listed as authorized to change).
We currently follow DPX specs for this DPX conformance checking, and all the files we have are with Image filename empty and Image date/time always set to same value so we didn't catch this issue.

In my opinion it makes sense that such field can change even with ditto key of 0, and I am going to add them to the list of fields authorized to change, @kmurmur you may be interested to comment that and/or update FADGI guidelines.

[jycm205]

Thanks for confirming!