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.

[M Most]

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.

I would humbly suggest that you'd be much better off asking this question on either Assimilate's support site, their Google group, or somewhere on a forum devoted to either Cineform or GoPro. This being RedUser, the Scratch section is devoted primarily to Scratch's use with Red files.

[Dan Hudgins]

Any suggestion could you like to share with us?

I have a "fool proof" tool in the image processing program I am developing for dealing with any such DPX issues, if you can send me some sample DPX files by email, one DPX per email, I can look at the data in the DPX file and its header, and maybe send you back some information about the data values.

If you can shoot a 90% white card, a 18% Gray card and a 2% Black card in a test frame, and make that into a DPX with the EI/ISO set right and K value right, that can give a result that is closer to exact.

You have your PM disabled, and your web site does not show an obvious email in English, you should fix both of those if you want people to help you.

My mail is at the top of each page of my DI system web site, tempnulbox (at) yahoo (dot) com keep the total DPX file size under 20MB per email by using *.zip or *.7z (7-zip format).

If anyone else has DPX issues feel free to contact me and I can look at samples with my DPX tools, please put "DPX file issues" in the subject line of your email so I know its not junk.

[mikeburton]

If you click onto the bottom portion of the Thumbnail in the Construct you see a detailed metadata window pop up. check and see if your file is being read as LOG or LIN. I assume its probably being read as LOG and if you change to LIN your image will represent as it should.
But I also agree with Mike, this topic should be presented on the Assimilate support site and not on REDUSER.

[Gerry Lee]

You have your PM disabled, and your web site does not show an obvious email in English, you should fix both of those if you want people to help you.

Sorry for that, I have changed my profile to accept PM.
Thanks for your kindly help.

[Gerry Lee]

But I also agree with Mike, this topic should be presented on the Assimilate support site and not on REDUSER.

Thanks for your suggestion.

[Dan Hudgins]

If you click onto the bottom portion of the Thumbnail in the Construct you see a detailed metadata window pop up. check and see if your file is being read as LOG or LIN. I assume its probably being read as LOG and if you change to LIN your image will represent as it should.
But I also agree with Mike, this topic should be presented on the Assimilate support site and not on REDUSER.

I was wondering what LIN means in this case as real Linear data as in how sensor data is linear would not seem to apply.

Are you saying that LIN is like Rec709 or other gamma 0.45 monitor corrected data where 18% Gray is about 0.462 normalized signal?

If LIN is not monitor gamma corrected then 18% Gray would be 0.18 or lower normalized signal, as it would be in sensor data without 0.45 monitor gamma correction (normalized after adjusting for sensor blacklevel offset).

Would LIN allow for the ITU/CCIR limits, in the case of 10bit DPX HD at black_clip=64 white_clip=940 and 18% Gray at about 470?

(940-64) = 876, 876*0.462 = 405, 405+64 = 469 or about the same as Cineon (tm) 470 for mid-tone 18% Gray.

1023*0.462 = 473 or about the same as Cineon (tm) 470 for 18% midtone.

1023*0.18 = 184, black level about 1023*0.0925 = 95, so 18% gray would be value 278 or less with black offset of 95,

Or are those adjustments a sub-set of LIN selection?

A = LIN_sensor_linear (somehow also needing ISO curve, midtone at black offset plus about 184 or less)

B = LIN_monitor045 (0 to 1024 limits, midtone at 470)

C = LIN_monitor045_plus_ITU_limits (64-940 limits, midtone at 470)

D = LOG (95-685 midtone at 470)

E = LOG (other limits?)

So which of those does LIN mean?

I guess both B and C can display without LUT on a monitor, so I guess what I am asking is would B and C (called LIN even though they are gamma 0.45 corrected) have midtone near 470 and so not require a monitor LUT, or would they have midtone near some lower value and require monitor gamma correction to be viewed?

[Gerry Lee]

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

[Gerry Lee]

If you click onto the bottom portion of the Thumbnail in the Construct you see a detailed metadata window pop up. check and see if your file is being read as LOG or LIN. I assume its probably being read as LOG and if you change to LIN your image will represent as it should.

hello, Mike.
I have this snap picture, please check 3rd picture.
In construct window show source is read as LOG.

[Dan Hudgins]

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

My tools are under development, but you can convert the DPX to BMP without using a LUT, then read the pixel values in the freeish program IRFANVIEW, use gogle for that. Multiply times 4 to get about the 10bit value.