- January 30, 2010 at 10:56 am #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.February 1, 2010 at 10:10 am #33703
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?February 2, 2010 at 1:28 pm #33704
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.February 9, 2010 at 9:56 am #33705
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.