New Color Correction Map

[soulburn]

The Color Correction Map needs a major overhaul, as currently its very limited in the kinds of operations it can perform. Below is a proposal for a brand new Color Correction map. It would allow the following maps to be replaced: ColorCorrection, Cuneyt's ColorCorrect 3rd party map, RGB Tint, RGB Multiply, Output. The map is in order of operations, so for example, any Value adjustment happens before the HSV adjustment, and the clamp happens before the remap, because they are in that order in the interface.

Basic Parameters

An input Color or Map.

Channels

Identical to the Channels dropdown in the max ColorCorrection map, allows you to reorder or swap RGBA channels.

Value

1) Brightness, this is a multilpier to RGB, allows for numbers above 1 and negative numbers. If the input color is 0.4,0.4,0.4, and Brightness is set to 0.5, the result color will be 0.2,0.2,0.2
2) Presence is a multiplier on the alpha channel. Un-multiply Alpha: Sometimes when we get a texture it may have pre-multiplied alpha. In general, when doing a color correction, you want to do this on a non-premultiplied alpha image. So I'd like a checkbox to unmultiply the alpha.
3) Contrast with Bias for the contrast control
4) Gamma: The current gamma inside the "Advanced Lightness" area of the ColorCorrection map is actually an inverse gamma. For example, if I take a color close to midgrey and apply a gamma of 2.2, I would expect a darker value. The control in "Advanced Lightness", if set to a gamma of 2.2, makes the color brighter. Lets do a regualr gamma control.
5) Clamp: The Normalize checkbox would determine whether or not the result is then remapped to 0 to 1 space, or whether it stays at the level you've chosen. The default for Normalize should be checked.



Currently the only way to do this is to adjust the Color Map...



But this takes far more button clicks to achieve the same result, and high and low clamp spinners would also be maxscriptable, which the color map is not.

6) Remap: would take an input signal, & remap it to provided values.

So say you have an input map that goes from a value of 0 to 1



and you set your remap to 0.1 and 0.5, you would get a map whose new values are remapped to be between 0.1 to 0.5



Note, this is different from a clamp, since it doesn't cut off high and low values, you still retain all the values, it's just these now live in a different color range.

Currently the only way to do this is to adjust the Color Map...



But this takes far more button clicks to achieve the same result, and the remap spinners would also be maxscriptable, which the color map is not.

7) Bump Amount: Identical to the control in the Output Map.

HSV

1) Hue shift and Saturation shift, just like the controls in ColorCorrection map.
2) Advanced controls for HSV (Each control has an on/off switch, to let the user decide if the control is activated):

• HSV Change, this lets you take any of the three compoents, H S or V, and change their value to a new value, independently of each other. Like Change the Hue to a value of 0.8, which would make the result Pinkish / Purple, while leaving the Saturation and Value the same as the input map.
  
• HSV Multipliers, this lets you take any of the three compoents, H S or V, and multiply them by a constant. A constant of 1.0 would produce no result. Values over 1 and below 0 are allowed.
  
• HSV Offset, this lets you take any of the three compoents, H S or V, and add or subtract a number from them. Example, an Offset of -1.0 for the Hue would put the hue of the resulting pixels 180 degrees on the other side of the color wheel.
  

RGB

1) The Color Map curves feature from an Output map, for fine level control of your rgb channels.
2) Advanced controls for RGB (Each control has an on/off switch, to let the user decide if the control is activated):

• RGBA Change, this lets you take any of the four compoents, R G B or A, and change their value to a new value, independently of each other.
  
• RGBA Multipliers, this lets you take any of the four compoents, R G B or A, and multiply them by a constant. A constant of 1.0 would produce no result. Values over 1 and below 0 are allowed.
• RGBA Offset, this lets you take any of the  four compoents, R G B or A, and add or subtract a number from them.
  

Tint

Contains a color, a submap and a strength. The tint is just a multiplier, whatever color is set multiplies against the current reasult of the input. Strength is just a multiplier to the Tint color/map. This allows you to achieve similar results to the RGB Multiply map.

[pokoy]

Very good suggestion. According to Zap the Color Correction Map's code is a complete mess and a pain to update or change and he would like it to be re-written from scratch anyways.

I have to say though that the current layout you adopted is wasting a lot of valuable space, it could be way more efficient, Cuneyt's ColorCorrect would be a good example how the UI could look like.

Also, as is the case with Cuneyt's CC, RGB space operations like clamp, normalize, invert etc. really make sense as pre and post processing. In fact, buying the code from Cuneyt and incorporating it in Max would be the best thing to do in my opinion. I'm attaching a screenshot for reference.

[dgorsman]

A bit long, but otherwise *exactly* what Ideas should look like - precise, detailed, no guesswork involved.

As for buying someone else's code... not always a good option.  If the originator insists on retaining rights it could cause complications if the partnership gets split up in the future e.g. latest render engine developments with NVidia, Mental Ray, and vRay/vRay+.  Then it ends up being re-engineered from the ground-up anyways.

[soulburn]

pokoy, while I do love Cuneyt's ColorCorrect plugin, I have never been a big fame of the interface. Its very compact, but the way stuff is organized and named makes it difficult to initially figure out what the different things do IMO. Even simple stuff like using the word "Gain" instead of "Multiply", they're the same thing, but I never found it intuitive. Which is why I suggest an alternate interface. Anyways, everyone will have a different taste of course, but for me, I'd much prefer something closer to my mockup. It could certainly be user tested to see what the majority of people prefer.

- Neil

[anonamice]

Just want to chime in here that it would be equally valuable to fix/update the curve editor to be bigger, more accurate, and more useable for all output, mix, color mapping editors. Neil, I made this post already, but please dream up the interface for AD and I will gladly erase my post so you can build momentum behind better curves... Hope this CC makes it. Much needed. Curves next!

[lightcube]

I am behind this. And I'd add to the list Performance. The current CC texture is very slow (far slower than I'd expect it to be). So making it perform quickly to preview changes would be a very top priority with any updates.

[anonamice]

Please, please please !!!

A big part of this same problem is that the curve editor needs a
redesign!!! It is tiny, and really poorly thought out. No keycomands, zoom
and scale are broken and usability is just poor. It needs to be rebuilt
with usability in mind. this means bigger, key commands, and workflow
improvements.

If you render you spend a lot of time editing these curves. This has been a
real source of pain in the past.

[sebastian___]

How about a very simple blur map node for added flexibility when building procedural materials ?

[soulburn]

Sebastien, actually, there's no such thing as a very simple blur map when it comes to procedurals, it's a very hard map. 🙂 But I do have a friend who made a test of such a map once, it's certainly worth a brand new wish.

[sebastian___]

Hmm, maybe a "proper" one with "infinite" vector like resolution could be hard to make and a little CPU intensive, but until that proper one, I think even a regular gaussian blur could be useful for certain scenarios.

 And maybe even a very simple box blur or something like that could be used, since it will be used for map manipulation and in a material network and not for a full screen beauty photo processing.

Just so you can avoid a round trip to Photoshop for quick tweaks.

And maybe even a sharpen node. So you can increase those details for a bump map or other things.

[soulburn]

"I think even a regular gaussian blur could be useful for certain scenarios"

The issue from my understanding is that you can't gaussian blur a 3d procedural. So the moment you have anything other than 2d bitmaps in your material chain, you lose the ability to perform a lot of 2d operations that you are used to having in photoshop. So to do a blur on an arbitrary map chain, you basically have to do a ton of 3d raytrace sampling, not unlike what a raytracer like vray does when it does glossy reflections. Which is really really slow. Anyways, I agree that being able to blur your map chain would be useful, but that's why I feel it would probably be best as a separate wish, since it is a very different beast than color manipulation.

[mbreidt]

Could this be implemented in OSL? The UI would not be as fancy as what is posted here but at least all the math should be there.

[BenediZ]

Also important:

MASK INPUT to define on which areas of a texture it should be applied!

It should be possible to drive its influence with a greyscale map.

All LookDev nodes should have that.

(Just imagine Photoshop or Substance without Layer Masks - unthinkable and primitive!)

[Carlos_Carpintero]

Hi everyone,

I'm setting this Idea to Implemented because 3ds Max now ships with the OSL Color Correction map that has most if not all of the requested features listed in the original post.

Thank you all for the feedback!

Regards,

Carlos

Product Owner

[pokoy]

It's understandable that, from your point of view, you consider the request as implemented. No doubt the OSL CC map has some useful options. However, there are good reasons for users to avoid using OSL:

- OSL map networks can get invalidated when a scene is re-opened. I know of a studio that discovered this mid-project and chose to rebuild an entire project pipeline (avoiding using OSL) due to this bug introduced at some point. As far as I know, the bug has not been fixed, it's been reported some 1-1.5 years ago.

- Mixing OSL and standard maps comes with a performance penalty, which unfortunately accumulates for every OSL map being used in a map tree. The only way around this is to use OSL throughout the entire map tree but this comes with some considerable drawbacks - *any* parameter change in the map tree will trigger a shader re-compile which can take anything from 0.5 second to 5 seconds and more for more complicated trees. A simple CC parameter change with only a bitmap nested already produces a noticeable lag, it should be instant.

Also, no solo-map preview for maps which is a huge drawback when working with bitmaps or maps as masks.

In my view, OSL is nice to have but comes with considerable drawbacks that, unfortunately, spoil some of the advantages. Users who can't/won't use OSL don't get to see any improvement at all that way.

[Carlos_Carpintero]

Hello pokoy

We haven't received any reports about a defect regarding OSL map networks being invalidated, or breaking, when a scene is re-opened. If you are able to, can you give us more details? Or point us to a forum post where the issue is discussed? Feel free to DM me if you prefer.

Regarding OSL performance:

OSL maps need to pass through an extra compile step that legacy maps do not because they are pure code, but the difference is in milliseconds. I suppose if an OSL shader tree is very large, there could be a noticeable difference in compile time compared to a legacy shader tree. Is it possible the delay you are talking about is more related to the viewport shaders rather than the shader itself? OSL passes through a compile step so that it can be displayed correctly in the viewport. That being said, after speaking to the dev, there might be optimizations we could do in both the way OSL is compiled and displayed. I can create a ticket to start an investigation.

A couple of things you could try to speed up your work (you may be aware of them but I'll them just in case):

1. Under the Display Performance tab of the Viewports Configuration window, you can reduce the resolution of Baked Procedural Maps.

2. You can try turning off the rendering inside of the SME via the Teapot icon at the bottom left corner of the SME window. This still prevent the shader from recalculating with every change. 

Lastly, you mentioned "solo-map preview". Would this be similar to the Preview Window that already exists in the SME, but you'd like to have an option to ignore all incoming data so that only the chosen map is Previewed?

Thanks for the great feedback,

Carlos

Product Owner

[pokoy]

Hi Carlos,  thanks for the quick reply.

I'll DM you some info about the bug. It's been reported and acknowledged.

About your suggestions, (please keep in mind that the following is based on Max 2021 with all PUs installed):

- using HQ display the CC map (with only a bitmap nested, legacy or OSL doesn't matter) seems to be fast but it will only update on the first parameter change - after that it won't update in the viewport anymore, no parameter change is reflected in the viewport anymore...

- this forces me to use the standard display mode which uses baked textures. Setting this to 512px is close to instant but using 1024px or 2048px already introduces a noticeable lag. Honestly, a 512 px preview is too coarse to be useful when working with detailed bitmaps or procedural maps so to me it looks like performance should be better

- turning of the teapot icon is not helping here. it's not the rendered preview, it's the viewport that lags

As for the solo map preview - what I mean that with 'legacy' maps you can click on the 'viewport preview icon' and the only the current map is displayed. With OSL, always the highest material level is displayed. If you want to preview a mask that you for example use as a glossiness map, it's much more useful to see the b/w map in the viewport than looking at the 'final' material in the viewport - the glossiness map might be barely noticeable there. Displaying a map in such a solo mode is not possible in OSL and it's a huge functionality gap.

At least in Max 2021, I can't display any other map channel with OSL than map channel 1. Trying to correctly display any other channel in the viewport always fails. Not sure what the situation in Max 2023 is but at least for max 2021 and 3 PUs this absolutely basic functionality was not provided in time.

I noticed that in the last years, the max dev team's tendency is to deem all 'legacy' nodes and workflows as outdated, like it's a thing of the past. OSL is the new fancy thing that we keep hearing solves all problems. Legacy is dead, OSL has it all. My story and the story I keep hearing is that no one really feels OSL is there yet. Too many basic things fail. It's nice to be able to write your own shader, sure, and I really like the improved preview in the viewports but at the same time basic crucial functionality is missing.

In short - legacy maps don't get updated or improved because OSL has all the developers' attention now. OSL is unusable for some users (and most definitely is not where it needs to be for professional work where you may have 1000s of objects with 100s of materials and really complicated map setups). We're stuck in a place where nothing moves forward. Instead of improving what we had we're supposed to use a replacement that fails to keep up with its promise and hasn't seen substantial improvements for a few years already. Sorry to sound bitter but please take it as a honest account of a long-time user who has closely watched the development of shading related features (as close as it's possible on the max beta, anyway).

Thanks for you time. I'll DM you some info about the OSL bug(s).

[shawnolson]

There is now a OSL ColorCorrect map. It does not hit every single point above, but has been in Max for a few years now. Please submit new ideas for improving that map for any item not touched.