Also something I did not mentioned above, is that the frame rate changed from 25p to 29.97p.
I do not do anything. Why does this happen?
Does compatibility exist between DPX from cf2dpx and SCRATCH,
Did I miss something in SCRATCH settings?
In your conversation with David Newman of Cineform on DVINFO,
He mentions XNVIEW, bit it has some issues as a viewer as far as I know:
1) May reverse red/blue for 16bpc DPX. (try making 16bpc DPX from REDCINE-X and see if the RED/BLUE match in Scratch and XNVIEW, let me know what you see)
2) Crops data to 8 bits (unless they have updated that)
3) I have not seen their having a soft clip adjustment.
You cannot load LOG DPX without softclip if soft clip has not already been applied since the values between 685 and 1023 will not be visable, soft clip prevents blow-out highlights if the data was recroded in the "super-white" area above white clip. The way Cineon (tm) files were designed, was as a archive format for film negatives that would not be re-saved graded, but soft-clipped when run through the LUT in the film recorder, or converted to 8 bit formats for TV use. Without soft-clip LOG files are unusable for film like results from digital sources. It's possable to save the LOG file with soft-clip done, in that case there is no extra data above 685.
What I was asking, was are the so called "LIN" files, in fact gamma 0.45 compensated (1/2.222 = 0.45)?
If the Cineform (tm) convertor is making "LIN" files, then are they 64-940 range or 0-1023 range, I can see that on the histograms of the DPX data and with a digital density probe, you look to see if the highlights are 940 or 1023 in the blown out areas, and if the shadows are under 64.
Actual "linear" files would be at gamma 1.0 not 0.45, but 10 bits is not enough data for real linear data to be stored for Digital Cinema Camera use.
Dan, you're making this way more complicated than it needs be. The whole discussion on how lin is not actually gamma 1.0 is theoretically interesting but not relevant to the problem.
Mike already gave the answer. Scratch by default assumes dpx's to be log. So you need to set them to lin. You can do this in the Scratch's media browser for all clips in one go. Or for individual clips in the shot config.
I have done another tests.
DaVinci Resolve for Mac can import the same sequences correctly.
DJV playback software cannot read DPX sequences from cf2dpx and report "[ERROR] WGL - Cannot get pixel format (#0)".
(Tool menu/Information or shortcut key "4" - popup new window
View menu/HUD or shortcut key "h" - data overlay image
for viewing DPX file header information)
DJV Imaging - Downloads
Here are download link (type file download code:2d7383ab) for DPX sequences and snapshot(4 png files) about importing in DaVinci Resolve.
Can one assume that Scratch uses HD limits of 64-940 by default for so called "LIN" monitor gamma DPX, or does it load 0 to 1023, and map that to 0-255 for 8 bit graphic cards by linear scaling? Or does it map 0-1023 to 16-235? Or map 64-940 to 0-255?
For the "LOG" files, does Scratch automatically apply softclip to push the highlights from 1023 down to 685, or does it automatically clip all file data above 685 off for default conversion of LOG to monitor gamma?
Does Scratch default 8 bit monitor gamma in the range of 0-255 or 16-235?
The ITU limits come up for viewing on LCD monitors which can have issues with highlight detail etc.
You can set monitoring to full-range or 16-235. Or load any display LUT for that matter. Both on UI monitor and DVI or SDI output. I monitor 10-bit out of SDI which you can set to YUV 8 or 10 bit or RGB 8 or 10 bit - and set to fullrange or 'legal'.
By default when loading LIN dpx's (which are usually not actually gamma 1.0 but 2.4 - so 'VID' would be a more useful notation) Scratch does not scale back to 16-235. If the material is fullrange it shows as fullrange.
gamma 2.4 I don't think is right it should be the inverse of 0.45 or 2.22 for HD use, 2.4 is the monitor gamma, but HD images and some DCP images are encoded for 2.22 showing midtone a bit off center on standard gamma 2.4 monitors because of room lighting being on, and also encoded 2.22 for DCP projectors at gamma 2.6 because the room lights should be off in the movie theatre. Maybe someone at SCRACH can say what the default encoding gamma would be for HD DPX, and if they just map 0 to 1023 to 0 to 255 by default, showing 64 to 940 HD DPX as washed out?
If the input is full range, and the file is 64-940, then setting the monitor to sub-range 16-235 (0-15 not output and 236-255 not output) would only make the monitoring more washed out (on a 0-255 monitor) since that is a second contrast decrease, a third monitoring option of clip and expand to 0-255 would be needed to exapand 64-940 subrange on full read, to fill 0-255 on the monitor... I guess maybe that is to be done with some non-default LUT? But it would seem to be a common issue?
If the link above gets fixed, I can look at the histograms and see if cf2dpx is making 64-940 or 0-1023 "LIN" type DPX. One way to tell LOG is that from Digital Cinema Cameras there should be no data under code 95, whereas "LIN" would have histogram data between 64 and 95 most of the time, so that might be a way to auto select.
|« Previous Thread | Next Thread »|