Mas pravdu, overoval jsem si ty GIFy v CProxy a opravdu se prenaseni (zrejme) downsamplovane na nizsi rozliseni a Cproxy je pak u klienta resampluje na puvodni velikost vcetne antialiasingu, pricemz se (z principu komprese pouzite v GIF) zvysi jejich datovy objem nad "puvodni" GIF.
Sam pouzivam Cproxy a je super, mozna bude chyba u tebe.
A to, ze pri kompresi GIF je vysledek vetsi nez original neni chyba, protoze ve skutecnosti se toho prenasi mit. K vyslednemu zvetseni velikosti dochazi az u klienta diky pouziti nejakeho vyhlazovaciho filtru (aby to vypadalo lip).
Pridam jeden tip pro vyvojare akceleratoru:
Komprese JPEG obrazku v akceleratorech je vetsinou nastavena na nejaky fixni pomer velikostu "original/komprimovany". A protoze na webu jsou jak obrazky kommprimovane malo, tak i hodne, akcelerator pak nektere komprimuje zbytecne malo ci presprilis. At algoritmus pri vypoctu pouzije i velikost obrazku a a pocet bitu/pixel! Co takhle vzit jako "originalni velikost" geometricky prumer z rozmeru originalu v pixelech x 1.2bpx (=JPEG "sweetspot") a puvodni velikost JPEG obrazku?
Komprese GIF je jine tema. Treba v Cproxy je implementovana zcela chybne.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
