Could this have something to do with using integer coefficients vs. using floats? In your examples, using integers always works and using floats always fails, so I wonder if there are some weird type promotion rules at work.
BTW, did you read the solution to the thread you linked to? The source image was in RGB888 format and they were reading it as RGBA8888. That sounds like the same problem you are seeing here – I knew I was missing something obvious.
If passing from 24bpp to 32bpp solves the problem, this should be RGBA. What I meant was that conversion shouldn’t be the solution, unless there is no choice, of course…or maybe work with other format?
If OpenCL doesn’t support RGB888 (I didn’t know) , I’ll focus to RGBA, like you said.
(P.S. : Gimp : converting RGB to RGBA generate black image, ti’s an other problem)
I will try this, it should work (cf , previously linked thread).
In any case, thank you for taking time to reply and help me.
Discussion can maybe continue… : )
I had this kind of problem to with RGB. The image was stripped. In fact when I wanted to write the resulting image in RGB, it was considering the alpha parameter as a color, that implied the shift.
My solution was to create a table of size (4heightwidth) for the input image. with all element table[4*i+3] = 0.
I did the same to convert the table into bitmap.
I think it’s worth mentioning why OpenCL doesn’t support RGB888 out of the box. The reason is that most hardware doesn’t support 24-bit RGB internally. Instead, it is expanded to 32-bit RGBA.
Finally, I opt for RGBA image, where it’s work fine. Orobas’s trick can be exploit, I try it but doesn’t work for some reason.
I think it’s worth mentioning why OpenCL doesn’t support RGB888 out of the box. The reason is that most hardware doesn’t support 24-bit RGB internally. Instead, it is expanded to 32-bit RGBA