CoronaBitmap - gamma discussion

[romullus]

I logged bug on mantis that CoronaBitmap doesn't respect override input gamma and always use automatic one. But now report was closed with resolution that it won't be fixed as automatic gamma is enough.

I'd like to start petition to reconsider this. First of all it makes converstion of old scenes troublesome as all my normal maps are loading with wrong gamma and i must manually fix it one by one. Aditionally, i quite often load greyscale jpegs with gamma 1.0 in reflection and/or glossy slots. Now with CoronaBitmap i forced to stick with gamma 2.2. i find it limiting.

Please, don't take that funcionality from us, as it's not making use of Corona simpler, more elegant or intuitive in any way.

Or maybe i should start a poll for this?

[maru]

Maybe an "automatic gamma" checkbox that would be on by default and off for old/converted scenes? But Ondra probably won't like the idea of yet another checkbox. :)

[romullus]

There's no need in any additional checkboxes or switches. Simply respect for gamma set in load bitmap window would be enough. That's why i can't understand why it was declined.

[Ludvik Koutny]

Yep, i think there was a bit of misunderstanding regarding how this feature is used at our office. I explained it from the production point of view and it seems the gamma override in image open window will return :)

[romullus]

[Ondra]

I would LOVE to kick the option out, but once again, we found out that 3dsmax/3DCG ecosystem is just not mature enough for that :(

[rfletchr]

How do you mean Ondra? I would have said that having manual control of this was essential as max has no way of telling what the input data is representing.

[Ondra]

the idea is that since our loader is not from max, we could do it better (automatically). We still can, but then the problem is with OUTPUT to 3dsmax texture slots, not INPUT.

[rfletchr]

so you want to assume everything is linear and the user adds a correction?

sorry if im not understanding. gamma makes my brain hurt.