Texture corruption

This topic contains 5 replies, has 3 voices, and was last updated by  pasdsa 8 years, 5 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #29776

    hnyk
    Member

    Hi

    Is it possible that the color values of a texture change when the texture is loaded into memory? I have made a feature vector algorithm that seems to make small errors randomly. Errors occur when a feature vector is defined by a small difference in color value. For example in gray level picture when a pixel and the pixel next to it have only 1 level difference, the algorithm sometimes thinks that the pixels have equal levels. Or if the pixels have equal levels the algorithm sometimes think that they have one level difference.

    -Henri

    #32988

    Gordon
    Moderator

    This shouldn’t happen – GL shouldn’t alter the values.

    What format of texture are you using? Which platform? How are you loading the texture and how are you reading the texel values in the shader? What filtering are you using?

    #32989

    hnyk
    Member

    The texture is in .pvr format and I load the texture with the function provided by your shell. I use Windows PC-emulation as platform. Texel values are read with texture2D-function and with coordinates provided by vertex shader. I just add 1/512  (texture’s resolution is 512 x 512) to coordinate(s) when I want to read the next pixel’s value. What do you mean by filtering?

    #32990

    Gordon
    Moderator

    I’m not sure what you mean by .pvr (.pvr is a container format). Which format are you putting into the .pvr file (are you using PVRTexTool to produce this?). If it’s a comopressed format or lower precision 16bpp format there will be some unavoidable discrepancies from your source images.

    By filtering I mean texture filtering: GL_NEAREST, GL_LINEAR, GL_LINEAR_MIPMAP_NEAREST etc. The default when loading through the PVRTools is: GL_LINEAR without MIP-maps and GL_LINEAR_MIPMAP_NEAREST if they are present in the .pvr file. This could affect the values returned by your texture sampling. I’d suggest you use GL_NEAREST in this case if you’re not already.

    Normally the texture coordinates are passed as varyings from the vertex shader to the fragment shader and there is no need to manipulate the values manually (unless for a specific effect).

    Would it be possible for you to post your shader code or send it to devtech@imgtec.com to see if we can reproduce what’s happening here?

    #32991

    hnyk
    Member

    Thanks for the answer and sorry for the misunderstanding. I’m still quite a newbie :). Anyway, I was using wrong kind of filter. The GL_NEAREST solved the problem entirely. Thank you very much!

    #32992

    pasdsa
    Member

    By filtering I mean texture filtering: GL_NEAREST, GL_LINEAR,
    GL_LINEAR_MIPMAP_NEAREST etc. The default when loading through the
    PVRTools is: GL_LINEAR without MIP-maps and GL_LINEAR_MIPMAP_NEAREST if
    they are present in the .pvr file. This could affect the values
    returned by ottawa escort your texture sampling. I’d suggest you use GL_NEAREST in
    this case if you’re not already.

    Normally the texture ottawa asian escort coordinates are passed as ottawa asian escorts varyings from the
    vertex ottawa escorts
     shader to the fragment shader and there is no need to manipulate
    the values manually (unless for a specific effect).

Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic.