@K.F.Wright… @Young seems to looking at the problem from an engineering perspective, and thats ok… K.F and I are just trying to communicate the more downstream needs of how this tech gets used.
If the camera records 10-bit linear RAW directly from the sensor, why do we need LOG, That’s a perfectly valid question.
I like to think of the sensor mainly as a the Advanced Photon capture device… We are happy to take all the dynamic range the sensor can possibly capture… However at some point you have to represent that capture to a human ….
Log is how you represent that capture down stream. So really Log is a workflow thing rather than thinking of it as capture thing.
The industry didn’t adopt LOG because sensors needed it to preserve data. The industry adopted LOG because humans need a practical way to view, expose, monitor, exchange, and grade high dynamic range images.
Linear RAW is ideal for recording, but terrible for humans
Linear data as I understand it is not how our eyes perceive brightness.A linear sensor allocates half of its code values to the brightest stop of exposure.Half of what remains goes to the next stop.Half again goes to the next.
And so on.
That’s mathematically efficient for recording photons, but it is not an intuitive way for cinematographers to judge exposure.
LOG curves exist largely because they redistribute those values into something more perceptually useful.
That’s why virtually every professional camera manufacturer records one thing and displays another.
-
ARRI records ARRIRAW but shows LogC.
-
RED records RAW but works through Log3G10.
-
Sony records RAW but provides S-Log.
-
Canon has C-Log.
-
Blackmagic has Film.
The sensor isn’t seeing or recording LOG, it’s seeing the linear raw photon count.
The operator needs to see this Log version of the linear raw since it’s much better for us as a human.
Monitoring is where LOG becomes important
I think this is the area where the Spark currently feels limited.Right now we’re effectively looking at Pixboom’s interpretation of a Rec.709 image.
That means we’re viewing a display transform rather than a representation of the sensor data itself.
The issue isn’t whether the recorded RAW is preserving dynamic range, we know it is since you’re giving us the cinema DNG exports.
The issue is that I don’t know what the sensor is truly seeing at the time of recording since right now the only way to really know is to stop and export dng’s, and this really isn’t a good way to do it on set exposure.
If a highlight clips on the monitor, I have to ask myself did the sensor clip? Or did the Rec.709 transform clip? Those are very different things.
A DP needs confidence in that distinction right on set just by looking at his tools on-board the camera or on the monitor… it maybe a combo of both.
That is exactly why RED created Traffic Lights and Goal Posts.
Those tools answer the question for the operator:
“What is the sensor doing?” not “What does my display LUT look like?”
The traffic and goal post measurement is taken at the sensor level regardless of what Lut transform is loaded. If I am over or under exposing a sensor I know it as I am shooting it.
Exposure tools become dramatically more useful
This is really the heart of my original point.
-
False color
-
Waveform
-
RGB parade
-
Zebras
All of these tools become more valuable when they’re referencing a predictable scene-referred image, (realtime log created from a linear raw data)
If the camera offered a Pixboom LOG output, then every monitor manufacturer could immediately work within a known exposure space.
A SmallHD operator could use the exact same exposure workflow they’re already using on RED, ARRI, Sony, or Venice.
That consistency reduces mistakes. More importantly, it reduces hesitation and reduces the amount of training one needs to operate the Spark at a high level.
When a DP trusts the monitoring path, they stop thinking about the camera and start thinking about the shot.
LOG is really a communication format
This is another point I think often gets overlooked. LOG is not just for the cinematographer.
It is a common language between departments.
Everyone understands what they’re looking at. The image remains flexible. The creative decisions will happen later.
Right now, when Spark exports H.265 or ProRes, the image appears heavily tied to the Pixboom Rec.709 transform.
That means the image has already been interpreted before it reaches post. The more interpretation that gets baked in early, the less flexibility exists later.
A LOG export option would preserve significantly more grading freedom while remaining far easier to manage than CinemaDNG.
In a perfect world we would have a native workflow … Capture, PXBC file, dropped into Davinci that are perceived as a Log image by default while retaining all the bit depth of the linear raw at the control of Davinci, the user then can choose to put a Rec709 transform or other lut onto this while still having complete grading access to all that Raw data in the PXBC file. (emulating how RED does their R3D file with direct editing ability within Davinci)
The real value may be establishing Pixboom Color Science
This is where I think the long-term opportunity exists. Most successful camera companies eventually develop an image philosophy.
ARRI isn’t just known for dynamic range. It’s known for the ARRI look.
RED isn’t just known for resolution. It’s known for RED color science.
Sony has S-Gamut and S-Log.
Canon has Cinema Gamut and C-Log.
The reason these systems matter is because they create consistency. DP’s can move between camera generations and still feel at home.
If Pixboom eventually develops a Pixboom LOG curve and a Pixboom color space, it creates the foundation for a recognizable image pipeline that can extend across future products.
That is much bigger than simply adding another monitoring option.
It is the beginning of a camera ecosystem.
Sensor-based tools and LOG are not mutually exclusive
This is perhaps the most important point….
I don’t think anyone is arguing that exposure tools should rely solely on LOG.
In fact, the most accurate solution is what we have been discussing.
- Exposure analysis driven directly from the linear RAW sensor data. (In-body of the camera)
- Traffic-light style clipping indicators driven from the sensor. (In-body of the camera)
- Goal-post style highlight and shadow recovery indicators driven from the sensor. (In-body of the camera)
- Another option would be to give us a in-camera waveform tool that can toggle between sensor raw data and post lut
At the same time:
- LOG output over HDMI. (External Tools for monitoring)
- LOG output over SDI. (External Tools for monitoring)
- LOG export options for ProRes and H.265. (Greater flexibility in post formats for coloring and matching)
- User LUT support for monitoring. (In-body custom lut support allowing the DP to use his own look on his monitors.)
Those two ideas complement each other.
The exposure tools tell me what the sensor is doing.
The LOG output allows me to view that information using the professional monitoring ecosystem that already exists.
Ultimately, this is about confidence
For me, the biggest benefit isn’t technical.
It’s psychological.
When I’m shooting a once-in-a-lifetime moment at 900+ FPS, I don’t want to wonder whether a highlight is clipping because of the sensor, the monitor, the LUT, or the Rec.709 transform.
I want absolute confidence in what the camera is capturing.
The more clearly the camera separates:
- Sensor data
- Monitoring transforms
- LUTs
- Delivery formats
The more we have reliable tools like this, the more we can stop worrying about the technical capture and use that energy to capture the scene that we’re all here to record.
