Colorspace vs. VS Sampler2d: round2

psonice's picture

So, to work around the evil 'anything with a colorspace other than genericrgb fed into a vertex shader with sampler2d causes a crash' issue, I'm working on my composition with software CI (slow, but usable as a preview) and building an app with colorspaces set to genericRGB. I have the app itself working (with some help from vade) but the problem is it still isn't working with the vertex shader :/

I'm calling QCRenderer in fullscreen with initWithCGLContext, and setting the colorspace with colorSpace:CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB). It crashes the video card somehow, so that osx is still running but the screen stays black and a reset is required. If I use GenericRGBLinear, it works.. except that the vertex shader doesn't run (there's no displacement).

Am I doing it wrong? Or will I need to pull out a QCImage of the texture, change the colorspace, and feed it back into that vertex shader?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

yanomano's picture
None Codec !

If you re-compress your videos with the "none" quicktime codec it should work... But i know it is not a light solution ...

psonice's picture
No video

I'm not using any video here unfortunately. Just a lot of 16bit depth textures I'm creating with my QC paint tool or generating in realtime (which means software CI isn't really going to cut it too). So it has to be a 'real' workaround unfortunately.

franz's picture
bit wise

thinking out loud:

did you try with 8 bit textures ? do you really need the extra precision of 16 bits ? can't you interpolate within the shader (or CI) and use 8 bits pix instead ?

psonice's picture
Colorspace seems to cause it

There's a long discussion on the original issue somewhere here on kineme (I think it was under the topic 'useful bugs'), but to summarise it:

  • any vertex shader in a glsl patch will crash QC if you use a texture from certain patches in the shader.
  • only plasma, flame, and maybe one or two other patches generate an image that won't cause a crash
  • the patches that do work ok output images with 'genericRGB' as the colorspace. Anything with a different colorspace will cause an instant crash
  • turning on 'software CI' in the advanced QC prefs makes it work properly. That turns off colorspaces, but obviously performance suffers badly.

So, everything points to something in the glsl code in osx not handling colorspaces properly, which is why I'm concentrating my efforts there.

Actually, 8/16bit texturing seems to make no difference from what I've seen so far, and it doesn't have too much effect on performance. And it makes a MASSIVE difference in quality for what I'm doing. I use the texture to both displace a surface, and also to do something like normal mapping. With 8 bit i either get 'soft' surface detail, or I get a 'stepping' effect where the lighting picks out the border between grey levels. With 16 bit, it's nice and smooth.

Old pick from an early version, with the light contrast turned up to highlight the stepping effect in 8 bit:

cwright's picture
black plague

Does it hang when you run from xCode? how about from not xcode? I noticed the black screen freeze only in xcode -- it's xcode's debugger kicking in, preventing the program from closing. Since it's full screen, you can't interact with the debugger to tell it to shut up... it's a vicious cycle.

Anyway, sorry, I've got nothing on how to work around the colorspace insanity (though my deep and abiding hatred of color correction continues to fester and grow... this is such a stupid solution...)

psonice's picture

Ah, the debugger thing would explain it. As it happens, since Friday both of my macs now have dual monitors, so I'll tell the app to run on the second screen to work around it.

Have you tried any other ways of getting round the colorspace issue, like publishing the image output, pulling it into the code as a CI image and changing the colorspace attribute, then putting it back into the input of the GLSL patch? If so, I'll give up. Or more likely move on to the next harebrained scheme :)