Features wanted: Vectorscope and Waveform

[devernay]

From @devernay on August 4, 2014 17:15

As in broadcast tools. Helps a lot for color grading/matching. Waveform could be horizontal or vertical.

Copied from original issue: MrKepzie/Natron#154

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/57502133-features-wanted-vectorscope-and-waveform?utm_campaign=plugin&utm_content=tracker%2F83915136&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F83915136&utm_medium=issues&utm_source=github).

[devernay]

From @blackearth2014 on August 4, 2014 19:4

I think the waveform should be Horizontal if space allows.

[devernay]

From @blackearth2014 on August 5, 2014 15:48

Will the Waveform and Vector-Scopes be Hardware GPU driven?

[devernay]

From @MrKepzie on August 5, 2014 22:49

I don't think so because since the images in Natron are already on the CPU, copying them to the GPU to process them wouldn't make a big difference than just computing them on the CPU.

[devernay]

From @blackearth2014 on August 5, 2014 23:12

If that is the case, why are so many visual VFX software companies are coding their compositing software to be GPU excelled? Or is it just the scopes that doesn't make a diference?

This is your season Omar Brown Blessed House Media

On Aug 5, 2014, at 6:49 PM, Alexandre Gauthier notifications@github.com wrote:

I don't think so because since the images in Natron are already on the CPU, copying them to the GPU to process them wouldn't make a big difference than just computing them on the CPU.

— Reply to this email directly or view it on GitHub.

[devernay]

From @MrKepzie on August 5, 2014 23:28

It just doesn't make a difference for the scopes, because you're already giving it in input something that's originated from the CPU, plus a vectorscope and a waveform are not heavy processing, there are mainly copy of chunks of memory which the CPU does very well.

Now for an effect plug-in this is a complete different thing, it can do heavy processing and for this the GPU is better. Bear in mind that when you do something in the GPU there needs to be a copy of the image from the CPU to the GPU and then from the GPU to the CPU when it's done. In other words, you better have the GPU do something that is worth the transfer back&forth otherwise this is just a waste of time and energy for the developer

On Aug 5, 2014, at 4:12 PM, Omar Brown notifications@github.com wrote:

If that is the case, why are so many visual VFX software companies are coding their compositing software to be GPU excelled? Or is it just the scopes that doesn't make a diference?

This is your season Omar Brown Blessed House Media

On Aug 5, 2014, at 6:49 PM, Alexandre Gauthier notifications@github.com wrote:

I don't think so because since the images in Natron are already on the CPU, copying them to the GPU to process them wouldn't make a big difference than just computing them on the CPU.

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

[devernay]

From @blackearth2014 on August 5, 2014 23:35

This is the best explaination anyone has giving me on the subject. Thanks.

I hope and pray that Siggraph will help Natron blow up.

One more thing, were you able to read the information about exporting blender tracking information in to natron by using the import/export .chan format?

This is your season Omar Brown Blessed House Media

On Aug 5, 2014, at 7:28 PM, Alexandre Gauthier notifications@github.com wrote:

It just doesn't make a difference for the scopes, because you're already giving it in input something that's originated from the CPU, plus a vectorscope and a waveform are not heavy processing, there are mainly copy of chunks of memory which the CPU does very well.

Now for an effect plug-in this is a complete different thing, it can do heavy processing and for this the GPU is better. Bear in mind that when you do something in the GPU there needs to be a copy of the image from the CPU to the GPU and then from the GPU to the CPU when it's done. In other words, you better have the GPU do something that is worth the transfer back&forth otherwise this is just a waste of time and energy for the developer

On Aug 5, 2014, at 4:12 PM, Omar Brown notifications@github.com wrote:

If that is the case, why are so many visual VFX software companies are coding their compositing software to be GPU excelled? Or is it just the scopes that doesn't make a diference?

This is your season Omar Brown Blessed House Media

On Aug 5, 2014, at 6:49 PM, Alexandre Gauthier notifications@github.com wrote:

I don't think so because since the images in Natron are already on the CPU, copying them to the GPU to process them wouldn't make a big difference than just computing them on the CPU.

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[devernay]

From @MrKepzie on August 5, 2014 23:42

Yup I gave it a look, we need to talk about it and also talk to blender devs before doing anything. Thanks for the effort and infos

[devernay]

From @blackearth2014 on August 6, 2014 0:31

Cool Breeze.

This is your season Omar Brown Blessed House Media

On Aug 5, 2014, at 7:42 PM, Alexandre Gauthier notifications@github.com wrote:

Yup I gave it a look, we need to talk about it and also talk to blender devs before doing anything. Thanks for the effort and infos

— Reply to this email directly or view it on GitHub.

[devernay]

From @mifth on August 6, 2014 6:43

I think most stuff should be on gpu. for example, Krita has gpu and cpu canvas. gpu canvas works 10 times faster.

could you contact to krita devs in irc to discuss what‘s better to store on gpu/cpu? their irc is #krita.

One mistake can kill performance.

[devernay]

From @MrKepzie on August 6, 2014 15:0

Don't worry we have the background to make proper things on the gpu.

On Aug 5, 2014, at 11:43 PM, mifth notifications@github.com wrote:

I think most stuff should be on gpu. for example, Krita has gpu and cpu canvas. gpu canvas works 10 times faster.

could you contact to krita devs in irc to discuss what‘s better to store on gpu/cpu? their irc is #krita.

One mistake can kill performance.

— Reply to this email directly or view it on GitHub.

[devernay]

From @mifth on August 6, 2014 15:54

Great :)

Also, will it be possible to move color correction and other image manipulations to GPU? Like, Hue/Saturation, RGBALUTOFX, Roto etc.. I mean Natron OFX Misc tools.

[devernay]

From @Tangofish on October 24, 2014 22:1

I would also like to request some scopes & real time analysis tools. For me the essentials are the Waveform (Mono color, RGB parade / parade overlay) and a Histogram with RGB overlays. I'm going to step out on a limb here, for correction and grading of digital RGB sources, I much prefer to use RGB overlapping Histograms. When analyzing a monochromatic target (with a range of stepped values) that has been filmed, RGB separations that may or may not appear on the histogram tell you right away the tonal ranges where the white balance has deviated from theoretical true white. IMHO.

[devernay]

From @MrKepzie on October 24, 2014 22:17

There’s already an histogram tool in Natron, you can create one in the menu that appears when clicking the “Manage layout for this pane” on the top left of every pane of the application.

On 25 Oct 2014, at 00:01, Tangofish notifications@github.com wrote:

I would also like to request some scopes & real time analysis tools. For me the essentials are the Waveform (Mono color, RGB parade / parade overlay) and a Histogram with RGB overlays. I'm going to step out on a limb here, for correction and grading of digital RGB sources, I much prefer to use RGB overlapping Histograms. When analyzing a monochromatic target (with a range of stepped values) that has been filmed, RGB separations that may or may not appear on the histogram tell you right away the tonal ranges where the white balance has deviated from theoretical true white. IMHO.

— Reply to this email directly or view it on GitHub https://github.com/MrKepzie/Natron/issues/154#issuecomment-60455325.

[devernay]

From @Tangofish on October 25, 2014 9:54

Well, yes, indeed there it is, and it is possible to have more than one open, very nice. I'm happy to see the ROI works well too (was request #10 back in February) I would like to make a few additional suggestions: • Ability to Add/Name/Remove custom graticule lines (vertical or horizontal) and boxes. Optionally, cross-hair points might be nice for some people too. It would be very nice to be able to load and save and load them too. Maybe If more than one Histogram was open, they would display the same in all? • Ability to use the AYRGB shortcut keys to switch the display mode. • Ability to sync the zoom and pan of one histogram viewer to another (when more than one was open) • Ability to zoom/stretch the display Horizontally or vertically, useful when trying to analyze very small tonal ranges. Perhaps "1:1 aspect" could be a menu drop down check option with a keyboard short cut. activating it you could toggle between 1:1 (normal) and the last set stretch view. • Ability to Zoom or "Home" the histogram to the ROI when it is active, (perhaps with the f key, or shift f?) • Ability to change the units on the Graticule (yes sometimes it can be nice to read 0-255) • Optional: The ability to change the Major/Mid/Minor units along with it the graticule brightness/colourr. this would be nice, Natron is very usable as it is. • Optional: To be able to use keyboard shortcuts 1 and 2, 3... to change the viewer input. • Optional: Double clicking a Viewer in the node graph automatically changes the current Histogram Viewer target. Thank you again for you super speedy response!

[devernay]

From @MrKepzie on October 25, 2014 12:55

F key already set the histogram to display the [0 - 1] range (or 0 - 255 if your prefer) For all other shortcuts, we could add them indeed, we didn’t have much feature request about it before;)

On 25 Oct 2014, at 11:54, Tangofish notifications@github.com wrote:

Well, yes, indeed there it is, and it is possible to have more than one open, very nice. I'm happy to see the ROI works well too (was request #10 https://github.com/MrKepzie/Natron/issues/10 back in February) I would like to make a few additional suggestions: • Ability to Add/Name/Remove custom graticule lines (vertical or horizontal) and boxes. Optionally, cross-hair points might be nice for some people too. It would be very nice to be able to load and save and load them too. Maybe If more than one Histogram was open, they would display the same in all? • Ability to use the AYRGB shortcut keys to switch the display mode. • Ability to sync the zoom and pan of one histogram viewer to another (when more than one was open) • Ability to zoom/stretch the display Horizontally or vertically, useful when trying to analyze very small tonal ranges. Perhaps "1:1 aspect" could be a menu drop down check option with a keyboard short cut. activating it you could toggle between 1:1 (normal) and the last set stretch view. • Ability to Zoom or "Home" the histogram to the ROI when it is active, (perhaps with the f key, or shift f?) • Ability to change the units on the Graticule (yes sometimes it can be nice to read 0-255) • Optional: The ability to change the Major/Mid/Minor units along with it the graticule brightness/colourr. this would be nice, Natron is very usable as it is. • Optional: To be able to use keyboard shortcuts 1 and 2, 3... to change the viewer input. • Optional: Double clicking a Viewer in the node graph automatically changes the current Histogram Viewer target. Thank you again for you super speedy response!

— Reply to this email directly or view it on GitHub https://github.com/MrKepzie/Natron/issues/154#issuecomment-60477638.

[devernay]

From @Tangofish on October 25, 2014 14:51

Thanks for taking the time to consider such requests. For colour correction, it's really important to be able to compare histograms from different frames to each other. Lines and cross hairs help with this. Keyboard shortcuts will allow for quick "A/B" comparisons. Being able to draw a box can help with establishing gamut limits for output.

Pie in the sky, if we were able to take a "snapshot" of some frame's histogram, and compare that to while on some other frame, then that would be something magical!

Best.

[devernay]

From @blackearth2014 on October 25, 2014 15:16

Tango,

You are going all out with the color grading requests. I like it. Autodesk smoke doesn't have those requested features.

This is your season Omar Brown Blessed House Media

On Oct 25, 2014, at 10:51 AM, Tangofish notifications@github.com wrote:

Thanks for taking the time to consider such requests. For colour correction, it's really important to be able to compare histograms from different frames to each other. Lines and cross hairs help with this. Keyboard shortcuts will allow for quick "A/B" comparisons. Being able to draw a box can help with establishing gamut limits for output.

Pie in the sky, if we were able to take a "snapshot" of some frame's histogram, and compare that to while on some other frame, then that would be something magical!

Best.

— Reply to this email directly or view it on GitHub.=

[devernay]

From @Tangofish on October 25, 2014 15:28

Thanks Omar, Sometimes I have to draw on my monitor with a dry erase marker :( Together we need to end the dark days of colour grading :)

[devernay]

From @Rio on December 24, 2014 12:5

Another +1 for waveforms (parade/overlay) and vectorscopes. Will look into it myself if I can get my C++ skills up to speed. Nice 1.0 release btw, contratulations!

[devernay]

From @mash-graz on March 29, 2016 0:20

this is a very old feature request, but it's still missing for daily work. color related corrections do make much sens without useful measurements.

[devernay]

From @sobotka on May 19, 2016 15:27

@mash-graz A vectorscope is extremely challenging to code in the modern era as it requires knowing the chromaticity of the encoded YCbCr stream, and even then, it would take a good deal of thought as to how to implement a fully colour managed solution via OCIO. RGB data as well would require being chromaticity aware to locate the data in relation to the RGB positions on the scope.

A waveform is equally challenging. Is the data scene referred or display referred? Are broadcast levels markings correct given the sources? Etc.

So while both of these things are rather trivial to implement incorrectly, which would break and be misleading for a huge chunk of contexts, they are extremely challenging to implement correctly across all of the ingestion media.

[devernay]

From @mash-graz on May 19, 2016 16:48

yes -- i have to agree! :)

i studied the code of the actual histogram implementation in natron and -- like often, when i try to understand the code of natron -- i was really impressed. it's far beyond the level of programming i'm able to do myself. but i'm still very interested in this specific feature, because i'm using nuke and natron quite often to analyze video material and do some color related development (e.g.my ACES profiles for the GH4 video profiles).

OCIO support and integration into the natron viewer would be the most desirable solution, but i could also accept a more simple openFX node, which has to be chained after an OCIO transformation node. a solution, which just transforms an incoming rec709/linear RGB picture to a waveform/vectorscope image. but it has to be really fast an efficent, otherwise it does not make much sense. compute shaders to gather the data and vertex + fragment shades for the final drawing to frame buffers look like the most promising way to archive this goal.

but i'm still very confused, how this kind of OpenGL usage should be implemented in a natron extension in the most efficient and compatible way? i did take a look into the shadertoy and OpenGL / osmesa examples in the test section of openfx-misc, but it's a burdensome challenge to grasp this topics...

[devernay]

From @MrKepzie on May 19, 2016 17:8

On OpenFX side (plug-ins) we use osmesa to implement OpenGL plug-ins. Basically, with osmesa we can have the same code that does CPU rendering and GPU rendering using the same OpenGL calls. When running on CPU, shaders are compiled with llvm and very efficient.

Currently Natron, does not support OpenGL plug-in renders, hence OpenFX plug-ins will always receive images on the CPU before rendering and will have to render back to the CPU. In the next version (2.2) Natron will support OpenGL, meaning that portions of the rendering tree will be executed entirely on the GPU (the plug-in will receive textures and not images).

On 19 May 2016, at 18:48, mash-graz notifications@github.com wrote:

yes -- i have to agree! :)

i studied the code of the actual histogram implementation in natron and -- like often, when i try to understand the code of natron -- i was really impressed. it's far beyond the level of programming i'm able to do myself. but i'm still very interested in this specific feature, because i'm using nuke and natron quite often to analyze video material and do some color related development (e.g.my ACES profiles for the GH4 video profiles http://users.mur.at/ms/git/gitweb/?p=OpenColorIO-Configs.git;a=summary).

OCIO support and integration into the natron viewer would be the most desirable solution, but i could also accept a more simple openFX node, which has to be chained after an OCIO transformation node. a solution, which just transforms an incoming rec709/linear RGB picture to a waveform/vectorscope image. but it has to be really fast an efficent, otherwise it does not make much sense. compute shaders to gather the data and vertex + fragment shades for the final drawing to frame buffers look like the most promising way to archive this goal.

but i'm still very confused, how this kind of OpenGL usage should be implemented in a natron extension in the most efficient and compatible way? i did take a look into the shadertoy and OpenGL / osmesa examples in the test section of openfx-misc, but it's a burdensome challenge to grasp this topics...

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/MrKepzie/Natron/issues/154#issuecomment-220384400

[devernay]

From @mash-graz on May 20, 2016 0:22

thanks a lot for this lightening answer concerning the natron OpenGL jungle!

[devernay]

From @marcdraco on January 4, 2017 7:57

Did we progress any more on this? The histogram is very useful but as I think Omar would note, you really can't beat a decent vectorscope for getting things like fleshtones right. I expect Omar and others can do it without that but hacks like me (who are borderline colourblind) totally rely on them. It's said (not that I've tried it) you can colour correct bad footage on a worse monitor just using the scope!

[devernay]

From @neilpho on January 21, 2018 10:6

I'd like to vote for this! The waveform, RGB parade, and vectorscope tools all seem much better than a histogram. I guess the histogram was just the first thing people thought of and then it stuck around.

[devernay]

@mash-graz can you please contact me by email

[ajz3d]

If anyone is still maintaining Natron, then pretty please do consider adding waveform and vectorscope as a priority feature as it is important in the process of color correction.

[marcdraco]

Looks like it's gone by the wayside, probably because the "free" version of Davinci Resolv does pretty much everything as well (or better) and it costs the same except that we can't look at the code. Very sad really.

[rodlie]

If/when we get additional developers this might be worked on, until that happens don't expect major features.

We do however maintain Natron, we make sure users have working binaries and try to fix bugs and add minor features.

[ajz3d]

@marcdraco Fair observation which I cannot argue with. ;)

The problem with Linux version of Resolve is that it seems to be full of various issues. At least that's the conclusion I drew after reading Blackmagic's Linux forum thread. I'd rather like to avoid running their installer which only works with superuser priviledges because God knows what it will do to my, otherwise stable, production workstation.

@rodlie It's heart-warming to know that there are still some benevolent souls who keep on maintaining this fantastic project. After all, it's the only node-based free (as in freedom) compositor in existence that I know of.

[Songtech-0912]

@rodlie Recommend this issue to be added to the 3.0 milestone, as (ostensibly) 3.0 is going to be the first release that releases with new major features.