bepeg4d wrote:hi, i have already asked for this feature some time ago but none was interested, good to know that there is someone else that need this, it would be the perfect gift for the camera imager node, so +1
ciao beppe
Hi beppe, I have also requested scopes in Octane, in particular, the Waveform Scope. The waveform scope is an industry standard image-monitoring tool in cinematography. The photography (still camera) industry is behind and still stuck using the limited Histogram which is not actively being used in any cinematography on-set production or CGI productions/VFX post-productions. It is worth to mention that even Affinity (Photo) has a waveform, but its GUI implementation is limiting its usage.
Jaybee wrote:Yep it's pretty important if you are going to colour grade the image in post! I work with lots of photographic textures so I need to know I'm not rendering out 255 RGB in any one channel else I have nowhere to go in post to recover that lost data.
The "data" (scene-light values) is only "lost" (clipped) when previewing the rendered image via the Octane Render View that uses the default built-in color management (highly not recommended).
If the rendered image from Octane is exported as an OpenEXR file, preferably 16-bit (as 32 is overkill for beauty/non-data AOVs), without the "Tone Map" checkbox/option (I mentioned this detail here
https://www.elsksa.me/blog/cgi-color-management-survival-kit, search via CTR+F: "Avoiding any pre-image-processing prior EXR export" but I recommend reading the whole content), in post-production, the linear-scene-referred high dynamic range data is
preserved.
TL;DR, the sRGB standard OETF/EOTF (what you would likely know as "gamma curve/correction") used by default are not appropriate transfer functions for display-referred output tone-mapping from (very) high dynamic range linear-scene-referred image files and have never been designed for it.
The lack of advanced color image processing results in awful imagery produced without a proper and advanced tone-mapping solution (using OCIO, using some plugins/gizmo in post/compositing, directly in the non-linear digital intermediate grading system or, as rarely seen, custom solutions for high budget productions).
it is crucial to not affect the lighting based on the default built-in color management and default Camera Imager Exposure value as it is pushing the end-user to set non-plausible light values.
mib2berlin wrote:Where is the Histogram button here
Despite the original sarcastic intent, film directors of photography or still-photographers are (still) using light reflectance/incident meters.
Charliegoulet wrote:I would love one tooo! I can't tell if I'm blowing out my highlights
As mentioned in my response to "Jaybee", you are not blowing any highlights when rendering or exporting an EXR file. You are only blowing out when preview the rasterized rendered image using the default sRGB color management.
trogers wrote: Is there any histogram clipping view functionality in the current 2020.2 products? I'd love to be able to see these details before I export, especially to dial in my highlights without blowing them over. I'd love to hear any other tricks as work-arounds as well if this feature is not implemented.
Yes and no.
No: not built-in.
Yes: externally, via OCIO. Filmic by Troy Sobotka that works outside Blender3D, includes, via OCIO Looks which are supported in Octane, a "False Color", I mention it here:
https://www.elsksa.me/blog/octane-color-management.
Whenever a waveform monitor/scope is not available, in cinematography, the False Color is the handy solution, if available. It is a color-coded “heat map” of your image values, according to code table provided in the link below.
Download it here (free)
https://sobotka.github.io/filmic-blender.
Filmic is nothing specific to Blender3D and can be used anywhere OCIO is supported, despite some applications having questionable OCIO implementation, most of them should not cause any problem, especially not Octane which has been supporting OCIO properly since the beginning (thank you OTOY devs and @karu in particular).
BLKRCAT wrote:Actually I've always wondered if something like this was possible. Would be super useful to see exactly where the white points are and what's clipping in a 32bit linear colorspace.
As mentioned in my response to "Jaybee" 16-bit for exported beauty renders as OpenEXR, is the standard.
16-bit floating-point color component values are half values have 1 sign bit, 5 exponent bits, and 10 mantissa bits. For linear images, it provides 1024 (210) values per color component per f-stop, and 30 f-stops (25 - 2), with an additional 10 f-stops with reduced precision at the low end (denormals), are the ILM specifications of the 16-bit OpenEXR file format (the authors of it, with the contribution of other studios). OpenEXR is the solid and reliable industry standard high dynamic range file format (unlike the others) used in both digital cinematography and VFX/CGI. I shared more details about OpenEXR features here:
https://www.elsksa.me/blog/the-unawareness-of-png-and-exr.
If anything goes wrong in the imagery, it is surely coming from wrong/incorrect color management/image processing.
It is worth to mention that "linear" is not a color space. You can find more information in my blog-post:
https://www.elsksa.me/blog/understandin ... al-imagery and more details will be added in the near future.
Best,
ELSKSA