Hi,

I've got some problems using the code from the ocio display application in Krita, and I'm not sure what's going on. The problem is that when the exposure gets negative, the image gets more transparent, and I cannot figure out why that should be...
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Hey Boudewijn,

Sounds like the exposure function affecting the alpha channel. Alpha is usually normalized to 0 - 1, so it would make sense if positive exposure adjustments are clamped.

Cheers,

Andrew

On Thursday 22 November 2012 Nov, Andrew Hunter wrote:

> Hey Boudewijn,

>

> Sounds like the exposure function affecting the alpha channel. Alpha is

> usually normalized to 0 - 1, so it would make sense if positive exposure

> adjustments are clamped.

 

Yes -- that's what I figured. Unfortunately, I don't know why -- or rather, I don't know why that doesn't happen with the ocio display demo app. The code in Krita is pretty much the same, down to the same generated LUT -- and the shader calls the OCIODisplay method to calculate the color:

 

const char * m_fragShaderText = ""

"\n"

"uniform sampler2D tex1;\n"

"uniform sampler3D tex2;\n"

"\n"

"void main()\n"

"{\n"

" vec4 col = texture2D(tex1, gl_TexCoord[0].st);\n"

" gl_FragColor = OCIODisplay(col, tex2);\n"

"}\n"

 

I must be missing something else.

--

Boudewijn Rempt

http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

 

On Nov 24, 2012, at 5:05 AM, Boudewijn Rempt wrote:

I must be missing something else.

Looks like a known issue. MatrixOps.cpp line 457 says:

// TODO: This should not act upon alpha,
// since we dont apply it on the CPU?


Maybe you could figure out a way to keep the alpha multiplied by 1.0?



Brendan

On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.


Brendan

On 11/24/2012 2:47 PM, Brendan Bolles wrote:

On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.

I made this change recently after customer feedback. Seems to do the job, and nobody has complained yet.

On Saturday 24 November 2012 Nov, Paul Miller wrote:

On 11/24/2012 2:47 PM, Brendan Bolles wrote:

On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.

I made this change recently after customer feedback. Seems to do the
job, and nobody has complained yet.

Cool, I will try that. Maybe it's something that can be part of the next release? It doesn't matter for the binaries I build and redistribute myself, but for Linux distributions carrying Krita, it's a problem: they don't want to have patched 3rd party libraries in an application.

--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

On Sunday 25 November 2012 Nov, Boudewijn Rempt wrote:

On Saturday 24 November 2012 Nov, Paul Miller wrote:

On 11/24/2012 2:47 PM, Brendan Bolles wrote:

On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.

I made this change recently after customer feedback. Seems to do the
job, and nobody has complained yet.

Cool, I will try that. Maybe it's something that can be part of the next release? It doesn't matter for the binaries I build and redistribute myself, but for Linux distributions carrying Krita, it's a problem: they don't want to have patched 3rd party libraries in an application.

Ah, I thought it was a patch to the library -- I was looking in the wrong place. I've fixed this in krita itself now and everything is fine! Thanks for the replies.


--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl