When feeding an 8-bit grayscale image with alpha channel into a sampler, how is the grey channel declared?
Or is it that r,g and b hold the same values then?
And what about using a two-channel sampler instead? Nonsense?
i’ve never heard of a 2channel sampler and i’d guess that as you suggested direct3d will just make r,g,b hold the same value. so just try it and tell us your findings…
ok… as expected d3d complained that samplers have to be made of 4 channels.
BUT: I made a few tests using greyscale png’s + alpha and found out, that the data is being read inaccurate for some reason. The grey levels coming from the texture were darker than the original ones and r, g and b were NOT the same level (red was slightly brighter).
What’s going wrong here?
which texture format are you using in filetexture? is there any for grayscale + alpha?
I tried both A8R8G8B8 as well as A8L8 (which is the one specifically for grayscale + alpha) - no difference though.
are you reading the right pixelvalues and are you using no filter mode so that every pixels value is really the one you think it is?
no idea why r should be brighter than g and b though…
Whats about just save your grey values in one channel (ie. red) and let g & b black. Then, in your shader you read red channel only and will have a correct value.
Did you check the channel value with a graphic prog like Photoshop. Does the colour shift occur there, too? May be the values are written wrong by graphic prog.
Now there seem to be massive problems with processing gray textures.
I also discovered, that switching quads or shaders holding gray textures leads to bad drop-outs, especially when ‘Load In Background’ is set.
I attached two test-patches to verify those issues.
GrayTests.zip (105.4 kB)
@frank: I need to save memory, that’s why I’m going for greyscale images. And yes, I’ve been checking vvvv’s output using Photoshop and it really gets messed up - like being processed using some hidden gamma curve.
Now how nasty is that? RGB Textures seem to be read out inaccurate as well… With blue-values being slightly brighter than green.
Please forget my last post… measuring error…
RGBA seems fine.
ok. your _switch sample works as expected. the white flashes with “load in background” = 1 are due to the renderer not waiting for the image to be loaded, as it is being loaded in the background. your sample is just not a good use for that feature.
“wenn ich den Shader-Inhalt per ‘Writer’ exportiere und dann in Photoshop nachmesse, sind die Werte tatsächlich andere.”
couldn’t that be related to texeloffsets and filtering? are you sure you are writing the texture pixelprecise unfiltered?
i see the problems in _tint with .r resulting in a different output than .g and .b and i don’t have a clou what would cause this. .r obviously is something like -0.000…0001 instead of 0. test that by adding 0.00001 to .r or writing
saturate(grayValue.r)
which simply clamps the value to 0…1
i am not aware of any hidden gamma correction going on under the hood.
is your actual application still in danger or can you work around like this?
The thing that made me curious is, that there are no flashes with rgba textures… how come?
However, the grayscale is clearly being bent for some reason. Don’t know if it’s a gamma curve or some odd way of desaturation process going on - it just messes up the brightness information I need for proper re-tinting.
I’m now using full rgba textures for grayscales again though it sucks a lot to use 200% of the graphics memory I normally would need.
After all I suspect the grayscale handling to be buggy but reckon this to be a Direct X issue rather than a problem concerning vvvv’s filetexture node.