Thread: DPX sequences from CineForm cf2dpx import to Assimilate SCRATCH

Reply to Thread
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27
  1. #11  
    Senior Member mikeburton's Avatar
    Join Date
    Sep 2007
    Location
    Sacramento CA
    Posts
    1,669
    Quote Originally Posted by Gerry Lee View Post
    hello, Mike.
    I have this snap picture, please check 3rd picture.
    In construct window show source is read as LOG.
    This is your problem. Click the "Log" button and change it to Lin and all will be right with the world.
    Reply With Quote  
     

  2. #12  
    What do you think about XnView, which can read DPX directly, but seem have some limitation?
    Reply With Quote  
     

  3. #13  
    Quote Originally Posted by mikeburton View Post
    This is your problem. Click the "Log" button and change it to Lin and all will be right with the world.
    Please see the look of source in Import window(1st picture) is right, but the look in Construct window after imported is changed(recognized as LOG).
    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,
    or
    Did I miss something in SCRATCH settings?
    Reply With Quote  
     

  4. #14  
    Senior Member Dan Hudgins's Avatar
    Join Date
    Feb 2007
    Location
    San Francisco, CA USA
    Posts
    1,370
    Quote Originally Posted by Gerry Lee View Post
    What do you think about XnView, which can read DPX directly, but seem have some limitation?

    In your conversation with David Newman of Cineform on DVINFO,

    http://www.dvinfo.net/forum/cineform...e-scratch.html

    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 Hudgins is developing "Freeish" 6K+ NLE/CC/DI/MIX File based Editing for uncompressed DI, multitrack sound mixing, integrated color correction, DIY Movie film scanning, and DIY Movie filmrecorder software for Digital Cinema. RED (tm) footage can be edited 6K, 5K, 4.5K, 4K, 3K, 2K, or 1080p etc. see http://www.DANCAD3D.com/S0620200.HTM (sm) for workflow steps.
    Reply With Quote  
     

  5. #15  
    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.

    Barend
    Raamw3rk
    independent colourist and vfx artist
    Reply With Quote  
     

  6. #16  
    Quote Originally Posted by Barend Onneweer View Post
    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.

    Barend
    Thanks for everyone give me kindly help.

    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

    Here are download link (type file download code:2d7383ab) for DPX sequences and snapshot(4 png files) about importing in DaVinci Resolve.
    Reply With Quote  
     

  7. #17 LOG LUT? 
    Senior Member Dan Hudgins's Avatar
    Join Date
    Feb 2007
    Location
    San Francisco, CA USA
    Posts
    1,370
    Quote Originally Posted by Barend Onneweer View Post
    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.

    Barend
    Thanks for the insight Barend.

    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.
    Dan Hudgins is developing "Freeish" 6K+ NLE/CC/DI/MIX File based Editing for uncompressed DI, multitrack sound mixing, integrated color correction, DIY Movie film scanning, and DIY Movie filmrecorder software for Digital Cinema. RED (tm) footage can be edited 6K, 5K, 4.5K, 4K, 3K, 2K, or 1080p etc. see http://www.DANCAD3D.com/S0620200.HTM (sm) for workflow steps.
    Reply With Quote  
     

  8. #18  
    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.
    Raamw3rk
    independent colourist and vfx artist
    Reply With Quote  
     

  9. #19 HD DPX 
    Senior Member Dan Hudgins's Avatar
    Join Date
    Feb 2007
    Location
    San Francisco, CA USA
    Posts
    1,370
    Quote Originally Posted by Barend Onneweer View Post
    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.
    Thanks for the information, I was asking about the 64-940 issue, because if that is mapped full 0 to 1023 to 0-255 then the images may look a bit washed out, and it was my understanding that 1920x1080 HD DPX are "always" 64-940, so they would need to be clipped on input to display with full black and white.

    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.
    Dan Hudgins is developing "Freeish" 6K+ NLE/CC/DI/MIX File based Editing for uncompressed DI, multitrack sound mixing, integrated color correction, DIY Movie film scanning, and DIY Movie filmrecorder software for Digital Cinema. RED (tm) footage can be edited 6K, 5K, 4.5K, 4K, 3K, 2K, or 1080p etc. see http://www.DANCAD3D.com/S0620200.HTM (sm) for workflow steps.
    Reply With Quote  
     

  10. #20  
    Quote Originally Posted by Dan Hudgins View Post
    ……
    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.
    I have update the link.

    http://bit.ly/oyAjHK
    (type file download code:2d7383ab)
    Reply With Quote  
     

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts