Question How to invert an image: one minus, invert colors, etc not inverting

Hi,
I am trying to invert an image (in particular I am trying to convert a roughness map to a smoothness map). I thought it would be easy, but all my attempts right now didnt' bring any valid result...

I have a b/w image, if I link the rgba output to one minus (or to invert colors) I get this:



And of course this is not the image inverted :/

What am I doing wrong? This is how the image is imported:



Any suggestion?

Thanks,
Francesco

 

It looks like you are doing nothing wrong. The image is what I would expect when it is inverted. You have gone from a medium dark grey to medium light grey and the cracks from a light grey to a dark grey. One minus is the correct calculation to use and should take a roughness map to a smoothness map.

So I don't see a problem at all with what you are doing. Perhaps it is the end result of the smoothness not looking how you would expect?

 

Well, I was expecting the grey (that is more a middle grey) to stay middle gray, while the cracks (light grey) should become dark grey. That is exactly what Gimp or photoshop do with the same image, with this result:



This image makes a lot more sense to me...and to gimp/photoshop I guess but perhaps you are right and the grey is actually a medium dark grey, and gimp/photoshop just use a different algorithm to calculate the inverse image

 

Gimp / Photoshop is inverting the values as they are in the image. If you’re importing a texture with sRGB enabled, it’ll be have gamma correction applied to the image when loaded by the shader, and then the invert while be applied to the gamma corrected values.

Disable sRGB on the texture, as this is not a color texture, it’s a data texture.

 

I think bgolus is right that it is the gamma correction. Also, invert in a photo editor is not necessarily going to be linear, you would have to see how they are handling color space and the negation calculation.

That sent me down an interesting rabbit hole about gamma correction baked into saved images, especially PNG files. Here is a good article on correcting gamma for images in shaders:
https://medium.com/@abdulla.aldandarawy/unity-always-be-linear-1a30db4765db

I am not saying this is good in this case where the data should be what it is, but it begs the question for textures I might create for image or data maps with common photo editing software, this gamma baked in is a problem.

@bgolus do you have a set of tools or workflow you use for getting or keeping things linear for these types of textures when not dealing with software designed to produce these textures, such as Photoshop?

 

Nothing needs to be done, because Photoshop and Gimp already do it "right". Or, more specifically, they do it wrong for color images, which happens to be correct for data images.

 

So just import and turn off Color RGBa for the imported texture and good to go?

 

“sRGB”, not “RGBa”.
https://en.m.wikipedia.org/wiki/SRGB

Short version is sRGB more closely matches the curve of human perception, which is non-linear. So it is also more efficient for storing or displaying color images in limited precision than if they were stored linearly (i.e. relative number of photons). Almost all color values you’re used to seeing, like the usual 0-255 range byte per RGB component, are sRGB color space values. A value of 127/255 looks like a “0.5” middle grey, but in reality it’s roughly one fifth as bright as 255/255. So basically everything with computers is stored as and displayed assuming sRGB color values. This includes how Photoshop and Gimp work, by default they do all operations in sRGB space, which is not actually correct for color values, but matches peoples’ expectations for what values should be when blended or inverted rather than what they should be. Inverting 127/255 in Photoshop gets you 128/255 (255-127=128) instead of 230/255.

127/255 = 0.498
0.498 sRGB to Linear = 0.212
1.0-0.212 = 0.788
0.788 Linear to sRGB = 0.9
0.9*255 = 230

But that’ll confuse most people, so they don’t do that, unless you dive deep into the settings.

The side benefit is if you are actually dealing with linear data stored with 8 bits per channel (like a 24bit RGB image is), like normal maps or roughness maps, everything works as it should.

 

Thanks @bgolus, finally I got it working thanks to your explanation