Ramp/rectangle/radial node ability to add/remove color stops

[hpetrus]

As discussed with Fred via email, some functionality should be added to the ramp/rectangle/radial nodes, where one can add or remove colour stops for more complex ramps, etc.

If it doesn't already exist in the code somewhere, it would also be good to easily choose between different ramp shapes (ie: linear; radial; circular; etc.).

In compositing, ramps are one of the 'Swiss Army' knives of tools, allowing all sorts of ease in making quick mattes, to overlaying colour washes, etc. The ability to animate colour stops and pretty much any other parameter, makes this a powerful part of any tool.

Thanks, for considering it!

[devernay]

Just a quick question: is this feature available in another compositing software (Nuke maybe?) and how do you use it. The Color tab in Nuke only seems to apply an oriented ramp, and I don't see how to apply color stops, with more than two colors.

[devernay]

... and what about simply using a colorlookup node after a ramp (with no input to the ramp)?

[hpetrus]

I don't have access to Nuke right this minute, but I'll check it again when I get a chance. However, Blender's compositor has this functionality. Check out the colour ramp node under Convert tab. You'll notice the + and - signs that add and remove colour stops. Maya's compositor (Toxik) also had something similar. Shake, as well.

I'm not sure how you mean with the Colour Lookup node. It's great for mapping/remapping colour, if you want to use it that way, however, the functionality I speak of gives precise control over the location of the stops.

On 08/10/2015 06:20 PM, Frédéric Devernay wrote:

... and what about simply using a colorlookup node after a ramp (with no input to the ramp)?

— Reply to this email directly or view it on GitHub https://github.com/devernay/openfx-misc/issues/35#issuecomment-129632396.

[devernay]

ColorLookup is very precise:

• You make a greylevel ramp from white to black with the Ramp plugin
• You apply a precise LUT with ColorLookup, with as many control points as you want.
• you merge the ramp with the source image, with the compositing operator of your choice

The LUT cannot be animated at the moment, but this could be made in future development.

You can also use other color nodes (such as HSVTool or ColorCorrect) to apply changes, instead of ColorLookup

Please give me screenshots of the Blender/Shake/Toxik GUIs for these color stops to give me some inspiration

[hpetrus]

Here's a screen cap of a very basic ramp node set-up in Blender with results in background.

--Haig

[sozap]

ColorRamp I think are missing in Nuke and that's sad ... In blender it's very handy for a lot of things. http://www.graphicall.org/ftp/ideasman42/html_manual/_images/Manual-Compositing-ColorRamp_Colorize.png

Color correct a ramp with a ColorLookup or a grade can help in some cases, but it's not as precise and straight forward, for instance .

http://www.mongabay.net/images/oahu_2004/sunset_gradient.gif Recreate a gradient like this can be done in a few click by creating a ramp, putting a coloramp after that, and color picking the various colors...

With a colorlookup or other grading tools it's getting complex and not that precise...

[devernay]

ColorLookup (on Nuke too) has color picking. And it's really just a few clicks. Take a look at the Source and Target colors below the curve, as well as the "Set..." buttons. That's exactly making a colorramp if you use gray values for the "Source". You can put as many stops as you want too. We could draw the colorramp in the background of the graph to make it more clear (I'll work on that). Note that because of bug https://github.com/MrKepzie/Natron/issues/1323 you have to click refresh in the viewer to update the image

[sozap]

Hey, I wasn't aware of that trick, thanks ! It's indeed very usefull ! I still do think coloramps (in blender) have their usefulness ,

• with them you can tweak the gradient more easily by moving colors around ... If you have like 10 color stops , it's getting hard to find them in the colorlookup. In the same idea , with colorlookup you can't take the last point and make it the first, they get stopped by their siblings.
• Also coloramps have different gradient interpolation (linear , smooth, constant , ease , cardinal ) that's very helpfull to make a sharp or very smooth gradient.

In the end they are a bit more intuitive...

But the trick you show me open others possibility for color correction as well . So maybe it's a low priority stuff, at one point it will be a cool addition to the tool set, but it's still possible to workaround with the tools that are there... I'm not sure to well understand your idea of having the ramp drawn in the background. One cool thing could be having one gradient from black to white and below the color corrected gradient, to see what the LUT is doing. But it may not be enough to replace coloramp completely...

I can provide more explanation if needed , or make a video that show how it works in blender if you like ... but IMO all this is not top priority...

[hpetrus]

It's good to see this conversation being continued. Yes, indeed, Blender style ramps are extremely useful and intuitive for a plethora of reasons (every mapping you can think of under the sun in an intuitive way). However, we've got a workable workaround, for the moment. Still, I wouldn't say that it's low-priority, since user experience is what brings and keeps people using tools, like Blender and Natron. Being able to add more stops to a ramp in one node is something I've been able to do since the early nineties with RenderMan (by code and then through Slim and RenderTree). Maya has had it since it was Alias Power Animator. All in all, please consider this. The finest example I can think of is in Blender, though.

To the Natron team: you guys are doing a great job. Natron is becoming a really useful tool in little time. Keep it up!

On 05/29/2016 10:23 AM, sozap wrote:

Hey, I wasn't aware of that trick, thanks ! It's indeed very usefull ! I still do think coloramps (in blender) have their usefulness ,

• with them you can tweak the gradient more easily by moving colors around ... If you have like 10 color stops , it's getting hard to find them in the colorlookup. In the same idea , with colorlookup you can't take the last point and make it the first, they get stopped by their siblings.
• Also coloramps have different gradient interpolation (linear , smooth, constant , ease , cardinal ) that's very helpfull to make a sharp or very smooth gradient.

In the end they are a bit more intuitive...

But the trick you show me open others possibility for color correction as well . So maybe it's a low priority stuff, at one point it will be a cool addition to the tool set, but it's still possible to workaround with the tools that are there... I'm not sure to well understand your idea of having the ramp drawn in the background. One cool thing could be having one gradient from black to white and below the color corrected gradient, to see what the LUT is doing. But it may not be enough to replace coloramp completely...

I can provide more explanation if needed , or make a video that show how it works in blender if you like ... but IMO all this is not top priority...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/openfx-misc/issues/35#issuecomment-222363246, or mute the thread https://github.com/notifications/unsubscribe/ADoj_P2KsP8OX93gZYJyeOPFZj7EvJ39ks5qGaFggaJpZM4Fo6Tc.

[sozap]

hum, let's say it's high priority on the low priority todo list then ... :dancers: I think when you can workaround it's ok for now, there are some stuff that's still impossible to do yet, and development time and energy is limited. But that's just my opinion, it's up to the dev team to set the priority ...

[hpetrus]

Definitely on the 'to do later' list, but as long as it's somewhere on the list, is what I'm saying ;)

On 05/29/2016 10:18 PM, sozap wrote:

hum, let's say it's high priority on the low priority todo list then ... 👯 I think when you can workaround it's ok for now, there are some stuff that's still impossible to do yet, and development time and energy is limited. But that's just my opinion, it's up to the dev team to set the priority ...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/devernay/openfx-misc/issues/35#issuecomment-222399256, or mute the thread https://github.com/notifications/unsubscribe/ADoj_FDgTIJhkJRfHGHgGYJI0diWgwYbks5qGkjYgaJpZM4Fo6Tc.

[devernay]

@sozap @hpetrus could you suggest a better documentation for the colorlookup node? Note that there will soon be the possibility to add full documentation for plugins, with images. The format for that documentation will be markdown (which is the format used for the README.md file in this repository).

[sozap]

when I click on the help of the color lookup I get here : http://localhost:39409/_plugin.html?id=net.sf.openfx.ColorLookupPlugin

We can add someting like :
Note that you can easily do color remapping by setting source and target color and clicking "set RGB" below. This will add control points on the curve to match the target from the source. You can add as many point as you like. This is very usefull for matching color of one shot to another, or adding custom colors to a black and white ramp.

(these examples would be better understandable with images)

How can we edit the documentation ? I think the community could be a great help for that...

[olear]

@sozap :

The documentation is generated from the description and hints in the plugins, example:

https://github.com/devernay/openfx-misc/blob/master/ColorLookup/ColorLookup.cpp#L49 https://github.com/devernay/openfx-misc/blob/master/ColorLookup/ColorLookup.cpp#L66 https://github.com/devernay/openfx-misc/blob/master/ColorLookup/ColorLookup.cpp#L70

and an optional PLUGIN_ID.md file bundled with the plugin/bundle in the Resources folder (example: openfx-misc/Contents/Resources/net.sf.openfx.ColorLookupPlugin.md).

The documentation is generated on-the-fly by Natron.

[sozap]

Ok thanks @olear ! So if users want to edit or improve the documentation, we only need to fork OpenFX misc and submit a patch with additionnal .md files ?

[olear]

The main description and param hints are in the plugin cpp, extra "stuff" can be added to a custom .md file.

If you want to add extra info to the ColorLookupPlugin you need to make a PLUGIN_ID.md file where the PLUGIN_ID.png file is located, then edit the Makefile and add the PLUGIN_ID.md file to RESOURCES.

I will start writing some documentation for people that want to contribute docs.

[olear]

You can test your MD file in Natron by adding it to Plugins/OFX/Natron/BUNDLE_ID/Contents/Resources/PLUGIN_ID.md

[devernay]

@olear can you please add that info to a "Contributing" chapter in the Natron documentation, in a section called "Plugins documentation and tutorials"? @sozap if you don't want to fork/pull request, you can just send us markdown files (or a zip containing the markdown and images)

[devernay]

Here's the new ColorLookup background.

[hpetrus]

If this is available in the current snapshot, I'm testing it immediately.

On 06/22/2016 04:33 AM, Frédéric Devernay wrote:

Here's the new ColorLookup background. capture d ecran 2016-06-22 a 10 32 06 https://cloud.githubusercontent.com/assets/3778071/16259799/978a307e-3864-11e6-9a89-dedbe5f27179.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/devernay/openfx-misc/issues/35#issuecomment-227677973, or mute the thread https://github.com/notifications/unsubscribe/ADoj_MiYYJJT6-CO8YxP6BtZ3BnB1iz9ks5qOPNAgaJpZM4Fo6Tc.

[devernay]

Is the new ColorLookup GUI and documentation satisfactory, and can we close this issue?

[hpetrus]

For now, this is great. Easier to use and get more expected results. Well done.

On Monday, 22 August 2016, Frédéric Devernay notifications@github.com wrote:

Is the new ColorLookup GUI and documentation satisfactory, and can we close this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/devernay/openfx-misc/issues/35#issuecomment-241486779, or mute the thread https://github.com/notifications/unsubscribe-auth/ADoj_CkbrIBUR_sDYJXLvyh9f9-Vr5Oeks5qidwZgaJpZM4Fo6Tc .

[sozap]

Hello,

For me it's OK, by using colorlookup and being able to see the gradient is already a good step forward. And it open other possibilities as well that would be impossible with coloramps.

I think at some point it still would be nice to have a true coloramp node like in blender, with the possibility to move color stops around easily and to set different color interpolations.

But I'd say let's close it for now and maybe latter if someone still ask for a coloramp system let's start a fresh new discussion about that subject :D Maybe it's still too early now and there is too many things to tackle before looking into this.

Cheers,