PVRTC compression “on the fly”

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

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


    Would it be feasible to encode a 256×256 RGB8 texture in a fraction of second on the Iphone assuming we have the right compressor? Or is the process itself just too complex to attain these speeds?

    Reading through the paper didn’t help me too much to answer those questions.



    The difficulty with on-the-fly compression is both in the complexity of encoding and in achieving an acceptable quality of output in the final image. Running the compressor as available in our SDK on the iPhone is impractical though we have done other work which has been more promising. This is a research area and we have achieved good results in some cases, but not all.

    To produce high quality output in all cases may be impossible to attain within the constraints you mention given PVRTC is significantly less trivial to encode than other forms of texture compression.

    Do you have a particular use case in mind? Is there any questions you have about the document?



    Thanks for the answer, I would use a fast compressor for a geobrowser that downloads textures from a wms server, of course it would be better to compress the textures on the server but thats not really an option for me. And about the paper I just lack the mathematical background to understand it.   (wavelets?) 

    Thanks again.


    I am also interested in this feature

    Guess I can only dream of realtime compression here … but I would settle on a couple of seconds per 1024×1024 texture. Is it feasible?

    Do you have any code sample you can refer me to for compressing PVRTC on the iphone hardware.

    I would be grateful if you can give me something to work with.



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