Texture compression algorithm

This topic contains 3 replies, has 2 voices, and was last updated by  Gordon 8 years, 9 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #29657

    bitplane
    Member

    Hello

    Is there source code available for compressing PVR textures, or is this something that can only be done with the texture tool?

    #32554

    Gordon
    Moderator

    We do not currently provide source code for the creation of PVR texture files. PVR is a container format that is described in the documentation for PVRTexTool and PVRTexLib. Everything required to generate a PVR is included there, I believe, although the format of the texture data itself is not explained.

    PVRTC formatted PVR files can only produced by PVRTexTool/PVRTexlib and a tool in Apple’s iPhone SDK. Also, there is a white paper in the POWERVR SDK package that details the specifics of PVRTC if you are interested.

    #32555

    bitplane
    Member

    I figured as much, thanks for the response.

    I’ve since found articles and code on the web that explain how to generate the textures.

    If we were to support PVRTC in our cross-platform open source graphics
    library then decompression is a must, the ability to edit recompress
    would be highly desirable, support in our software rasterizers is
    highly unlikely but would still be incredibly cool. If we were to add PVRTC support do we (well, our American users) need to be aware of any patent restrictions?

    #32556

    Gordon
    Moderator

    There is PVRTC decompression source code in our SDK (Tools/PVRTDecompress.cpp) that you are free to use as long as copyright is maintained. PVRTexLib provides both compression and decompression in Linux and Windows libraries that you are free to use (again respecting copyright and acknowledgement), but we can’t supply you with source code for this, I’m afraid. You are free to write your own compressor/decompressor and I would be very interested in what you came up with if you did.

    Note that editing and recompressing is likely to degrade texture quality substantially – it’s best to have only one stage of compression in a texture resource pipeline.

    Directly supporting PVRTC in a rasterizer is likely to kill performance as the format was designed specifically for decompression by our specific hardware and extracting single pixels on a CPU involves a relatively large amount of processing.

    As far as patents are concerned, I’m not a lawyer, but I believe there is no problem with the uses you suggested above. Situations such as if the technology is incorporated into new hardware or if someone starts marketing and selling the scheme as their own are more at odds with the patents, I believe.

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