massive shift in green color on BMPCC4K

Same results here. Uncorrected BM input profile is weakest greens. Color Checker correction makes greens look better. Film emulation LUT makes greens even more vibrant and nice looking. Note that Provia100 is very "lightweight" LUT that adds very minor correction. So greens are always off.

Here's a quick screen grab. I switched the color space and gamma to Arri in the node and then did a color checker match with Arri set to the source and Rec.709 as the target.

Not sure if I am following the best way to use Log-C but it has been interesting following this thread to get a better idea of working with the Pocket 4K in Resolve.

Color Checker - Arri Log

Screen Shot 2020-05-30 at 12.31.46 PM.png (667.63 KiB) Viewed 20241 times

Here's a quick screen grab. I switched the color space and gamma to Arri in the node and then did a color checker match with Arri set to the source and Rec.709 as the target.

ColorCheckew works way better in wide color spaces and log gamma. So i recommend set source and target to LogC/ArriWide gamut and next do Arri to Rec709 transform with CST node or with Arrii LUT.
In my examples i apply ColorChecker in RedWideGamut/RedLor3g10

Also there are 2 slightly different ColorChecker references. One named as ColorChecker Classic and other as ColorChecker Classic Legacy. Legacy is for ColorCheckers manufactured before Nov 2014. Those had stronger green patches and so "Legacy" produce slightly less vibrant shift to greens.

I suggest you make the switch to Linear space first before you do the transform to arri. I do that in the raw tab. By going linear, you unwide the bmd space to something more neutral and easier for code to understand, in order for the transformation to be more accurate.

I suggest you make the switch to Linear space first before you do the transform to arri. I do that in the raw tab. By going linear, you unwide the bmd space to something more neutral and easier for code to understand, in order for the transformation to be more accurate.

Eugenia, that juanmelara video based on early beta footage from Ursa camera was discussed many years ago. It described rather useless workflow. There is no any benefit if you select linear or LogC or any other gamma/color space different from BMDFilm/BMDFilm in RAW settings. Also BRAW internal transforms work slightly in different way than DNG.
If you use non BMDFilm/BMDFilm settings in RAW, you bypass factory calibration and use basic matrix-based input profile. This method produce weakest possible greens. I provided examples in earlier posts.

BMD film -> ACES -> ACES Transform to Rec709


ACES -> ACES Transform to Rec709

Ok, here are my "Ryobi color" tests under 500W 3200K halogen lamp diffused from white ceiling. WB balanced in RAW.
Seems OLPF/IR filter don't affect greens a lot, but definitely produce better blacks.
3200K warm light render weaker greens, than cooler temperature light from B80 filter.
ColorChecker correction improves colors a lot, but there is still some difference between cool and warm light balanced.
Subjectively on my calibrated but ancient DELL U2311H monitor green color is still far from original, because limited monitor color space. I guess on P3 display it will look "greener" and more vibrant and better match to original.






And same examples but with ColorChecker correction:





And for reference best case scenario with aggressive Fuji Velvia100 film emulation LUT, known for green colors amplification:

In Cinema5D underexposed tests Pocket4K also looks very different to Pocket6K. More IR magenta/less greens.

To me, it looks like left has intense IR pollution going on and right has it filtered, not all of IR but most of it.

Here's a fun one. I couldn't coax any more accuracy from the Melara method. Better gamma curve for sure but it wasn't swinging the vectors one way or another. So.....

What would it look like if you transformed SMPTE bars into Log C gamma/gamut. It would look like this.

709 to Log C.png

You can see what's going on under the hood. If you don't know what you're looking at essentially anything over 584 is going to clip once you apply the Log C transform.

Now what if instead of matching to 709 targets you matched to the Arri Log C targets generated by the Log transform, and then used the Arri transform? You'd get this.

Log C.png

These were all done using only the chart and never looking at the Ryobi box. First 2 no surprises, I took a shot at manual correction, close but with such a loosely defined gamma the colorchecker charts aren't accurate. The last sample is manually matching the P4k Log to Log C then using the Arri transform.

Good Luck

If you look at the white, you can have an idea all colors are going towards some hue, thus making greens also look a bit off. In the last example, where white gets to being white and with a nice contrast, green seems to get to the right spot. Meaning, the workflow is setting everything off a bit, greens following. When you get the correct workflow, greens get where they should too.

The greens take the most hit, because they're more photosites of green on digital sensors than R or B. But the other colors also take a hit when they get squashed into rec709, but the problem there is simply less visible. Basically, Resolve's current out-of-gamut-to-rec709 algorithm makes everything shift towards secondaries. Resolve's algorithm probably is using RGB to do the "fitting" of the out of gamut colors, but it might be smarter to use HSV or HSL to do that transformation internally. For one reason or another, Arri's method works better.

Yep. Compression Wide Color Spaces to to Rec709 may be done many different ways and may provide very different "looks".
Resolve provide options:
BMD CST with Luma/Saturation mapping (with project settings or with CST node)
ACES (with project settings or with ACES Transform node)
REDIPP2 (with project settings or with LUT)
ARRI (with ARRI LUT)

Each large camera company like Sony, Canon, Panasonic, Fuji usually also provides it's own transformation LUTs.

By the way, almost all my tests done with custom made transformation LUTs. I use REDIPP2 based LUT for color space transform to Rec709 and Arri based for gamma transform to Rec709. I shared both those LUTs with example project.

In addition you can create your own custom transformation LUTs with LUTCalc https://cameramanben.github.io/LUTCalc/ ... index.html
Or with DisplayCAL package https://displaycal.net/ Synthetic ICC and 3D LUT maker apps allow to create custom input and output ICC profiles and combine them to LUT with various transformation/compression intents like “Perceptual appearance” or “Relative colorimetric”


Here is full list of ArgyllCMS Rendering intents from DisplayCAL FAQ (many of them are very specific and so i have no idea how to use them in real life):
“Absolute colorimetric” is intended to reproduce colors exactly. Out of gamut colors will be clipped to the closest possible match. The destination whitepoint will be altered to match the source whitepoint if possible, which may get clipped if it is out of gamut.
“Absolute appearance” maps colors from source to destination, trying to match the appearance of colors as closely as possible, but may not exactly map the whitepoint. Out of gamut colors will be clipped to the closest possible match.
“Absolute colorimetric with white point scaling” behaves almost exactly like “Absolute colorimetric”, but will scale the source colorspace down to make sure the source whitepoint isn't clipped.
“Luminance matched appearance” linearly compresses or expands the luminance axis from white to black to match the source to the destination space, while not otherwise altering the gamut, clipping any out of gamut colors to the closest match. The destination whitepoint is not altered to match the source whitepoint.
“Perceptual” uses three-dimensional compression to make the source gamut fit within the destination gamut. As much as possible, clipping is avoided, hues and the overall appearance is maintained. The destination whitepoint is not altered to match the source whitepoint. This intent is useful if the destination gamut is smaller than the source gamut.
“Perceptual appearance” uses three-dimensional compression to make the source gamut fit within the destination gamut. As much as possible, clipping is avoided, hues and the overall appearance is maintained. The destination whitepoint is altered to match the source whitepoint. This intent is useful if the destination gamut is smaller than the source gamut.
“Luminance preserving perceptual” (ArgyllCMS 1.8.3+) uses compression to make the source gamut fit within the destination gamut, but very heavily weights the preservation of the luminance value of the source, which will compromise the preservation of saturation. No contrast enhancement is used if the dynamic range is reduced. This intent may be of use where preserving the tonal distinctions in images is more important than maintaining overall colorfulness or contrast.
“Preserve saturation” uses three-dimensional compression and expansion to try and make the source gamut match the destination gamut, and also favours higher saturation over hue or lightness preservation. The destination whitepoint is not altered to match the source whitepoint.
“Relative colorimetric” is intended to reproduce colors exactly, but relative to the destination whitepoint which will not be altered to match the source whitepoint. Out of gamut colors will be clipped to the closest possible match. This intent is useful if you have calibrated a display to a custom whitepoint that you want to keep.
“Saturation” uses the same basic gamut mapping as “Preserve saturation”, but increases saturation slightly in highly saturated areas of the gamut.

So, at least we came to 1 conclusion so far: its not the camera as stated in the beginning, its the workflow.

Now, Im not an expert, but is reasonable to think that if you need to transform any BMD footage to another manufacturer's color space, it might work ok but probably it is not the best path to follow. Specially on newer generation of color science. BMD develops the camera, BMD develops the grading software and its own internal LUTs and calculations. Nobody better than BMD to know what happens under the hood with its own cameras and software. So the best path should be something within BMD's own colorspace and transformations. As Juan Melara were corrected by Captain Hook, the curve holds all the data. Maybe WE USERS are not knowing how to properly develop it.

It should be easy to settle: advocates of alternate methods supply a braw frame, and a grade of it which offers results superior to what can be achieved through the BMD to rec. 709 workflow.

Comparing one transform to the other, and claiming one is better or more accurate (initially) than the other, pre-grade, doesn't get the prize. Neither do trivial differences, differences which can't be quantified one way or the other, or differences which can be eliminated with simple grading.

Even this test is too lax: nobody's asking advocates to prove the new method doesn't have adverse consequences in this or any number of unanticipated/untested scenarios. But we'll let that go....

If the proposed new method is effective, even in one narrow case, who wouldn't want to know?

So, at least we came to 1 conclusion so far: its not the camera as stated in the beginning, its the workflow.

It is mixed problem. Specific camera sensor + sensor glass + build-in factory calibrated input profile + Color Science version + User Workflow.
If compare different cameras inside similar workflow, BM cameras produce weaker greens than competitors. It was known from the first BM camera. Some people like that basic brownish-greens BM look, some don't.

Now, Im not an expert, but is reasonable to think that if you need to transform any BMD footage to another manufacturer's color space, it might work ok but probably it is not the best path to follow. Specially on newer generation of color science. BMD develops the camera, BMD develops the grading software and its own internal LUTs and calculations. Nobody better than BMD to know what happens under the hood with its own cameras and software. So the best path should be something within BMD's own colorspace and transformations. As Juan Melara were corrected by Captain Hook, the curve holds all the data. Maybe WE USERS are not knowing how to properly develop it.

Not necessary. Color is very subjective. BM Color Science provide rather basic but probably technically "honest" input color. Sort of - ok, our sensor "see" less saturated greens, so let's keep that as it and let user deal with original data. It is not prettify color, it is not attempt to emulate film contrast response. This provides rather boring basic look.
Same time companies with large background of film history see final camera look as state of art, as something mathematically wrong but that looks "better" to human eye and feels more like classic film photography rather than broadcast TV show look.

But again, for me it is really a mystery why Blackmagic goes against color target reference.
Why create so tiny color space for ColorScience Gen4 with insane red channel clipping? By the way Panasonic V Gamut and Sony SGamut have same problems with clipping and oversaturation in different colors because those color spaces also way smaller that original colors captured by sensor.
Why don't use as example larger sized REDWideGamut or CanonWideGamut color spaces that build in the way to capture full sensor color data without clipping?
Also Why don't create better input calibration for DNG/BRAW? It takes few clicks to shoot some color chart target, and create decent input profile.

is reasonable to think that if you need to transform any BMD footage to another manufacturer's color space, it might work ok but probably it is not the best path to follow.

Correct. It's not ideal, it's just the best we got.

Nobody better than BMD to know what happens under the hood with its own cameras and software.

These are different parts of a company, don't ever assume that they speak to one another in the level that you think they do. Sure, there's communication, but don't assume that a BMD software engineer is going to change a 20 year old algorithm that nobody complained about in the past, without some big time DP showing them the error of their ways first. Besides, that rec709 algorithm was written probably 10 years before BMD made their first camera, and it never got updated. Remember, Resolve is a very old app, and its fundamentals might have not been updated.

Maybe WE USERS are not knowing how to properly develop it.

Incorrect. BMD's default method of fitting the out of gamut colors to rec709 results in a shifting of the colors towards secondaries, it's not a user error. The user should not need to do anything more than apply a manufacturer's lut to come to the proper color space with minimal clipping. The BMD lut in conjunction to the internal default algorithm do NOT do that. Arri's and RED's methods do (for their own footage, at least, using their own libraries and not BMD's).

I maintain, with conviction, this is something that Resolve needs to fix. Users should not have to go through hoops to get proper colors. This needs to work out of the box.

I tried two flavors. One a wide gamut Red timeline with a transform node, a linear node, a bonus709 node and a couple other bells and whistles. The other a single vanilla rec709 node. I mostly ended up in the same spot. I'd argue that it is more camera/color science issue and not workflow. There is little separation between the yellow chip and the Ryobi color.

Before I do anything else on color I'm looking to fix that light. The color shift across the frame is a bummer.

I'd suggest using the OPs quicktime as a reference.

widegamma.png (847.57 KiB) Viewed 19763 times

709 solo.png (792.29 KiB) Viewed 19763 times

The color I'm calling Ryobi Green is Pantone 376 C the chip was generated in resolve using the RGB targets 132, 189, 0.

Good Luck

Hmmm - I remember just having to decide between Extachrome or Kodachrome - or maybe Fujifilm.

But again, for me it is really a mystery why Blackmagic goes against color target reference.
Why create so tiny color space for ColorScience Gen4 with insane red channel clipping? By the way Panasonic V Gamut and Sony SGamut have same problems with clipping and oversaturation in different colors because those color spaces also way smaller that original colors captured by sensor.
Why don't use as example larger sized REDWideGamut or CanonWideGamut color spaces that build in the way to capture full sensor color data without clipping?
Also Why don't create better input calibration for DNG/BRAW? It takes few clicks to shoot some color chart target, and create decent input profile.

If you are working on a newer iMac with P3 color space or the newest Apple Display is it an issue with Gen4 color science and Blackmagic Pocket V4 and REC709?

But again, for me it is really a mystery why Blackmagic goes against color target reference.

I wish someone from BMD would either answer your question or explain why it's thoroughly misconceived, but lacking that, consider that we're dealing with a line of inexpensive cameras, bundled with powerful color correction software, and that human visual perception of moving pictures is crude, incapable of distinguishing "real" colors from manufactured ones. That blasted Ryobi box is case in point: who, short of a color picker, would be able to tell the difference between a sensor/processing stream which actually captured it, and a hue adjustment? And who would care, one way the other, in a medium where no color is actually realistic?

How many millions do producers spend, to ensure their movies don't look like reality? And we're growing ulcers worrying about the accurate capture of hues which are going to get color-corrected anyway, into pure fiction?

Most people are here because they do like BMD color.... Low budget kludge or not, it's seems to be working okay. Shoot more, worry less?

But again, for me it is really a mystery why Blackmagic goes against color target reference.
Why create so tiny color space for ColorScience Gen4 with insane red channel clipping? By the way Panasonic V Gamut and Sony SGamut have same problems with clipping and oversaturation in different colors because those color spaces also way smaller that original colors captured by sensor.
Why don't use as example larger sized REDWideGamut or CanonWideGamut color spaces that build in the way to capture full sensor color data without clipping?
Also Why don't create better input calibration for DNG/BRAW? It takes few clicks to shoot some color chart target, and create decent input profile.

If you are working on a newer iMac with P3 color space or the newest Apple Display is it an issue with Gen4 color science and Blackmagic Pocket V4 and REC709?

You should be using a calibrated monitor

And who would care, one way the other, in a medium where no color is actually realistic?

How many millions do producers spend, to ensure their movies don't look like reality?

And most people are here because they do like BMD color.... Low budget kludge or not, it's seems to be working okay.

Both are excuses for an issue.

And who would care, one way the other, in a medium where no color is actually realistic?

How many millions do producers spend, to ensure their movies don't look like reality?

And most people are here because they do like BMD color.... Low budget kludge or not, it's seems to be working okay.

Both are excuses for an issue.

So tell me, which manufacturer offers its consumers objectively real colors? Arri? Red? Kodak or Fuji film?

And we have also yet to establish that Dmitry's analysis is actually correct. It wouldn't be the first time that user misconceptions of how BMD engineering works have led to multi-page wild goose chase threads.

And who would care, one way the other, in a medium where no color is actually realistic?

How many millions do producers spend, to ensure their movies don't look like reality?

And most people are here because they do like BMD color.... Low budget kludge or not, it's seems to be working okay.

Both are excuses for an issue.

So tell me, which manufacturer offers its consumers objectively real colors? Arri? Red? Kodak or Fuji film?

And we have also yet to establish that Dmitry's analysis is actually correct. It wouldn't be the first time that user misconceptions of how BMD engineering works have led to multi-page wild goose chase threads.

That's deflecting.
We're talking about BM cameras in a BM program.

Exactly, and BMD cameras in a BMD program deliver colors many people like, at prices they can afford. It's why dealers can't keep the BMPCC 4K in stock.

What more BMD could do is nothing but speculation at this point. And Red and Arri cost a bit more, as you may have noticed. If you demand that level of performance, the cameras are readily available.

Exactly, and BMD cameras in a BMD program deliver colors many people like, at prices they can afford. It's why dealers can't keep the BMPCC 4K in stock.

What more BMD could do is nothing but speculation at this point. And Red and Arri cost a bit more, as you may have noticed. If you demand that level of performance, the cameras are readily available.

What more could they do?
Have a proper base starting setup in their own program for their own cameras.

"Proper base starting setup" again? Can you honestly say you understand how the camera is meant to work with the software which comes with it?

You might be happier with a camera which shoots straight rec. 709, with lots of internal processing to provide pleasing results. Canon, Panasonic and Fuji have any number of models available.

I guess we just inform BM team that BM cameras can't capture "Ryobi" color. So maybe they fix this gap (as well as red channel clipping problem) in ColorScience Gen5.

I can still remember the days when an early version of Red's codec crashed the camera when aimed at a specific tree in the Southern States, consequently called the "evil tree" by the Red community.

Maybe Ryobi is BM's "evil color"?

On a more serious note, I'd like to remark that no camera with an RGB filtering system will fully agree with human perception of colors. Sony cameras, for example, had those notorious problems with certain blue shades becoming cyan plus very bad differentiation in shades of strong red (a red rose looked always the same). It took them years to arrive at the color quality of the Venice. Red was also improving their color science year after year, and Arri had a lot of help from scientists at the Fraunhofer institute. Arri is still the best at skin color, but not always perfect in the blue/green range.

I can still remember the days when an early version of Red's codec crashed the camera when aimed at a specific tree in the Southern States, consequently called the "evil tree" by the Red community.

I remember when everything was mixed in stereo.

https://encycolorpedia.com/84bd00

First, I am no colorist. Second I have made pictures (even in the time of 35mm film camera's ...) of art, for print. In no way it is realistic to take a camera, shoot, put a standard color correction and expect 100% correct colors. It never was this way, and the bmpcc4K is not an industry grade color calibrated sensor ...

However, my little test below shows the problem is not in the Resolve settings, nor with the camera. It is entirely possible the P4K is not sensitive enough in the greens or whatever, but the info is there. I agree the official LUT for the p4k is not good enough. I compare it with the Jordanwright p4K lut (not trying to push it here, it is the only one I have to compare). The green on the bike is quite close to the ryobi green. You can see what happens (I just dragged it in Resolve, shot outside in the shade, white balance was set to the standard shade setting, no tint shift).

!!!! Somehow I needed to get the size down, I cropped in paint on Windos, but actually, in Resolve the difference is 2-4x bigger between the two LUTs !! This again proves how difficult it is to get matching colors.

Well, if someone can get to the correct colors through CST, than the data is there. Meaning, its not a camera problem. Thats been proved here.

So, the question remains. How should the workflow be? Maybe the expectations of just slapping a LUT and hope everything is ok is wrong? I dont see how a wide gamut camera with a file recorded with high amount of color information should be diminished to a one click solution. Thats my point of view. Not a technical statement

There's no such thing as accurate color.

Accurate colour doesn't exist.

If every camera did accurate colour then every camera would look the same no ? There wouldn't be any difference at all in looks between cameras.

6 cameras on the same colour chart. None of them are the same.

https://www.provideocoalition.com/what- ... ect-color/

You can find a Ryobi green for any camera is the point.

What's insulting though is posters in this thread continuing to insist that it somehow it is possible, despite some pretty detailed and patient explaining of how it's not so simple. Which frankly, means they've not spent time trying to match cameras or spent much time colour correcting and speak from a place of limited actual real world experience.

You are welcome to say that greens suck on BMD cameras. But that also says you're also not prepared to to do any post work at all, which you'd have to do in some form or another with every camera out there with whatever equivalent that camera has to ryobi green.

You're welcome to say that you think the default workflow produces greens you dislike.

If you've done any colour correction work at all, you also would know that when you make corrections these are often by reducing other tones. And so therefore if you're chasing a tone that's now "reduced" then the blues or cyans long knives team come out ?

Here's the same conversation with the same issues on another forum around a panasonic camera and the colour red.

http://www.dvxuser.com/V6/showthread.ph ... he-new-Red

Does anyone think a P4K can't get to within 1% of the right colour Ryobi green though some actual manual colour correction ?

The issue at hand is really about doing it in "auto" mode, not if it can hit that tone.

Which is fine. Go make a poll that demands for BMD to address the issue of their default workflow and "look"

JB

It is my personal speculation, but it could be just a BM subjective preference to use warmer greens because this color shift is better for skintones.
Same situation was in consumer photography film stocks. Fuji films produced more vibrant greens, because their "calibration target" was bronzed asian skintones. But Kodak film stocks produced more warmer colors and less "acid" greens because "calibration target" was lighter european skintones.

By the way, this is example of Panasonic color space clipping problem similar to red channel clipping in BM ColorScience Gen4. I hear that Panasonic fixed that problem in updates. This is all due too tiny unified input color space developed by manufacturers compare to native huge sensor color space.

By the way, this is example of Panasonic color space clipping problem similar to red channel clipping in BM ColorScience Gen4. I hear that Panasonic fixed that problem in updates. This is all due not large enough unified input color space selected by manufacturers compare to native huge sensor color space.

Dimitry, I still have color science gen 3 on my Ursa Mini 4.6K. Shot this time with an SLR Magic 50mm APO. You can take a look at the raw file if you want: https://we.tl/t-542rGY0bYk

Gen 3 Ursa Mini 4.6K

ursa-mini-gen-3.jpg (573.39 KiB) Viewed 19555 times

If you flip back and forth between the two it is pretty interesting to see the changes Greens are more subdued in GEN 4. BTW I like GEN 4 for skin tones, if I had to shoot products all day I might prefer GEN 3.

It is my personal speculation, but it could be just a BM subjective preference to use warmer greens because this color shift is better for skintones.

This is another way of agreeing with what I was saying.

If you adjust a perceived problem in one direction, it will no doubt create another issue in another part of the spectrum as these choices are all subjective.

As some have learned, there's no LUT to rule them all. There's no grade that works for everything.

JB

If you adjust a perceived problem in one direction, it will no doubt create another issue in another part of the spectrum as these choices are all subjective.

Shifting primaries into secondaries is not subjective, it's measurable (particularly for the engineers of Resolve who have hardware tools to do so). All Luts do is shift the problem. To fix problem in its root requires Resolve change its remapping algorithms. Because there IS a problem.

Can we see actual proof BMD engeneers dont know what they are doing and leave the endless realm of assumptions?

Any kind of color matrix is a compromise in one direction or the other. As I already wrote, Arri is very carefully aiming at skin tones (and still famous for that) and they also have to accept some weaknesses in other color ranges. Every manufacturer has different biases based on assumptions about the preferences of the target audience (and maybe even the personal taste of the CEO).

It was never different in the history of movies, every opto-chemical color film stock had a specific look to its colors, and directors and DoPs were choosing based on the subject and their preferences. There was a Kodak look, and a Fuji look, and an Agfa look (not even to mention color separation processes). So, no need to bash a single camera manufacturer for their specific decisions, you can have your choice with digital too. But don't expect perfection!

Near-perfect color reproduction would need dozens of color channels per pixel. In consequence, cameras would be financially inaccessible and have very low light sensitivity. So, for me, it's this: Live with what you can get and grade accordingly. Period.

If you adjust a perceived problem in one direction, it will no doubt create another issue in another part of the spectrum as these choices are all subjective.

Shifting primaries into secondaries is not subjective, it's measurable (particularly for the engineers of Resolve who have hardware tools to do so). All Luts do is shift the problem. To fix problem in its root requires Resolve change its remapping algorithms. Because there IS a problem.

Buzz off already. I learned everything I needed to learn about collage about 40 years ago but I'd never presume to tell you your business. Perhaps you extend the same courtesy and assume the BM engineers have a clue.

Good Luck

Buzz off already. I learned everything I needed to learn about collage about 40 years ago but I'd never presume to tell you your business. Perhaps you extend the same courtesy and assume the BM engineers have a clue.

My business? I was a computer programmer for 10 years, working in London, which I left behind due to health issues. I only turned to visual arts afterwards. So your super-aggressive, belittling reply is not needed in a civilized discussion. In my experience with software architecture, there is an obvious issue in Resolve in the way it interprets out of gamut -> rec709. This is not about the Resolve engineers not knowing their job, but mostly an issue of presumably very old code that hasn't been updated for the realities of modern sensors. Code that seemingly works, very rarely you touch. But the time has come to rethink that piece of code.

Ignorance is bliss.

<Harp Swells>

Good Luck

Buzz off already. I learned everything I needed to learn about collage about 40 years ago but I'd never presume to tell you your business. Perhaps you extend the same courtesy and assume the BM engineers have a clue.

My business? I was a computer programmer for 10 years, working in London, which I left behind due to health issues. I only turned to visual arts afterwards. So your super-aggressive, belittling reply is not needed in a civilized discussion. In my experience with software architecture, there is an obvious issue in Resolve in the way it interprets out of gamut -> rec709. This is not about the Resolve engineers not knowing their job, but mostly an issue of presumably very old code that hasn't been updated for the realities of modern sensors. Code that seemingly works, very rarely you touch. But the time has come to rethink that piece of code.

With the greatest respect to your computer programing expertise - in the absence of a full set of input data this statement is pure speculation.

The only real argument in the end is the end product, the footage. The differences between cameras is already vanishingly small. An Alexa in the hands of a no-budget filmmaker won't make a better movie than a BMPCC 4K in the same hands, and it's not even obvious that the Alexa would survive a bind test among most people in this business.

No idea how many people here are actually engaged in narrative filmmaking, but in order of ranked irrational priorities, the camera is variably first, where it should probably be last.

To this day, the best shot/looking no budget (<$50,000) color movie ever made was shot on a GH2.

Unless somebody's claiming the BMPCC 4K produces ungradeable crap images compared to some other comparable camera, or even the industry standard, what are we arguing about?

Upstream Color? What was shot on a gh2?

Actually, it was Godfather 3.5; Francis went out and bought one right after the Zacuto demo.

Kidding aside, yes, Upstream Color gets my vote, including all the ultra-low budget 16mm color features from the 80s and 90s, "Return of the Secaucus Seven", "The Brothers McMullen", "El Mariachi", and dozens more, often at much higher budgets.

Now, if only it made more sense....

There are some sites running aroung the interwebs with Primer at a 1.04:1 shooting ratio. That would mean he shot 80 minutes total. It's basically impossible without editing the entire film in camera which I propose is the next oner. The creation of the modern myth.

Good luck

I'd say that the best looking microbudget movie is Cosmos, 2019. Shot on an original BMPCC, edited/graded in FCP and Premiere. This is a mini-Spielbergian film, shot for just $8000. They had great success with it (for a no budget), their DVD/BDs went out of stock multiple times. Only thing it needed was a tighter cut. It's currently free to watch on Amazon Prime or Tubi TV.

Something we agree on. Cosmos was 45 minutes too long and there was a sequence of pushes at the end that had to be an inside joke. Beyond that I'm floored how good the Pocket looked in those conditions.

Upstream Color is probably worth a (re)rewatch, I was too busy trying to figure out if the worms were in the pork figuratively or literally.

I'm going with Blue Ruin, no muss, no fuss, revenge story told correctly, Canon C300 I believe.

Good Luck

Blue Ruin was made by an independently wealthy filmmaker -- budget was several hundred thousand. Not really comparable to Upstream Color, though I'd still stick with the latter, if we have to pick between them. But we're going far afield here....