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/jens%40optimolch.de
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]
