Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


CaptainHook last won the day on August 30 2018

CaptainHook had the most liked content!

About CaptainHook

  • Rank

Profile Information

  • Location
    Melbourne, Australia

Contact Methods

  • Facebook
  • Twitter
  • Instagram

Recent Profile Visitors

636 profile views
  1. This is not what noise looks like from the ADC. This is not natural and its not the finest details captured, its MORE. The information is made up in the debayer. I know it is. People also seem to think cDNG has no processing before the file is stored in camera but cDNG is subject to calibration (which attempts to reduce noise and other issues) and other processing before those "RAW" pixels are stored as DNG also. Its okay to like it more too. Doesn't mean its the same process or the same thing. An OLPF can look similar to Gaussian Blur too. I get some people prefer cDNG, that's totally fine. But some people are acting like the image was faultless, which it certainly was not. And when there are incorrect statements made as fact, I will try to correct when I'm able to (IP and other concerns restricts my public involvement). The decisions made over a 2 year process developing Blackmagic RAW were not arbitrary or taken lightly either.
  2. Ignoring the made up numbers here, in terms of debayer quality the method for cDNG is much older as not anywhere near as good as Blackmagic RAW. I see a lot of people mistake the artefacts of the DNG debayer as sharpness. Its not that the cDNG debayer is necessarily keeping more details, but it IS creating false detail. An interesting comparison was just posted here that's worth looking at : https://forum.blackmagicdesign.com/viewtopic.php?f=2&p=510320#p510320 Especially this image - what you're seeing on the DNG is not real information the DNG retained, it's CREATING it (falsely) and it can look like sharpness/detail when it's over areas of real detail, but it's a very "hard" and digital feeling look IMHO : But also pay really close attention to the resolution image at the above link. You can see on the right hand side the artefacts between the red and yellow resolution lines and around the edges of the circle. These artefacts are not real detail or sharpness that you lose with Blackmagic RAW, they are created in error. Something to consider as well is we get a lot of feedback from customers that 4.6K Blackmagic RAW still has more resolution than some "other" cameras 8K RAW images - likely because of strong optical low pass filtering that without could produce similar artefacts as shown in DNG. The highlights and shadows sliders in cDNG are NOT debayering RAW controls and work on debayered data only. They are the exact same (mathematically) as the ones in the primaries tab and work exactly the same on Blackmagic RAW as the DNG RAW tab ones. I demonstrated this for someone on Facebook last year..
  3. Resolve 15.3 has a build of SDK 1.3 which does support LUTs in the sidecar, they just need to be manually placed in the sidecar at this time (we would like to add the ability to add LUTs to the sidecar through the Resolve UI in a future update). If you're brave I've attached a sample sidecar with a 3DLUT (B&W to make it easy to tell its working) which shows the syntax needed. Open the sidecar in a text editor and you can copy in any Resolve formatted 3DLUT (can also open LUTs in a text editor) into the sidecar file data section (inside the quotes) and make sure the "post_3dlut_sidecar_size" number matches the "LUT_3D_SIZE" from the 3DLUT. Just rename the sidecar file to the same as your clip. If you are going to add it to an existing sidecar, put it at the top of the sidecar data inside the curly brace (the current build in Resolve requires it but a future build will not be as strict) and put a comma after the LUT data quote (this is JSON syntax). If you already have the clip in a Resolve timeline, you'll need to remove the clip from the timeline and from the media pool and relink it as Resolve will cache and not pick up the sidecar change. If you just want to test, making a new project and bringing in the clip might be faster. You'll need to use Blackmagic RAW player 1.3 which is inside the Resolve app bundle so make sure that version is the one being used when viewing clips not using Resolve. In general though so you are aware the sidecar is just for the controls you find in the RAW panel, the SDK (and applications using it) can't recreate all the complex colour grading operations you can do in Resolve. I've also attached a sample Blackmagic RAW frame with an embedded 3DLUT. If you view this in Resolve, go to the RAW panel and change to clip decode and you will see you can enable/disable the 3DLUT, and change from the embedded 3DLUT to the sidecar LUT. This gives you more options for making sure when passing around clips the intention of how you want it to look is preserved non-destructively in any app that supports SDK 1.3+ (when released) which i think is pretty cool! sample.sidecar sample.braw
  4. What version of the player and what Resolve version are you using? What GPU and OSX version?
  5. It did, at calibration time during manufacturing. But more can develop over time like all sensors, and in unfortunate situations even before the customer receives it. Some companies have publicly known policies on how many "defective" pixels are acceptable, including for displays etc.
  6. By that definition you have probably never used raw then, as I haven't come across any camera that supports uncompressed/lossless raw that doesn't alter the sensor data in a process referred to as "calibration" - where every pixel is altered. That can include noise reduction and other processing that's already applied before the raw file is created. Some sensors do this on chip before the ADC! I've also never seen a camera that doesn't do pixel remapping as all sensors suffer hot/dead pixels. Some even offer user initiated pixel remapping to address this as it can occur over time. Which means lots of pixel data is CREATED because the sensor didn't provide useful information. So yeah, no camera from any manufacturer I have seen or used would qualify as offering "raw" to your standard. People seem to have a romantic and idealised notion about what raw is.
  7. We write the file headers/close the file every 5 secs during record, our cameras since the BMCC have always periodically written the headers/closed the file so at most if you lose power you might lose the last 5 secs of the clip. If you lose power before 5 secs of recording, then it could be an issue.
  8. Gen 4 uses a common defined gamut so you can use Broadcast Film for space (Broadcast Film gamut is the same as Pocket4K/UMP/etc Gen 4 gamut) and Pocket 4K Film for gamma. Hopefully this will be cleaned up a little in a future update.
  9. It was a correction to the original chart.
  10. Looked into this and the steps that some lenses report will result in a value that's smaller than the precision of the numbers we show. So for instance the lens may allow two settings around f14 where the "second" one is still closer to f14 than f15 so we display both as f14. The opposite can also happen where some lenses will report settings where it DOES fit in a our precision to show two different values but the lens doesn't actually change aperture enough to see any difference. We assume Panasonic etc know of these settings across the lenses and compensate/ignore them etc as necessary in their cameras.
  11. If you can let me know exact MFT lens models and describe the issue in repo steps I can follow it up. There is one known issue at the moment that some times the lens won't set the correct aperture we tell it to, but for the aperture number to stay the same on the camera UI display but the lens actually change sounds like something different. Will look into what you mention nRF Connect too.
  12. What lenses is this happening with? I've scanned the thread but every mention seems to indicate a focal reducer of some kind which may actually be the issue, rather than direct control of an MFT lens.
  13. FYI just in case you're not aware, midtone detail is also available in the primary tab and is not a raw tab exclusive control.
  14. Historically (not that we've made cameras THAT long) we've always converted internally to YUV/YCbCr no matter the codec for SDI output etc. It's then convenient and easier on resources to do image statistics on just luma for zebras/false colour and that has not changed. RGB would be more ideal, yes. Personally I always set zebras to 95% for some slight headroom (even before I worked for the company and learnt how it worked) and after i joined and we added false colour, the "red" (highlight clipping) on false colour is actually at 95% for the same reason.
  15. Zebras are currently based on Luma or the Y channel of YCbCr (as it has been since the first BMCC).
  • Create New...