Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] Feature Requests => [Max] Resolved Feature Requests => Topic started by: Yehat on 2015-06-17, 16:34:21
-
Maybe you add, please, brightness/contrast/gamma/HUE/clamp into CoronaBitmap to kill the colorcorrect plugin (and standart colorcorrection map)? )))
-
Maybe you add, please, brightness/contrast/gamma/HUE/clamp into CoronaBitmap to kill the colorcorrect plugin (and standart colorcorrection map)? )))
+1
It will be more simple to tweak all color correction options in one step.
-
Maybe you add, please, brightness/contrast/gamma/HUE/clamp into CoronaBitmap to kill the colorcorrect plugin (and standart colorcorrection map)? )))
now THAT would be a good one. +1½
-
Maybe you add, please, brightness/contrast/gamma/HUE/clamp into CoronaBitmap to kill the colorcorrect plugin (and standart colorcorrection map)? )))
+1111111111111
-
Split topic and moved to feature request section.
-
Now wouldn't it be better to have a general color correction node so you can apply it on procedurals as well?
-
Now wouldn't it be better to have a general color correction node so you can apply it on procedurals as well?
Well there is already one in 3ds Max, so you are back to square one :)
-
Now wouldn't it be better to have a general color correction node so you can apply it on procedurals as well?
Well there is already one in 3ds Max, so you are back to square one :)
I actually think the built-in color correction node is one big failure, Cuneyt Ozdas' ColorCorrector is way better in all regards. People should stick to his plugin and forget about the built-in one. If we really want a correction node native to Corona it should not have a limitation to work on bitmaps only.
-
What's wrong with native color correction map? I know that it has somel impact on performance, but other than that?
-
Yeah I've never had an issue with the native CC map.
-
...that's what I mean - why would we need an additional color correction in CoronaBitmap when they're happy with either of the available cc maps? Better spend dev time on something more important.
-
What ondra say on another post was that cc map was very bad coded and was very slow to render , am i right??
-
Slow - don't know, but last time I checked it produced NaN pixels in some cases, the hue shift algorithm was wrong for initial versions and changed its behaviour two or three times over the latter releases (not sure about how many times exactly, but it was faulty and had to rewritten). Awkward per-channel level shifts, no normalize controls, no clamp controls (!).
-
Both slowness and NaNs were fixed ever since 2015. Clamp option is on the output node ;)
-
it is better to use dedicated color correction node. We may do our own one day, but for now, use some of the integrated ones