Compare images using shaders

[sparkzi]

Hallo,
I has following problem to solve:
I want to compare (pixel-per-pixel) two textures (first generated from many draw shapes, second read from disc) using fragment shader. Unfortunately i'm new in graphics and open gl and i need some help. My idea was:

• Draw some SFML shapes on texture
• Fill second texture with .bmp from disc
• Run fragment shader which will be run on generated texture (.bmp texture will be shader parameter) and will store information about difference for example in alpha channel ((r1-r2)^2+(g1-g2)^2+(b1-b2)^2)
• Run second pixel shader which will sum differences in rows
• Run third shader which will sum "partial sums"

I believe that in result I will have one number - difference between two images.
But I have few questions:

• It is good conception of comparing two images using gpu?
• it is possible to run three different pixel shaders using SFML?
• How can I read my final difference from shader (reading texture values will be probably very slow?)?
• Is there any option for "output" parameter from pixel shader?

I will appreciate any help

[Groogy]

well it is not unheard of. When you do HDR you do a luminosity calculation on each pixel then you calculate an average luminosity by down-sampling until you have a 1x1 texture. So I wouldn't say you are doing anything super weird really.

Yes you can run three different pixel shaders using SFML, though not at the same time, because that's not how shaders work.

Yes you will have to read from the texture if you need the value for CPU computations. There is no way to output the value to an output parameter other than an output texture. You could perhaps use CUDA or something but then you can't use SFML for it.

[sparkzi]

I'm glad to hear that Could you please give me any hint how to achieve my aim(it will be easier to start looking for something particular instead of "HDR open gl" )>

[Groogy]

Well no not really? It's just fundamental Shaders. It's not like HDR uses some special trick.
You do your calculation and store that value in a texture and read the value. No magic

[sparkzi]

Thank you
It is possible to use more than one shader during drawing sprite in SFML?

[Hanmac]

Thank you
It is possible to use more than one shader during drawing sprite in SFML?

i found two ways:

http://en.sfml-dev.org/forums/index.php?topic=12032.msg83676#msg83676 uses drawing Sprites

http://en.sfml-dev.org/forums/index.php?topic=7672.msg51053#msg51053 uses TextureParameter


but i cant say wich one is better

[sparkzi]

Thanks    I have another question, after all my calculations I will be interested in reading difference result from GPU to CPU. It will be one number only and I want to to make reading very fast, could you please give me hint how to do correctly? I thought about following solution (in las shader): shader will be run on 1x1 texture and will have  texture parameter (1x height) - it will "sum" all pixels from texture parameter and then write result to 1x1 texture. Then i will read 1x1 texture to CPU using SFML. It will be fast solution or there are any better?

[Laurent]

Using a 1x1 texture looks like the best solution to read from GPU to CPU.

[sparkzi]

During computing difference between images I recive quite big numbers: it is possible to store my original result number in 1x1 texture or I have to scale it to 0-1 range?

[Groogy]

Using SFML the value is between 0-1, SFML doesn't support different texture formats yet *frowns in Laurent's general direction*

[Laurent]

frowns in Laurent's general direction

Bah... a single pixel in current format is 32-bits, which is enough to store more than 4 billions of different values. Should be precise enough for this purpose

[Nexus]

Direct texture download incurs a blocking function call on both CPU and GPU. You should consider pixel buffer objects (PBOs) for fast readback.

Check out these resources:

• nVIDIA: Fast Texture Downloads and Readbacks using Pixel Buffer Objects in OpenGL
• OpenGL Insights: Asynchronous Buffer Transfers

[Groogy]

frowns in Laurent's general direction

Bah... a single pixel in current format is 32-bits, which is enough to store more than 4 billions of different values. Should be precise enough for this purpose

Problem is that he can only get out a color value between 0 and 255 integers unless he writes OpenGL specific code.

Edit: Or well he could encode the value in all the channels(RGBA) then he could represent a bigger number.

[Laurent]

Or well he could encode the value in all the channels(RGBA) then he could represent a bigger number.

That's what I meant.

[sparkzi]

Using SFML the value is between 0-1, SFML doesn't support different texture formats yet *frowns in Laurent's general direction*

That means that if I will write my own "reading from GPU" code (using OpenGL) I can use more values than 255 for each channel(0-1f)?