A good example ist the waveform of Final Cut Pro X, it has color information merged into the luma based waveform. You can watch it here at minute 3:10 youtube

Above (top right) is an early crude waveform produced from data from the Axiom Beta. The larger waveform is from a recording at 1080p as viewed on DaVinci Resolve, which includes the Axiom Beta overlay.

I will have a look at that christophvarga.

Here is the final cut version if you are interested

could you post a screenshot of an example where whitebalance is almost correct? i would be interested how that looks like.

someone at natron.fr is probably also working on an waveform monitor https://forum.natron.fr/t/luma-waveform-display-using-shadertoy/985

hello do we have IRC for apertus for gsoc's 2017 projects?

Yes, we have IRC, it is on #apertus @ irc.freenode.
Just join there and ask if you need anything.

Best,
Herbert

the waveform and vectorscope feature requests are long outstanding wishes.

recently natron saw some important improvements concerning the viewer and more complex groups handling different color spaces / RRTs / ODTs in viewers and scopes. that was a required prerequisite fore more useful scopes, because this kind of metering tools do not make much sense without an adequate translation from the internal linear data representation to more common display referred standards.

i would suggest to utilize arryfire and it's very fast GPU accelerated histogram routines in the actual implementation.

@mash: while that is a good idea for cutting/post software, this is not an option for the AXIOM Beta as there is no GPU to accelerate anything.

Nevertheless, part of the image analysis and probably most of the result display can be done in the FPGA directly on the image data-streams.

Best,
Herbert

In T734#11374, @Bertl wrote:

@mash: while that is a good idea for cutting/post software, this is not an option for the AXIOM Beta as there is no GPU to accelerate anything.

yes -- you are right!
i didn't think about this constraints of an implementation on the camera -- sorry!

but the arrayfire hint could be still useful for colleagues interested in this topic, because it's using a platform neutral modularization for this kind of performance critical tasks. the same code will use available acceleration by CUDA or OpenCL, but will also run in multiple threads or single threaded just on a CPU. and it's IMHO really recommendable to utilize well optimized libraries like this for histogram calculation, because it's not trivial to do it better by writing it from scratch.

in case of an in camera implementation, i would also abstain from more precise color transformations or messurement values translated to e.g. rec709 levels / IRE etc. this doesn't make much sense on a RAW camera and would only degrade the performance. simple histograms and waveform representations of the RAW sensor values or their logarithmic equivalent are more useful in this case to control exposure and the clipping of channels. a vectorscope doesn't make much sense under this circumstances neither.

Correct cmv_hist3 link: https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/cmv_tools/cmv_hist3

In T734#17428, @BAndiT1983 wrote:

@eppisai Was trying to answer your questions on IRC, but you weren't online. There is little reason to place a cartesian plane in the painter, as the purposes are different, it's more or less about "single responsibility". It would be better to create a base class for the graph widgets, e.g. BaseGraph, and then derive different graphs from it.

ohk... Thanks!