ARB fp, fragment.color.primary & textured quads or drawPixels - calling all Gurus

Hi Gurus

In attempting to do some image processing I’ve an ARB fragment program I’d like to apply to a displayed image however have encountered some hurdles (for ref: Renderer : NVIDIA GeForce FX 5200 Ultra OpenGL Engine Version : 1.3 NVIDIA-1.3.28 under OSX 10.3.5)

Upon enclosing a drawPixels() with a glEnable/Disable(GL_FRAGMENT_PROGRAM_ARB) it appears that fragment.color.primary referenced within the fragment program, is consistently white (for fragments written by the drawPixels() ).

Take as example the following (very simple) fragment program.

!!ARBfp1.0
MOV result.color, fragment.color.primary;
...

Having read others’ woes as to similar situations with ARB fp & drawPixels on nVidia FX, I tried a little debugging & with the same ARB fragment program, managed to get it to function as expected when instead of drawPixels I wrote verticies, 1 for each “pixel” of the image, explicitly setting the color at each vertex (pixel).

glBegin(GL_POINTS);
glColor3f();
glVertex2f();
...

(ie, in the above case, fragment.color.primary contained the glColor3f set explicitly for each fragment).
Of course, drawing images as verticies, 1 pixel at a time is far from elegant (nor feasible, given performance constraints of playback) hence I ventured down the 3rd path of texturing a quad with my image using GL_TEXTURE_RECTANGLE_EXT, blatting it to the screen

 glBegin(GL_QUADS);
glTexCoord2f();
glVertex2f();
...
 

and again enclosing the above quad in the glEnable/Disable(GL_FRAGMENT_PROGRAM_ARB) .

Though I verified the fragment program was working , again the fragment.color.primary was always white.

Given all the above, does anyone have any ideas as to what I may be doing wrong.

Thanks muchly

The value in fragment.color.primary is the interpolated vertex color, not the color of the current fragment. This is why your immediate mode example works and your DrawPixels and texture quad examples do not.

In your textured quad example, just read the colors from the texture using a TEX instruction.

Thanks for the swift reply.

Originally posted by jra101:
The value in fragment.color.primary is the interpolated vertex color, not the color of the current fragment. This is why your immediate mode example works and your DrawPixels and texture quad examples do not.
Your explanation leaves me a little puzzled. I’m almost certain I have successfully used fragment programs (both ARB and NV) to retrieve the fragment.color.primary and f[COL0] respectively, from an enclosed drawPixels() request on a Quadro FX2000 (though that was some time ago).

Can anybody verify?

Even so, I’ve come across numerous posts indicating that texturing a quad should result in fragment.color.primary containing the fragment’s, primary color.

Originally posted by jra101:

In your textured quad example, just read the colors from the texture using a TEX instruction.
If I take your suggested course of action to “texture” the quad (ie populate fragment.color.primary from within the fragment program?) then I lose the (elegant) ability to simply switch off the glEnable(GL_FRAGMENT_PROGRAM_ARB); in order to leave the “original” fragments untouched (which is highly desirable in this instance).

Can you suggest anything else that I may have overlooked?

Failing that, any other suggestions for an inexpensive way to get my image onscreen & (optionally) access (with a view to modifying) the fragment’s color within an ARB fp?

just switch between the fragment program and normal texturing?

Even so, I’ve come across numerous posts indicating that texturing a quad should result in fragment.color.primary containing the fragment’s, primary color.
Yes. The primary color is the primary color as computed in the vertex shader/fixed-function T&L and passed to the fragment shader. Anything else is a driver bug.

It does not contain the color of the texture.

Failing that, any other suggestions for an inexpensive way to get my image onscreen & (optionally) access (with a view to modifying) the fragment’s color within an ARB fp?
You may not access the color of the “pixel” to which you are writing in a fragment shader. You must use a blend operation to do something of what you are suggesting.

If you don’t want to change what’s already there, then just use the glColorMask to turn off color writes.

Thanks Nitro, the impact can be safely mitigated in this instance. I’ll give it a go asap.

Originally posted by jra101:
The value in fragment.color.primary is the interpolated vertex color
…
In your textured quad example, just read the colors from the texture using a TEX instruction.
If I understand correctly jra101,
would you suggest I bind & enable my TEXTURE_RECTANGLE_EXT (my image source), then enable the FRAGMENT_PROGRAM_ARB, then draw the single quad (supplying texture coords for each of the 4 verticies, as if there were no FRAGMENT_PROGRAM_ARB?)
Then from within the fragment program reference the (bound) TEXTURE_RECTANGLE from a TEX instruction?

In doing so, how do I determine the appropriate texture coordinate to supply the TEX instruction (is it the fragment.color.primary or fragment.texcoord[0] or am I missing the point completely?)

The value in fragment.color.primary is the interpolated vertex color
Is there any other way for me to access this interpolated vertex color, from an ARB fragment program?

You would use fragment.texcoord[0] to access the interpolated texture coordinate you specified with glTexCoord.

Here is an example:

TEX result.color, fragment.texcoord[0], texture[0], RECT;

Since you are using a rectangle texture, make sure your texture coordinates are in the [0…texture width]x[0…texture height] range.

Originally posted by Korval:
Anything else is a driver bug.
…
You may not access the color of the “pixel” to which you are writing in a fragment shader.

I (now) concur with the theory on both counts, & it appears the behavior experienced is likely attributable to a driver bug.

In practice:
QuadroFX2000 (Linux or WinXP), drawPixels resulted in (ARBfp1) fragment.color.primary and (NVfp) f[COL0] being populated with the “pixel” color. At the time, similar behavior was noted on ATI 9800Pro, though (obviously) on this hardware it only applied to ARBfp1 & interestingly on the 9800, only when pixelZoom was exactly 1.0

Nevermind, I’ll steer clear of this route. Thanks for your assurances.

Originally posted by jra101:
[b]

TEX result.color, fragment.texcoord[0], texture[0], RECT;

Since you are using a rectangle texture, make sure your texture coordinates are in the [0…texture width]x[0…texture height] range.[/b]
Much appreciated. I bow my head humbly in appreciation for your combined efforts jra101, Korval and NitroGL.
Thanks gurus