@troy_s most of the footage is from an fs7, a bit noisy... I'm getting good results though with natron using the PIK keyer, which allows you to synthetize some of the occluded background (like using the inpaint node) to preserve the detail on the edges of hair.
No, I'm still at 3.1.7.3. I only just got to update my nvidia drivers so I can run two profiles(two monitors - something about argyll needing to be updated, which it has been now). :/ Are there problems now with DisplayCAL 3.2 ?
@troy_s hi. When emailing with Greg Zaal I told him about the add-on for measuring the dynamic range
@troy_s he said "About measuring dynamic range - that add-on is nice, but not practical, since it doesn't take into account the amount of noise that the dark areas have. "
@troy_s and ..."A better method is to know how much dynamic range the camera captures in a single shot at a certain ISO (DXOmark has data for this), and add this to the dynamic range you capture with exposure bracketing. But then you can only know this if you know how it was captured, no one can calculate it afterwards. So for now the EV number I post on my site is purely the exposure bracketing (e.g. 1/4000 to 1" is 12 EVs)". What do you think of this ?
@OldMan In practical sense sure, there is a noise floor. Cameras though offset the noise floor upwards. The variation is going to be rather negligible, and the math is the math. Whether or not you agree with it is sideways, the values are the values.
@OldMan Either you acknowledge that whether you believe it or not, every pixel emits, noise and otherwise, and that is part of the emission.
@OldMan Anyways, it isn't something I would obsess with, nor would I obsess with the dynamic range; it just doesn't matter if the HDRI is mangled, and most are. Even Zaal's ratios are off in many of them. Maxime's seem a little more accurate, but the bottom line is that most accurate HDRIs cost a lot of money for good reason.
@OldMan He is also a little off on his comment as technically the full range of a camera sensor isn't recording accurate data, as the toe and shoulder are nonlinear. But again, it is quibbling over what amounts to nothingness.
Assuming the HDRI is accurate (again, most aren't) the dynamic range in the hottest pixels versus the lowest pixels should be out of the noise floor or shoulder range, and in the end, those pixels whether you agree or not, are part of the CGI dynamic range.
The rendering engine doesn't give a shit what you think; it renders with those values.
Clarkvision has some good discussions about noise.
It isn't nearly as straightforward as Zaal suggests.
(I learned this by helping a team work on a camera)
Anyways, not something I really care about. The dynamic range of the values is the dynamic range of the values, noise or not. Is it the actual scene's dynamic range? Well if you ask that, eventually you are going to realize that the scene itself has an infinite dynamic range towards zero.
So moot point really.
If you want to obsess about it, feel free to apply a low pass median filter to average out those low values.
@oblomov No. Just a few questions about the newer UI if you had used it.
@troy_s I'm going through your last message regarding the color profiling of the monitors. From what I can tell, setting up the wide gamut displays will be a challenge. I'll need some time tomorrow to gather the information required: The monitors I basically received as a bounty from our print department. They were replacing those displays after two years, and I simply grabed them so finally the 3D visualisation would have monitors that deserve the name.
@troy_s That's why I need to dig backwards in history to figure what models we have exactly, and then I'll be able to provide details.
@aliasguru The thing that throws me is why you were getting whacked colours on the wide gamut, which suggests maybe it was being profiled in a wide gamut mode?
@troy_s the screenshots I sent yesterday were taken on my machine at home, not on the wide gamut ones. However, the behavior is similar
@troy_s I rather think we either do something wrong when generating the 3D LUTs or when defining the look in ocio.conf. But We'll know more when I start testing your advise on the "real" machines.
@aliasguru Your process is fine, plus or minus. The expectations are the curious part.
@aliasguru The Filmic set will never of course deliver sRGB ratios. Just won't happen. But if we know the constraints better (vendor requests particular xyY value for example) then it is easier to sculpt out a solution.
@troy_s I was hoping that I could combine the profiling I do with my monitor (whereever, home or work) with the filmic presets. That the colors differ from sRGB standard is clear to me. I just want to make sure that on the display end I do see the tonalities I should see, that's all
@troy_s and regarding the Wide Gamut, I'd love to get it to work finally. Feels a bit cheesy to run them in sRGB mode.
@troy_s The KTM orange by the way is a tricky thing: The color was redefined only a few years ago. KTM has always been orange, but the hue has changed. That would not be such a bad thing, but: The look our CT guys were after was called "Neon Orange".
So they chose paint types which really have this strong kind of neon effect. It was shown on a bike a few years ago on a fair in Milano. Hundreds of journalists took images. Not a single photo was even close to represent the color. All of them turned out brown. It's impossible to shoot a proper image!
@aliasguru (Remember a photo is basically a raster baked RGB version of a wavelength model scene. So even if your photographers know what they are doing (uh...) the chances the colour is captured as one experienced it in the scene at the psychological level is low.
@oblomov Just did some deep thinking on what to set as an input curve. I'm pretty much certain that the "idealized" input colours would be 709 lights with a 2.2 power curve.
(Because display hardware isn't sRGB on the transfer side in most instances. I believe at the low level hardware baked in level, they hack the 2.2 curve onto an otherwise linearized output of LCD.)
@troy_s I might try it on Friday if I have some time. I'm supposed to be making a Christmas card image this week too. I left it rather late this year . . .
That would be really helpful. Nothing worse than finding the tutorial doesn't match the application :/ I do hate that they keep moving thing around. It's fine if it's an 'improvement'. But when would I differentiate between sRGB and Rec709? Shouldn't they give the same end result, or would it matter for different hardware?
@oblomov It is part of the "real" world I suppose. Those sorts of seemingly minor decisions cascade.
I'm sort of already facing this with the Filmic set as studios adopt them; I can't just willy-nilly push changes that I feel like without considering how that will barf up the studio.
@oblomov Your sRGB / 709 question is a great one, and one that requires nuance to even ask.
REC.709, in terms of the OETF and EOTF, are strictly for encoding video footage. That's it.
sRGB borrowed the lights, and changed the OETF / EOTF to sRGB's.
(Because again, REC.709 was never designed to ever be viewed. Later, BT.1886 finally answered that question)
@oblomov When calibrating for Blender work, what you are seeing is really Blender dumping raw sRGB (or whatever) to your 2.2 display.
So profiling against 2.2 makes the most sense, as that will try to match the expected against what you get.
The flip side, using the sRGB curve, means things are a bit more turnkey and the image is pretty much sRGB. What you will notice is some slight shifting in the intensity in the shadows if you tag it as sRGB and view it as sRGB in a proper colour managed system, but very slight.
The theoretical "perfect" would be:
1) Profile against a 2.2 curve that matches your display.
2) Work.
3) When you are finished, convert the image using ICCs from sRGB with 2.2 to sRGB proper.
That would make the result perfectly 1:1, with the added cost of a conversion there via ImageMagick.
