As feared, my table of results got mangled. Let's see if this work any
better in plain text:
CodecExport Quicktime displayRe-import compare Levels
DnxHD 220xRGBClipped and stretched *601Unchanged
601Full range (unchanged) 601Unchanged
RGBClipped and stretchedRGBGamma correct, clipped **
601Full range (unchanged)RGBNothing clipped, range squeezed ***
ProRes HQRGBClipped and stretched601Unchanged
601*/Clipped and stretched/*601Unchanged
**
RGBClipped and stretched**RGBGamma correct, clipped
601*/Clipped and stretched/*RGB*/Gamma correct, clipped/*
On 12-09-22 9:28 PM, Michael Brockington wrote:
>
> Hi Job:
>
> Thanks for doing some testing. I've reproduced your results.I've done
> more tests as well, and can conclude that ProRes files exported
> Same-as-source from Avid do behave differently than DNxHD exports in a
> couple of cases.
>
> In a nutshell, ProRes exports always behave as though they were exported
> as RGB, regardless of whether RGB or 601 was chosen in the export
> dialogue.
>
> This is consistent with the results you just reported, as well as the
> odd results I reported earlier in this thread.
>
> Here's a table of my results that lead me to this conclusion.I limited
> my testing to DNxHD220x and ProRes HQ, but imagine the results would
> hold for other codecs in the same family.
>
> The DNxHD results are as expected.I have highlighted the 2 cases in this
> table where the ProRes results differ from the DNxHD.In both cases, it
> appears the ProRes results ignore the export flag being set to 601, and
> are always treated as though the Avid export flag was set to RGB.
>
>
>
>
> *Clipped and stretched -- indicates values have been truncted below 16
> and above 235, then stretched to the range 0-255.
>
> ** Gamma correct, clipped -- no values exist above 235 or below 16, but
> everything in between is unchanged.
>
> *** Nothing clipped, range squeezed -- the full range of values 0-255
> have been scaled into the range 16-235.So no values exist above 235 or
> below 16, but nothing has been truncated.
>
> It seems likely the RGB/601 setting for Avid quicktime exports just sets
> a flag in the quicktime file -- no pixel values are actually changed in
> the file during output.If this were not the case, then it would take
> longer to output an RGB file as 601, or vice-versa, when in practice,
> quicktime output seems to take the same length of time regardless of the
> RGB/601 output setting.
>
> When 601 is set on import, it overrides any RGB flag setting in the
> quicktime file, allowing access to the original pixel values.
>
> When RGB is set on import Avid actually changes the pixel values of the
> imported file, mapping 16 to 0 and 235 to 255, crushing all values below
> 16 and all values above 235.The pixel values are permanently truncated.
>
> Avid may never read the RGB/601 flag from the quicktime file on import
> since the user always specifies one or the other on import.
>
> In these tests, After Effects shows the same results as desktop preview
> in the finder.So it is honouring the 601/RGB flag correctly when
> importing DNxHD quicktimes, and it is also treating ProRes quicktimes as
> always having the RGB flag set.Unlike Avid, it has no way to override
> the 601/RGB flag on import.
>
> On 12-09-22 2:16 AM, Job ter Burg (L2B) wrote:
> >
> > Michael,
> >
> > I re-tested this, albeit in 6.0, on Mac.
> >
> > - Traditional Import the Belle Nuit Test Chart at 709 setting to Apple
> > ProRes MXF
> > - Splice into sequence
> > - Export Same As Source with 709 levels
> > - Re-Import (a Fast Import) that exported file at 709 setting
> > - Second import matches the first one 100%, also when watched on the
> WFM.
> >
> > My guess is that you are determining the color levels some other way,
> > and perhaps the application you are using for that is using Quicktime
> > to feed the signal. The way that I describe above makes no use of the
> > Quicktime software at all. It just rewraps from MXF to QT (Same As
> > Source export), then from QT to MXF (Fast Import).
> >
> > Job.
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
[Non-text portions of this message have been removed]
No comments:
Post a Comment