imgFormat == "RGBA" is missing.

[kwonoh]

Packages: GLPlot (0.0.3), Images (0.4.13), GLAbstraction (0.0.3)
When I try to run "image.jl" which is an example of GLPlot package, an error messages shows that "Color Format RGBA not supported".

[SimonDanisch]

That's interesting, I don't really know, why it works fine on all my platforms, for most image formats.
Thanks for the Pull request, I'll just merge it for now and see how it goes..
There are some mysterious things going one around this problem, which I haven't analyzed yet.
BGRA works fine, even though I tell the Video driver it's RGBA, Vec4(Red, Green, Blue, Alpha) works fine as well, which can't really be. And on my platforms (Windows, Ubuntu) I always just get BGRA...
@timholy Is there any chance that RGBA and BGRA are equal?

[timholy]

No, they have different storage order---the name encodes the order of bytes.

It's weird that telling OpneGL that it's RGBA works fine when the storage order is BGRA, I don't understand that at all. You're sure it preserves the colors correctly? (Compared to a system image viewer or ImageView.)

[kwonoh]

I'm using a Mac OS X (10.9.5).
Colors looks correctly with RGBA flag.

[SimonDanisch]

That's really odd... Especially that it just works for you @kwonoh, and it works equally well for me with BGRA, even though that the storage order is not changed...
I should create some test cases, to hunt this down!

[kwonoh]

I just thought that Images.jl returns RGBA ordered data from OS X framework but the line 175 in GLTexture.jl doesn't check for it.

[SimonDanisch]

No it's more complicated ;) I removed RGBA, as I always got BGRA and it worked fine with GL_RGBA. So I thought, okay that's odd, but if it works, I leave it for now.

[timholy]

But it's right that OSX will return RGBA, whereas other platforms will usually use BGRA.

@SimonDanisch, if you search this page for the first hit for "preferred," you'll see that the driver will do some conversion. But I can't imagine how it would know it's really BGRA when you tell it that it's RGBA.

[SimonDanisch]

By now, I know this page nearly by heart :D
I just double checked it:

#a texture initialized with 
bgra    = Texture([AlphaColorValue(Images.ColorTypes.BGR(0f0,0f0, 1f0), 1f0) for i=1:N, j=1:N])
println(bgra)
Texture: 
                  ID: 6
                Size: [ColorDim: 4]x1024x1024
    Julia pixel type: Float32
   OpenGL pixel type: GL_FLOAT
              Format: GL_RGBA
     Internal format: GL_RGBA32F
glplot(bgra) # -> gets displayed correctly

# These, also with Format: GL_RGBA, get displayed correctly as well:
rgba1   = glplot(Texture([Vec4(1,0,0,1) for i=1:N, j=1:N]))
rgba2   = glplot(Texture([AlphaColorValue(RGB(1f0,0f0,0f0), 1f0) for i=1:N, j=1:N]))

[SimonDanisch]

Oh I actually don't know that page that well. I should read it a little bit more thoroughly!

[timholy]

Are you aware that because BGR <: AbstractRGB, BGR(0,0,1) means blue? For all AbstractRGBs, you always specify the color in the order r, g, b. See the documentation here (especially the last paragraph) and constructor here.

[timholy]

Another small point: in Images, colordim means "which dimension of the array is being used to store color?" For example, in Matlab it's common to use a w, h, 3 array to store color information, in which case colordim = 3, not because it takes 3 elements to encode an RGB but because the color "axis" is the 3rd one. When color is stored as a 3, w, h array, colordim = 1. And of course, when it's stored as an Array{RGB}, then there isn't a colordim, i.e., colordim(A) == 0.

Between them, Color and Images also define length(RGB) == 3, length(RGBA) == 4, length(::RGB) == 3 and various other helpful utilities.

[SimonDanisch]

That explains, why my example works.
It doesnt explain, why bgra and gl_rgba work well together, though. Or do
you construct the images in the way, that all of them have the same rgb
memory layout? Maybe I should start reading your documentations more....
Am 24.09.2014 15:56 schrieb "Tim Holy" notifications@github.com:

Another small point: in Images, colordim means "which dimension of the
array is being used to store color?" For example, in Matlab it's common to
use a w, h, 3 array to store color information, in which case colordim = 3,
not because it takes 3 elements to encode an RGB but because the color
"axis" is the 3rd one. When color is stored as a 3, w, h array, colordim
= 1. And of course, when it's stored as an Array{RGB}, then there isn't a
colordim, i.e., colordim(A) == 0.

Between them, Color and Images also define length(RGB) == 3, length(RGBA)
== 4, length(::RGB) == 3 and various other helpful utilities.

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[timholy]

If the Image is stored as an Array{BGRA}, there's nothing more to say about the layout. (Other than checking the definition of the type.) It just shouldn't be the case that BGRA and gl_rgba should work. This suggests a bug somewhere. How did you get your BGRA image?

Over the next week I'm going to see if I can find a machine with better video drivers and check this myself. Presumably you'll have this figured out by then, but I want to get GL* working locally anyway...

[SimonDanisch]

I'll clean up my mess a bit and support the Color types better and prepare
some test cases.
Any chance, that Images.jl won't use its own color types and just transfers
them to Color.jl?
Am 24.09.2014 16:45 schrieb "Tim Holy" notifications@github.com:

If the Image is stored as an Array{BGRA}, there's nothing more to say
about the layout. (Other than checking the definition of the type
https://github.com/timholy/Images.jl/blob/d54609d8369406335650dfe4b4ecee124fcd5f6c/src/colortypes.jl#L25-L31.)
It just shouldn't be the case that BGRA and gl_rgba should work. This
suggests a bug somewhere. How did you get your BGRA image?

Over the next week I'm going to see if I can find a machine with better
video drivers and check this myself. Presumably you'll have this figured
out by then, but I want to get GL* working locally anyway...

—
Reply to this email directly or view it on GitHub
#4 (comment)
.