D3D 2D exact texel to pixel *sometimes*

[zqw]

I'm creating an image processingish app in direct3D that does most work in PS2 shaders. I'm using multiple textures per pass, and the textures may be different sizes and aspect ratios - then I want to filter and stretch things to fit the window with minimal blurring. Usually, the images of the exact size of the window or an even multiple, I need NO/minimal filtering to be evidient. I'd like to use the same sampler setup for both.

So, my current solution is: Ortho projection 0 to 1, full window quad 0 to 1, with UVs 0 to 1, and GAUSSIANQUAD filter. I've verified by image diff that this does what I want when textures are exact or a multiple of the window size. I'm pretty happy with the filtering on image resize.


Does anyone see problems, or have ideas for improvement? Is there a more accurate sampling method or UV scheme? I was suprised that I didn't have to offset verts by 0.5 screen pixels, or UVs by 0.5/texWidth, etc. It all just worked.

Thanks,
-Zach



P.S. Currently, my projection is like thiis (0 to 1):
D3DXMatrixOrthoOffCenterLH( &g_matProj, 0.0f, 1.0,
0.0f, 1.0f,
0.0f, 1.0f);

UVs are 0 to 1, and I have a single quad 0 to 1, and my sampler looks like this:
sampler srcSamp = sampler_state {
texture = <srcTex>;
AddressU = CLAMP;
AddressV = CLAMP;
AddressW = CLAMP;
MIPFILTER = NONE;
MINFILTER = GAUSSIANQUAD;
MAGFILTER = GAUSSIANQUAD;
};

 

[Rolf N]

I highly doubt that whatever hardware you use supports that GAUSSIANQUAD filtering mode -- none does. Probably not even RefRast does.

That might explain why you don't need the 0.5/n offsets. I'm not that familiar with DX Graphics, but you may fall back straight to point sampling instead of the next best thing (linear) when you ask for an unsupported filtering mode. That could hide the offset problem. I do recall reading some discussions about that, and where it was concluded that these offsets are indeed required for DXG.

The following is IIRC, please anyone correct me and mock me as required
In DXG a pixel center is at integer coords n;m. Texel centers OTOH are not, they are at n+0.5;m+0.5.
Thus to draw a perfect (multisampling-proof) fullscreen quad (heh ... I know) with your ortho transformation you need vertex positions of
x0:=-0.5/width, y0:=-0.5/height
x1:= ...
x2:=1.0-0.5/width, y2:=1.0-0.5/height
x3:= ...

And the same (0;0) to (1;1) texcoords as you already use.

 

[Mate Kovacs]

You could just use transformed vertices (D3DFVF_XYZRHW instead of D3DFVF_XYZ) for the fullscreen quad, and forget about the projection.

 

[ERP]

You could just use transformed vertices (D3DFVF_XYZRHW instead of D3DFVF_XYZ) for the fullscreen quad, and forget about the projection.

Even then you have to worry about the subpixel offset.
Also NVidia used to let you change the offset in the driver control panel. And pre DX7 (or was it 5) there was no standard for the offset in DX.

 

[Mate Kovacs]

You're right, but that way he could get rid of the projection, and that ugly "0.5/width" thingy, at least.

 

[JHoxley]

There is an article in the SDK covering this. Might well be of interest:

Directly Mapping Texels To Pixels: http://msdn.microsoft.com/library/d...extures/coordinates/MappingTexelsToPixels.asp

hth
Jack

 

[zqw]

Thanks for the replys. (Apoligoes for improper quoting.)

>Directly Mapping Texels To Pixels: http://msdn.microsoft.com/library/de...lsToPixels.asp
Yeah, I went over that and the related topics - it's what got me started on this sad path.

>I highly doubt that whatever hardware you use supports that GAUSSIANQUAD filtering mode -- none does. Probably not even RefRast does.
DOH! I've got better test images now: alternating lines of black and white pixels that easily show banding under both point sampling and linear.
I need filtering for the stretched images. And linear has looked bad so far. Is there a way to use anisotropic settings to get extra samples for min/mag even if my quad is flat?


On the exact image drawing: I've tried a lot of things this weekend. And I've come very close with transformed verts and either offsetting verts by -0.5, or UVs by 0.5/texWidth. But it's not exact. It's driving me bonkers.

Luckily, tonight I found the example code attached to this paper that can display my test images exactly. I'm pretty certain my math is right. I think I'll find some global d3d state or texture option that is different as I begin adding chunks of the working code.
http://www.ati.com/developer/shaderx/ShaderX2_AdvancedImageProcessing.pdf