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! We accept bounties via Bountysource.

[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 MrKepzie/Natron#154 (comment).

[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!