Yes, that clears it up, somewhat. However will all of the various
extensions to openGL, im still not convinced, but at least I know what
to expect. I will try to massage my numbers to be between 0 and 1 pre
output, and then blow them back to whatever range I need them to be on
the other end.
Ill report back :)
Thanks for the info. Im curious how this is handled in other
implementations.
On Sep 18, 2008, at 3:51 PM, Jens Groh wrote:
I think here it is. -- From [http://www.opengl.org/registry/specs/ARB/color_buffer_float.txt
] :
The standard OpenGL pipeline is based on a fixed-point pipeline.
While color components are nominally floating-point values in the
pipeline, components are frequently clamped to the range [0,1] to
accomodate the fixed-point color buffer representation and allow
for fixed-point computational hardware.
I was naive, thinking I was calculating with floating-point numbers.
No, it is just floating-point number syntax used for what are
actually fixed-point numbers between 0 and 1! (Which is plausible
for a high performance graphics engine indeed, but I did not know
the depths of OpenGL.)
And they say, "frequently"! That means, implementation dependent.
Probably it is really the difference between the software renderer
and the GPU that I experienced, and possibly the reason it is
contained somewhere in this table:
[http://developer.apple.com/graphicsimaging/opengl/capabilities/]
Well, I will never again assume I have more than the interval [0,1],
even if i do sometimes.
Unfortunately, I'm afraid I have to stop my project until I
hopefully find a way to port my algorithm to a fixed-point domain.
Maybe this helps you too, vade.
Jens
I wrote:
Even more strange is what I experienced, and without 'Render To
Image'.
I wanted to use a range larger than [0,1], too, because
intermediate processing in my application must be able to use
arbitrary magnitudes in the range ]-inf,inf[, which cannot be
avoided. At the input, I shift and scale the values from [0,1] to
[-1,1]. At the output, I do the reverse. The scaling is somewhat
special.
If I omit all intermediate processing and put in series those two
input/output processing 'Core Image Filter' patches, I should get
the unaltered original
kernel vec4 mapRGBColorSpaceToUnitSphere(sampler src) {
vec4 t = sample(src, samplerCoord(src));
t.rgb = t.rgb * 2. - 1.;
float sphereToCubeRatio = length(t.rgb) / max(max(abs(t.r),
abs(t.g)), abs(t.b));
t.rgb = t.rgb * sphereToCubeRatio;
return t;
}
kernel vec4 mapUnitSphereToRGBColorSpace(sampler src) {
vec4 t = sample(src, samplerCoord(src));
float cubeToSphereRatio = max(max(abs(t.r), abs(t.g)),
abs(t.b)) / length(t.rgb);
t.rgb = t.rgb * cubeToSphereRatio;
t.rgb = (t.rgb + 1.) * .5;
return t;
}
, but it does not work! Values must have been clipped, at least I
see that nothing becomes darker than (probably 0.5) grey at the
output.
Just to prove that my special scaling is not wrong, I put them both
together in a singe filter unit instead
kernel vec4 mapAndUnmapRGBColorSpace(sampler src) {
vec4 t = sample(src, samplerCoord(src));
t.rgb = t.rgb * 2. - 1.;
float sphereToCubeRatio = length(t.rgb) / max(max(abs(t.r),
abs(t.g)), abs(t.b));
t.rgb = t.rgb * sphereToCubeRatio;
float cubeToSphereRatio = max(max(abs(t.r), abs(t.g)),
abs(t.b)) / length(t.rgb);
t.rgb = t.rgb * cubeToSphereRatio;
t.rgb = (t.rgb + 1.) * .5;
return t;
}
, and this works.
But if I omit the special scaling and just do a simple one
kernel vec4 mapRGBColorSpaceToUnitCube(sampler src) {
vec4 t = sample(src, samplerCoord(src));
t.rgb = t.rgb * 2. - 1.;
return t;
}
kernel vec4 mapUnitCubeToRGBColorSpace(sampler src) {
vec4 t = sample(src, samplerCoord(src));
t.rgb = (t.rgb + 1.) * .5;
return t;
}
, there is no more value clipping! An intermediate image between
the two filter units with negative values is obviously accepted here.
I am completely stuck. Where and when does clipping occur
implicitly? How can I avoid it?
The only difference I see is the use of max() and abs() functions
and the division operator. Can this lead to a different data path
if these operations are not GPU supported and the filter is
therefore being executed on the CPU? (My GPU is an ATI
RadeonX1600.) But why then such a different behaviour? I thought
the GPU/CPU thing was meant to be completely transparent? I don't
understand that.
Regards,
Jens Groh
Am 17.09.2008 um 05:57 schrieb vade:
Hello
I think ive answered my own question, but im not 100% sure what
the proper behavior should be, so im posting to the list.
The attached composition renders a GLSL shader in a render in
image macro patch.
The GLSL shader specifies a fragment color output of -0.5 (yes,
below black).
The image is passed to another GLSL Shader which reads the image
and adds +0.75 to the input color.
My result is that the output color rendered is 0.75% luma, not
0.5, which is what id hoped for, and would expect from a floating
point texture pipeline.
Does 32bit per channel, differ from what one would expect as a
float texture in GL would be able to handle (my understanding is
it should handle fragments below 0 and above 1.0.
Does colorspace come in to play here? My understanding is that
core image supports floating point/128bit images, but are they
clipped? Hows this work? Are there any docs that clearly spell out
what is to be expected?
Curious, thanks.
<32BitFloat is clipped 0-1.qtz>
BTW, Some sort of HDR processing for sub blacks and super whites
(or, rather for my purposes more GPGPU style processing) would be
highly enjoyed and used/abused!
Thanks.
On Sep 16, 2008, at 11:07 PM, vade wrote:
Hello
Does anyone know of the using Render in Image clips float output
images to 0 -> 1.0 range?
I am beginning to think it does, based on some GLSL code im using.
Has anyone seen this?
_______________________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
