Question:DPX sequences from CineForm cf2dpx import to Assimilate SCRATCH

[Gerry Lee]

We found the look of DPX sequences from CineForm cf2dpx is strange(different) when it is imported to Assimilate SCRATCH,
the preview look in Import Window is right,
but the one in Construct Window is strange.
We tried to change Source Transform Settings, finally, it seems to have right look with Lin2Log with Gamma 2.2.

Any suggestion could you like to share with us?

snap pictures in attachment.

Thanks in advance.

[David Newman]

That seems to be a question for Scratch. DPX is what you see it what you get, we have no control over the look after it is created.

[Gerry Lee]

which "profile of DPX" is cf2dpx output form CineForm encoded AVI or MOV file?

"profile" I mean:
Log or Linear?
10-bit Linear? 12-bit Linear for SI-2K RAW source?
10-bit Log?
YUV or RGB?
Is all above is source related?
What has been write into DPX file header? Does it also include Timecode, Frame Rate?

Which tools of viewing DPX and its file header is recommanded or used for your studio?

Thanks.

[David Newman]

10-bit RGB, in whatever curve you have applied.

Yes, Timecode and believe frame rate also.

I use xnview.exe for quick DPX review.

[Gerry Lee]

Thanks, David.

Seem Assimilate SCRATCH by default assumes DPX's to be LOG. So user need to set them to LIN. User can do this in the SCRATCH's media browser for all clips in one go. Or for individual clips in the shot config.

Update:
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
or
View menu/HUD or shortcut key "h" - data overlay image
for viewing DPX file header information)
DJV Imaging - Downloads

[Gerry Lee]

David,

What you mean is that cf2dpx always output 10-bit RGB wherever CineForm MOV or AVI sources is( from SI-2K, r2cf, dpx2cf, convert form file, such as HDSLR, SONY, Panasonic, etc. capture form AJA/BMD), is right?
Is it same for r2cf to convert *.r3d to DPX?

While dpx2cf / r2cf tools have parameters to control look related data and metadata in converting process.

If we want to preserve maximum dynamic range of image by combining CineForm and DPX/TIFF, what do you suggest?

[Gerry Lee]

David,

Sorry, it seems my question related log vs linear processing workflow.

[David Newman]

There is no issue with 10-bit RGB, it is the default for most systems, and that is why we use it. As for curves, linear is bad in 10-bit, but any log curve will preserve the dynamic range.

[Gerry Lee]

Hi, David

Could you like to check the header of DPX (attachment teji017.part1.zip, teji017.part2.zip, teji017.part3.zip)?

Reference -

DPX sequences from CineForm cf2dpx import to Assimilate SCRATCH

from Dan Hudgins

Quote Originally Posted by danibam View Post
LIN or LOG are just flags in the DPX file header. In SCRATCH, as in many other applications, this flag in the DPX file header is used by the software to display it properly.
Daniel Perez

I looked at the header and it says:

DPX image information header . image element[1] . transfer = 0
DPX image information header . image element[1] . colormetric = 0

Those both are "user defined" so there is no LOG = 3 or LIN = 2 value set by cf2dpx, maybe some should talk to Cineform (tm) about why that is?

I looked at the data and it ranges from code values about 5 to 983, so I guess its a "full range" user-defined transfer curve.

See the attached BMP files showing the histogram for conversion without LUT adjustments, showing the code values from your DPX file un-altered other than scaling by 4.

I checked the signal levels as you can see the probe readouts on the left in the attached images (DPX_GRA2.BMP, DPX_GRA3.BMP),

White at 0.9610 * 1023 = 983

Black at 0.0052 * 1023 = 5

So those are out of the 64-940 range, using LIN and the monitor "full" setting should be the right choice, but the conversion from Cineform (tm) to DPX or the camera's recroding seems to be the issue with the blown-out-highlights.

In the case of "user defined" then SCRATCH should default to LIN = full range no curve, rather than default to LOG 95-685 since the curve is unknown, or at least not setup by the DPX file?

[Gerry Lee]

Pihlaja View is a DPX image sequence viewer
http://pihlaja.org/?sdmon=files/tria...beta-trial.dmg

DPX(DPX from cf2dpx) file header info view in Pihlaja

[Dan Hudgins]

The important question is why if you are shooting with RED ONE, and recording to wavelet compressed R3D files, would you then convert that into Cineform (tm) wavelet compressed RGB or YUV, and then convert that into 10bpc DPX?

It would be better to just make 16bpc DPX in REDCINE-X, or 16bpc TIF in REDCINE-X to start with as there would be less double compression losses and scaling errors.

In REDCINE-X you may be able to reduce the ISO by overriding the meta-data ISO to improve the highlight detail, then grade the 16bpc DPX or TIF frames back up in SCRATCH since it seems to use float internal.

REDCINE had something called DRX that improved highlight detail in over exposed shots, if you can find that in REDCINE-X, then try setting DRX at about 50% and reduce the ISO by one or two stops to see if you can get some highlight detail, then grade the 16 bpc DPX or TIF frames back up in SCRATCH by adjusting the S-curve to pull up the lower part.