If you're doing the rendering in D3D9, then yes, you need to move your clip-space vertices by half a pixel to compensate for it's silly pixel coordinate system, where the corner of the screen is the centre of pixel #0/0, instead of the corner of pixel #0/0 like every other API, and then it uses this stupid coordinate system in order to perform it's interpolation.
Are you rendering this texture in D3D9, and the just viewing the results in Softimage?
Looking at your image, we can guess the size of a pixel and outline them:
Assuming that softimage is drawing those lines accurately, then you can see that the yellow line at the top is in the upper 50% of the pixels in that row, which means that this row of pixels is technically contained by the polygon, and should have been filled by D3D.
What kind of offset were you using when rendering this image? In your link, the part about "subtract a half-pixel from position" is what you need.
Your link explains the problem, but for any clarification, the official explanation is here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690(v=vs.85).aspx
In any case, after you've solved this, you will want to run a dilation/gutter pass over your results in order to bleed the colours into the blackness a bit so that bilinear filter and mip-mapping work... if you can't figure this out, then you can also use that pass to hide these rasterization errors somewhat
Are they (In a sane API, not D3D9)?
The rules for rasterization are different than those for texture sampling.