This artificial test image (from the Dava engine) is tough for PVRTC. Left is original, middle is my encoding (44.3 Y dB), right is PVRTexTool (37.89). Those artifacts on the 1 and 0 are so annoying.pic.twitter.com/S3dyfLod4e
আপনি আপনার টুইটগুলিতে ওয়েব থেকে এবং তৃতীয়-পক্ষ অ্যাপ্লিকেশনগুলির মাধ্যমে অবস্থান তথ্য যেমন শহর বা সুনির্দিষ্ট অবস্থান যোগ করতে পারবেন। আপনার কাছে আপনার টুইটের অবস্থান ইতিহাস মোছার বিকল্প থাকবে। আরও জানুন
Right now I compute each 4x4 block's RGBA AABB and floor/ceil it to compute the initial block L/H endpoints (like Lim's PvrTcCompressor). They are then refined using 1x1 block least squares and table lookups. These tricky "mod flips" are the last remaining major artifact to fix.
Interesting. I suspect that would be easy enough to modify in PVRTextool as the filter weights for the initial guesses are table driven... just need to add in a lot of zeros.
Lin's approach is very "stable" and is useful in real-time encoders. High frequency image features get reliably smoothed out. (Its output is basically reliably crappy!) It's usually a good source for further refinement (using LS or tables). But it suffers from mod-flips.
A few years back, a team member was working on a GPU compressor for PVRTC but it got shelved (well, pushed off the back burner and into the freezer). It really needed a way of "type punning" the texture format and (at the time) this wan't available.
Mind you, I don't think it had a way of dealing with the alignment problem either: Easiest to do that on the CPU.
টুইটার তার ক্ষমতার বাইরে চলে গেছে বা কোনো সাময়িক সমস্যার সম্মুখীন হয়েছে আবার চেষ্টা করুন বা আরও তথ্যের জন্য টুইটারের স্থিতি দেখুন।