We use index maps for further compressing our DXT already since ~2005 (Doug's patent was filed 2010!) in our open-source project, and I assume many projects did so before us - such an index map is a natural conclusion from the fact that S3TC is block based.
I know (or assume) Doug just filed the patent to project his project. But the fact he uses the patent (against a non-commercial competitor) is a very bad act imo.
Not to speak from the patent office that accepted such an application ... (do they even have any knowledge of prior art?)
Side note, all 3d-devs want a new hw-based (open) compression format for ages but this news showed the field of image compression is already such mined, that just cause of such patents we will still work with S3TC in year 2035 - (software) patents are soo great .....
+1, expect item (4). The jury should decide the time the patent is granted (in a 2-7years range).
Last edited by -jK-; 07-26-2012 at 10:36 PM.
Software patents should be abolished.
And patents should expire after 5-7 years. 20-40 years is very bad.
High compression texture mapping is a logical (and obvious)conclusion of ancient texture compression algos.
I was under the impression that FXT1 was open, and that Nvidia owned the core tech. The CC_MIXED profile 'might' conflict with S3TC patent 5,956,431, but I am not experienced enough to make that call. Adding hardware support would likely be a trivial exercise for ATI/NVidia. Another issue to overcome would be the 1998 deal where MS made S3TC part of DirectX.
Originally Posted by -jK-
Looking at the arithmetic involved, I'm pretty certain that S3TC accelerated hardware could be made to support FXT1 due to the intrinsic similarities. I imagine that this will come at a cost though, in either performance or IQ.
Perhaps a SME could post regarding the technical hurdles that would need to be overcome.
FXT1 fails horribly at gradients, we don't need something worse than S3TC, we need something better.
Originally Posted by russofris
BC-6 & BC-7 are good candidates, but their implementation is very complex, so there is just MS's compressor so far. Also it is unknown if it is really free of patents.
Not to forget that none current driver implements it in hw afaik. Mesa supports it, but I don't assume any gallium driver implements it. And if I want to compress my textures on hdd and uncompress them before sending to GPU, there are much better image formats (png, jpg, ...). You use S3TC not cause it compress so well, you use it cause it stays compressed in memory (e.g. we use it for groundtextures which would be >300MB if uncompressed), saving bandwidth & storage.
According to Wikipedia the patent number for the claim is US5956431 which would be referenced in law docs as the 431 patent. You can see the patent here http://worldwide.espacenet.com/publi...E&locale=en_EP you can check the claims and legal status by clicking on the left hand side. If you do that then the patent office has not posted any thing indicating that the patent is now invalid. Further I see no reference to this patent at all in the Apple law suite pdf posted above. So unless this is the wrong patent I see no indications that it is now invalid. Of course that could be in another document. But this site doesn't seem to show it as being part of the law suite at all. http://tech2.in.com/news/smartphones...om-suit/316892
Wikipedia claims here that US patents are now good for 20 years from the filing date. Which from the application number US19970942860 19971002 would seem to be 1997. So we have roughly 5 more years of this shite.
Wikipedia patent length link. http://en.wikipedia.org/wiki/Term_of..._United_States
This is about as far as my knowledge takes me. If there are further questions I would suggest asking at Groklaw.
Originally Posted by -jK-
My feeling was that TC formats that are arithmetically similar to S3TC could leverage existing hardware acceleration through some creative driver tricks (such as the creation of a compressed intermediate format, or transformation). Whether the performance benefits would outweigh the costs of such an implementation is unknown to me. Round pegs can fit into square holes if you make the hole bigger, or the peg smaller, or file the sides flat first.