About images with alpha channel embedded

[borisquezadaa]

Well i have read a lot about this in the forums.

An image with embedded alpha channel cant be used directly both as diffuse and opacity map.
If you try to do it max can actually read the alpha channel and apply as opacity BUT is like they get the greyscale of that map messed up.

The whites are not treated as whites and asume that blacks neither, cause there are some semitransparent parts where there should be completely opaque ones.

It ocurres to me that has something to do with a gamma issue (no clue) is just i have been reading a lot about  filmic tonemapping and how shaders are writen and there are a lot of issues if the gamma correction is applied and where is applied. (I'm not expert whatsoever just generalist curious talking so dont kill me).

So i wonder... if there is a way max can output a channel out of a image like just R, G, B ,A values? so i can experiment with just the alpha channel of the image?.

The answer is yes, the ColorCorrect node has an option to output selectively a channel of your choosing.

Perfect.

So i created a material with a targai image that has alpha channel and put the map to both diffusse  and opacity. As expected the opacity are interpreted in a distorted fashion as always. And every combination of the alpha interpretation that max have just make it worse.

So i lineup a colorcorrect node between the texture and the opacity, i let only the alpha channel trough... in the preview looks like a normal map no issues there but behaves differently.
So next step i choose advanced and try to counter the gamma (i asume got messed up double time).
As no expert whatsoever i try correct to 2.2 using the slider... not enough. So i instintively bumped til 4.48 (2.2x2.2 cause it could be that gamma where applied twice somewhere... )  and it works like intended.

So my question for the technician experts or anyone who knows.

Is this a Corona related bug interpreting the gamma of an image format... like puttin (1/2.2) in a weird place?...
Is this a completely unrelated to gamma and i just get lucky?...
Is this a Max issue?... cause in other places they claim that Vray doesn't have this problem.

THe post that gave me the idea to mess with gamma was http://filmicgames.com/archives/75 and was related to a discussion here on forums by Juraj about tonemmaping

Greeting from Chile.


PS: The image has a 1000 as gamma correction cause was my first try. Dont take that number in account it should say 4.48.
PS: i know its a known bug or limitation just i'm wonder if this could be a solution or i'm tottaly off rails. XD.

[borisquezadaa]

[Alessandro]

Using color correction+CoronaOutput I've got no need to work with gamma.
In this quick sample I used the render as a texture for the plane over the base, on the right, a 32bit tga with alpha.
Ondra told me something about the need to use Corona output map, but sorry I don't remember the reason why!!! :|
With a material like mine, do you work right?

[borisquezadaa]

Hi alessandro i was not aware of Corona Output. Are you using daylies by any chance? I can find that map in Public V7.2

I have not tested tgas with alpha comming from Corona, so i can tell if that is an issue.
The problem arises when trying to use an image created in photoshop, so my guess is that photoshop does not work nice , thats why i suggest a color correct node could help for those that has the same problem.

Maybe thats the reason Ondra told you that... i really dont know.

Thanks for the info!

[Alessandro]

I've just tried with a tga created in photoshop, same material schema, it works.
CoronaOutput is a map, you can find it also in public alpha.

[borisquezadaa]

You were rigth. I was being literal. Found the map.
Thanks again for the info!.

So... here is what i've found:

1.- Corona applies some tonemapping to all images. Because of that images that includes alpha channel information gets messed up.

2.- The proper way of avoid that is to plug a Colorcorrect node to extract the alpha channel from image and pipe a CoronaMapOutput and then pipe to opacity in Corona Material. That way the alpha channel gets as is and not messed up.

That's the way  it IF you have images with alpha on it. But is wise to have separate images for that...

That's similar to what i have done with native 3dsmax maps. A Colorcorrect node with gamma set to (2.2x2.2)=4.84 to counter that initial tonemaping (and set Opacity Color to black in material settings). Sadly this approach is WAAAY to slow to render compared to native CoronaMapOutput.

3.- PRO-TIP:  In order to achieve ultimate render speed, opacity map should best be used as separate image in gif or jpg format as already discovered here on the forums.

Attached is a sample scene with 4 materials  and renders depicting time.

ColorCorrect+CoronaMapOutput                     =    57 secs
ColorCorrect set to 4.48 (opacity set to black)=    2 mins 31 secs!!!
tiff's for diffuse and opacity                              =    40 secs  NICE
tiff for diffuse and jpg for opacity                     =    38 secs GOOD
tiff for diffuse and gif for opacity                       =   37 secs  THE BEST CHOICE  IMHO.

There is a little halo around edges but i will asume that has to do with antialiasing so i will call this question fully answered.

MAYBE IS TIME FOR SOME CORONA MATERIALS AND MAPS INFO, A WIKI OR SOMETHING LIKE THAT.

[Alessandro]

Can you please have a test with a jpg format instead the gif for the alpha? Thx if you can, I'm curious about time differences!

Btw, my usually way to work with opacity map is to use a separate jpg, use the alpha channel of a picture is more convenient for any changing in map coordinate (or similar change on the map) but it's no good for render time...

[borisquezadaa]

Off course!...
It's a photographic finish for jpgs's and gifs in this scene.
Added jpg to results.

[romullus]

3.- PRO-TIP:  In order to achieve ultimate render speed, opacity map should best be used as separate image in gif or jpg format as already discovered here on the forums.

Opacity map filtering problem is succesfully solved in daily builds and there's no difference in speed between various bitmap formats anymore.

[borisquezadaa]

Hmmm.... acknowledge.
Even though this info will be valuable for Corona free users then

[Ondra]

fixed