abeker schreef op woensdag 6 april 2022 @ 10:36:
[...]
Het is leuk bedacht maar om nou te zegen dat het heel erg goed performed... De encoding/decoding speed is wel goed maar de compressie zelf is gewoon slecht. Ik weet niet wat voor settings voor libpng gebruikt zijn in de benchmarks, maar met een fatsoenlijke encoder (zoals OptiPNG) worden de PNG-bestanden véél kleiner.
images/textures_photo/IMGP5493_seamless_2.png
libpng: 911kb
qoi: 1349kb
optipng: 750kb
images/textures_pk01/pk01_vent_wall03_s.png
libpng: 201kb
qoi: 117kb
optipng: 73kb
Ik ben niet bekend met PNG optimizers, maar hoe word die optimalisatie van opslaggrootte bereikt?
Overigens is het maar net waar je de nadruk op wilt leggen, performance of opslaggrootte en wat vaker gebeurd.
Enigzins relevant anekdote; ik heb wel eens met een data generator voor een simulatie gewerkt die 1 object per keer genereerde, voor elke stap in de simulatie 1 line. Het inlezen gebeurd veel vaker, dus is handig als dat goed geoptimaliseerd is. Een line bevatte alle info voor 1 simulatie stap, dus handig bij het verwerken. Maar niet zo handig bij het generen. Het probleem daarmee was, dat als je meer dan 1 object genereerde (en daar was die data generator zeker voor geschreven), hij dus voor elk object alle lines bij langs ging. Ik had 400 objecten nodig, voor ongeveer 260k stappen. Gevolg; hij ging 400 keer alle 260k lines langs, voor 10+ bestanden om een getalletje aan het eind toe te voegen. Traag als ik weet niet wat.
Ik heb daarna voor eigen gebruik hem omgeschreven dat hij alle data van 1 object op 1 lijn uitdraaide. Bij het inlezen deed ik een transpose op de data en voila. Zelfde beginstand, en een paar ordes van groottes sneller. Ja, je moet dan wel alle info op het begin al in je geheugen kunnen laden, dus het legde een paar memory constraints op, maar dat was voor mij geen probleem.