[Film in icon] Testen van optimalisatie methodes

[Schonhose]

Naar aanleiding van [filmpjes in icon] oproep aan HlpDsk en dan met name de hypothese van HlpDsK naar aanleiding van de vraag waarom de loads van sommige icoontjes zo hoog zijn (zie onderstaande quote) wil ik graag een onderzoekje opstarten waarbij eenzelfde file door verschillende pakketten bewerkt wordt (uiteraard met een aantal randvoorwaarden) om na te gaan of de verschillen in de load veroorzaakt wordt door de verschillende optimalisatie technieken in de diverse GIF-optimisers.

Hypothese

Ik begin te vermoeden (puur hypothese vooralsnog) dat het misschien wel aan de GIF software ligt. Dat die allemaal een eigen manier van optimizen gebruiken. En dat sommige verianten niet bepaald lekker CPU-vriendelijk zijn als de browser het terug moet rekenen.

Toch vreemd dat het niet simpel te zeggen is.

De randvoorwaarden (welke altijd constant moeten zijn) voor de optimalisatie die ik nu even uit de mouw schudt zijn:


• iedereen moet uitgaan van de hetzelfde bron file
• vaste aantal kleuren (standaard bijv. 32)
• aantal frames mag niet veranderd worden
• de grootte van de pic mag niet veranderd worden (standaard bijv. 60x60 pixels)
• elk pakket moet minimaal drie onafhankelijke icoontjes leveren (dat houdt in dat de meetingen bestaan uit drie icoontjes (van drie verschillende mensen) maar gedaan met 1 pakket.)
• de load moet worden bepaald op een net gestarte systeem waarbij alle draaiende processen constant moet worden gehouden.
• invloed van de verschillende browsers.

Op deze manier kun je naar mijn idee een goede vergelijking maken voor wat betreft de kwaliteit van de diverse GIF-optimisers met betrekking tot de load en de grootte van de file.

De bron file wordt geleverd door HlpDsK (zie posting hieronder)

Het lijkt me iig leuk om hier eens nader na te kijken.

Wat zijn hierover jullie meningen?

[Overige gegevens]
<sup>Titel van dit onderzoek: Tweakers GIF Optimalisatie test 2002
Onderzoeksleiders: HlpDsK & Morpheus25
Metingen Load en Grootte: HlpDsK
Statistische evaluatie: Morpheus25 (i.o.m. HlpDsK)
Optimalisatie uitvoeren: zoveel mogelijk tweakers.

Aanleveren data: bij voorkeur met een link, dus geen image posten</sup>


[edit]
Wat dingen aangepast, verbeterd en geupdate.

Versie 1.4

[Verwijderd]

Ik kan wel iets uit een DivX knippen of ff grabben. Een paar seconden.

Dan maak ik er alvast 60x60, 25 frames/sec van.

En dan mag iedereen met dat ene fragment gaan kloten.

We spreken dan een framerate en het aantal kleuren af wat het moet worden. En ieder doet dat op z'n eigen manier.

En belangrijk: iedereen vertelt precies welke software, en welke stappen/opties daarbij zijn gebruikt

[Schonhose]

Even originele posting aanpassen naar aanleiding van de opmerking van HlpDsK hierboven.....

[Verwijderd]

Dat van de vers gebootte systemen maakt niet echt uit.

Het is alvast zo (eerder 'onderzoek' heeft uitgewezen) dat de CPU-snelheid vrijwel niets uitmaakt, of de achtergrond-tasks. Het hele verhaal zit 'm in de browser. Met Opera speelt het hele probleem bv. niet. Met Netscape is de load er wel, maar de animatie is veel vloeiender. En met IE gaat het het minst vlot. En dat is toch de meerderheids-browser.

Het zou me uiteindelijk niet verbazen als MS weer iets niet helemaal volgens de standaard doet.

[Schonhose]

Op maandag 28 januari 2002 17:16 schreef HlpDsK het volgende:
Dat van de vers gebootte systemen maakt niet echt uit.

Het is alvast zo (eerder 'onderzoek' heeft uitgewezen) dat de CPU-snelheid vrijwel niets uitmaakt, of de achtergrond-tasks.

Ok, dat kunnen we schrappen dan

Het hele verhaal zit 'm in de browser. Met Opera speelt het hele probleem bv. niet. Met Netscape is de load er wel, maar de animatie is veel vloeiender. En met IE gaat het het minst vlot. En dat is toch de meerderheids-browser.

Het zou me uiteindelijk niet verbazen als MS weer iets niet helemaal volgens de standaard doet.

En dit voegen we vervolgens gewoon toe

Ik denk dat het nu wel ongeveer grotendeels vast ligt.

[Verwijderd]

Ok, hier is de Master.

Het filmpje dus van waaruit de tweakers kunnen gaan kloten.

http://tweakers.net/~crew/hlpdsk/optimalisatie_master.rar

Het is een 8 seconden fragment uit Terminator 2.
Ik heb het alvast naar 60x60, met zwarte balken, omgezet.

Het is rauwe ongecomprimeerde AVI, zonder geluid, 25 fps. Dat is je uitgangspunt.

Ik stel voor om je GIFje uiteraard te laten voldoen aan de 100 KB limiet.
Dat moet makkelijk kunnen. 8 seconden, ultra-wide-screen, moet zelfs in de helft zeer goed te doen zijn.

Verder stel ik voor dat je de framerate laat komen, niet hoger dan 12,5 fps.
(liever minder, tussen de 5 en de 9 fps is zo ongeveer de 'sweet spot').
Het aantal kleuren en de techniek van al dan niet ditheren, en verdere optimalisaties, laat ik vrij. Ik garandeer je echter dat enkele tientallen kleuren al ruim voldoende zijn. Een enkel tiental kan al verbluffend goed ogen. Maak dat je uitgangspunt om daar niet te ver overheen te gaan.

Expirimenteer. Met de framerate, met het aantal kleuren, en met de manier van optimaliseren.

Veel succes!

[Schonhose]

En vergeet niet al je stappen en instellingen te noteren om later een vergelijking tussen diverse icoontjes te kunnen maken.

Bvd.

[Verwijderd]

Ok .. mijn 1e 'run'


• Stap 1: met VDub de framerate decimated met 3. Van 209 frames naar 70 frames.
De AVI is nu 8,333 fps. Elke frame duur 13/100e seconde.
• Stap 2: ik heb de AVI in Ulead Gif Animator 4 geladen.
• Stap 3: ik heb de 1e frame een duur van 1 seconde gegeven. En geen klok-animatie. Dus puur kaal.
• Stap 4: ik heb de Gif optimized met de volgende settings:

- Global palet
- 32 kleuren
- median cut dithering
- remove redundant pixels
- remove comment blocks
- remove layer titles
- add comment

Bij 16 kleuren dithered ziet het er ook nog erg goed uit.

• Resultaat bij 32 kleuren dithered = 51 KB.
• Resultaat bij 16 kleuren dithered = 39 KB.

Hier is de 51 KB file:
http://tweakers.net/~crew/hlpdsk/optimalisatie_test_1.gif

Bij het openen van de GIF in een nieuw IE-venster geeft het mij een CPU-load van 0% aan in taskmanager, voor IE6.
99% van de CPU-tijd gaat nog altijd naar de , en de rest is onderverdeelt tussen IE en alle andere draaiende tasks.

Dat is dus precies zoals het hoort. Door de hele animatie heen een te verwaarlozen CPU-load van de browser. Hij verslikt zich er dus niet in.

[Verwijderd]

Helemaal geen interesse

[BaRF]

ok, mijn try:

Eerst in VDub Decimate / 4 > 53frames
Dan in Adobe ImageReady3, 0.08sec/frame
Optimize: Colors 32, 88% dither diffusion

resulaat: vrij vloeiend, 38.1kb

http://www.digital-grey.com/BaRF/t2_barf.gif

[Verwijderd]

Op dinsdag 29 januari 2002 22:35 schreef BaRF het volgende:
ok, mijn try:

Eerst in VDub Decimate / 4 > 53frames
Dan in Adobe ImageReady3, 0.08sec/frame
Optimize: Colors 32, 88% dither diffusion

resulaat: vrij vloeiend, 38.1kb

http://www.digital-grey.com/BaRF/t2_barf.gif

Alleen .. decimate by 4 op 25 fps = 6,25 fps
0.08 sec/frame = 12,5 fps.

Da's op zich nog geen echte ramp, maar het filmpje speelt nu op dubbele snelheid. En hij zorgt bij mij ineens voor 30% of meer load.

Kun je 'm nog eens exact hetzelfde doen, maar nu met een decimation van 3, en de framerate op 8,333 fps?

Dan weten we of het de framerate is (12,5 toch te hoog), of de GIF software. (Ulead Gif Animator vs. Imageready)

[G1itch]

Ik zal hem ff in animation shop doen.
(Ik post maar vast, om dubbel werk te voorkomen..)

[..]

Daar issie dan: icon.

- 70 frames, eerste een seconde, de andere 13/100.

settings:
- 31 colors
- median cut / error diffusion
- remove non visible elements (comment)
- write minimal frames
- collapse identical frames
- map identical pixels to transparant

Filesize 51,1 kb

[/..]

[Verwijderd]

Op woensdag 30 januari 2002 00:23 schreef G1itch het volgende:
Ik zal hem ff in animation shop doen.
(Ik post maar vast, om dubbel werk te voorkomen..)

[..]

Daar issie dan: icon.

- 70 frames, eerste een seconde, de andere 13/100.

settings:
- 31 colors
- median cut / error diffusion
- remove non visible elements (comment)
- write minimal frames
- collapse identical frames
- map identical pixels to transparant

Filesize 51,1 kb

[/..]

Kijk .. nu komen we ergens

jouw icoon doet bij mij op sommige scenes ook wel 30% CPU-load. En toch heb je idd dezelfde settings gehanteerd.

Wat me wel opviel was dat die load geen kernel-load was. (rode lijntje in taskmanager van Win2K). Dat is wat ik meestal zie bij icoontjes die 'zwaar' zijn.

Dit bevestigt sterk het vermoeden dat het aan de manier van optimizen ligt. De manier van de frames leeghalen van informatie, en de manier van de volgende frame tekenen.

Hmm

[Schonhose]

Je zult bij mij hoe dan ook even moet wachten tot na het weekend.

Ik kan hier vandaan nergens bij

[Verwijderd]

Ik heb iig ontdekt dat de kernel-load er wel is. Ik had 'n setting verkeerd staan na een herinstall van Win2K.

[Schonhose]

Is er al bekend wat de invloed daar van was?

[Verwijderd]

Op maandag 04 februari 2002 08:08 schreef Athos het volgende:
Is er al bekend wat de invloed daar van was?

Nee. Niemand heeft verder gereageerd.

Maar het zit 'm dus echt iig in het optimaliseren.


Ff iets anders: heb je het icoon van general_freakazoid gezien? Ren & Stimpy? Dat icoon jaagt m'n load helemaal tot op 100%.

[Schonhose]

Whoa 100%!

Das niet best...

Check deze dan eens:

[Oude Icon (imageready) Max. 15%]


[Nieuwe versie: (Ulead) Max. 0%]



De laatste is met Frames decimate 3, Ulead Gif met 32 kleuren. (en ruim 20kb kleiner (51kb vs 30kb)

Mijn nieuwe Bryant Icon moet ook niet zo'n hoge load hebben nu....