[C#] Voortgang van het laden van een image

[_Thanatos_]

Ik ben bezig een applicatietje te schrijven die grote afbeeldingen moet kunnen weergeven (megapixel-afmetingen zegmaar). Het laden van een afbeelding, een simpele JPEG, duurt hierbij al gauw 2-3 seconden, zelfs op mijn dikke quadcore. Wat ik dus wil, is een voortgang maken dat nog veel harder nodig is voor mensen met een niet-zo-snelle cpu. Let overigens wel dat ik zoek naar voortgang van het decoden, niet het laden van disk.

Mijn ultieme doel is dat ik een image al ladend in een picturebox "langzaam" zie opbouwen, net zoals een browser dat ook zo mooi kan met grote jpegs. Daarnaast wil ik het laden vaneen afbeelding kunnen cancellen, zodat als de gebruiker door een lijst met afbeelding bladert, hij niet voor iedere stap moet wachten.

Ik hoopte dus dat je aan Image.Load() een callback of iets kan meegeven, maar helaas. GDI+ lijkt zoiets nergens te ondersteunen.

Wat heb ik al geprobeerd:
Ik heb een Stream class geschreven die om een FileStream heen wrapt, en een event afvuurt bij iedere call naar Stream.Read(). Zo kan ik in dit event een exception opgooien om het laden af te breken. Helaas heeft dit twee grote nadelen: je kunt de te laden afbeelding nog steeds niet progressief weergeven, en je moet je in rare bochten wringen omdat GDI+ er niet zo blij mee is

Wat ga ik niet proberen (denk ik ):
PictureBox.LoadAsync(). Die gaat het niet worden voor mij, omdat het async-gedeelte ervan niet meer is dan het laden van disk (of internet). En dus gaat het decoden nog steeds synchroon. Bovendien zal het alleen met een picturebox werken, en ik heb meer flexibiliteit nodig.

Heeft iemand een idee hoe ik dit kan bereiken? Het zou een beetje zuur zijn als iets basaals als een progress-callback niet mogelijk is, toch?...

[RobIII]

_Thanatos_ schreef op maandag 29 september 2008 @ 21:51:
zelfs op mijn dikke quadcore.

Dat zal weinig boeien t.o.v. een single core; er zullen niet zo snel meerdere threads gebruikt worden voor het laden van een image

_Thanatos_ schreef op maandag 29 september 2008 @ 21:51:
Let overigens wel dat ik zoek naar voortgang van het decoden, niet het laden van disk.

Ook dan doen de cores er weinig toe denk ik (maar da's op gut-feel). Zover ik weet zal een loadimage geen progress reporten dus tenzij je daar custom libraries o.i.d. voor gaat gebruiken zal het je (denk ik) niet lukken.

_Thanatos_ schreef op maandag 29 september 2008 @ 21:51:
Mijn ultieme doel is dat ik een image al ladend in een picturebox "langzaam" zie opbouwen, net zoals een browser dat ook zo mooi kan met grote jpegs. Daarnaast wil ik het laden vaneen afbeelding kunnen cancellen, zodat als de gebruiker door een lijst met afbeelding bladert, hij niet voor iedere stap moet wachten.

Again; LoadImage en consorten die linksom of rechtsom op hetzelfde neerkomen zullen daar geen mogelijkheid toe hebben.

_Thanatos_ schreef op maandag 29 september 2008 @ 21:51:
Helaas heeft dit twee grote nadelen: je kunt de te laden afbeelding nog steeds niet progressief weergeven

Uiteraard; het aantal reads of hoeveelheid gelezen bytes verandert niets over het wel/niet progressive weergeefbaar zijn van een image. Het kan goed zijn dat pas na het lezen van de laatste byte uberhaupt gedecodeerd kan worden

_Thanatos_ schreef op maandag 29 september 2008 @ 21:51:
PictureBox.LoadAsync(). Die gaat het niet worden voor mij, omdat het async-gedeelte ervan niet meer is dan het laden van disk (of internet). En dus gaat het decoden nog steeds synchroon.

Jep en Jep. Ik denk dat je wel eens met een profiler mag gaan kijken want ik denk dat de grootste vertraging toch wel degelijk in de I/O ligt en niet zozeer in het decoden. En dus zou je juist daar van de progressie willen weten. In dat geval is het percentage gelezen bytes natuurlijk wel leuk om te weten voor een indicatie van het geheel, maar zul je je image nog steeds niet progressief kunnen weergeven.

_Thanatos_ schreef op maandag 29 september 2008 @ 21:51:
Heeft iemand een idee hoe ik dit kan bereiken? Het zou een beetje zuur zijn als iets basaals als een progress-callback niet mogelijk is, toch?...

Ik vrees niet met native .Net; hooguit met wat custom libraries.

[ Voor 7% gewijzigd door RobIII op 29-09-2008 22:32 ]

[_Thanatos_]

Jep en Jep. Ik denk dat je wel eens met een profiler mag gaan kijken want ik denk dat de grootste vertraging toch wel degelijk in de I/O ligt en niet zozeer in het decoden.

Ik heb geen profiler nodig om te concluderen dat een plaatje van 3MB er 1 seconde over doet, niet aan de harddisk kan liggen. Die trekt nml makkelijk het 20-voudige. Geloof me, het is zuiver de rekentijd.

Voor de rest, heb je misschien wat pointers naar custom libraries (liefst in .net geschreven) die wel capabel zijn om pregress te tonen? Echt, als GDI+ dat niet eens kan, is mijn vertrouwen daarin nog verder gezakt... resizen gaat al crap, en nu dit.

Anyway, ik ga zelf ook ff verder kijken, scriptrequests mogen tenslotte niet. Maar iemand met een goed idee is zeker welkom

[Gerco]

Als het een operatie is die 2-3 seconden duurt heb je natuurlijk helemaal geen echte progress indicator nodig. Een Throbber oid is genoeg. Zo lang iemand maar kan zien dat het programma bezig is en het minder dan 5 sec ofzo duurt heb je ook helemaal geen cancel button nodig.

In een app van mij zit al een jaar of twee voor veel operaties (maken van netwerkverbindingen, synchrone method calls over RMI) alleen een "Ik ben $ding aan het doen" indicator (modal dialog met tekst en een indeterminate progress bar) en geen cancel button. Die dialog springt alleen op wanneer een operatie langer dan 1.75 seconde duurt, kortere operaties zie je alleen in de status bar. Mensen vinden dat in de praktijk helemaal niet vervelend.

Er zijn ook operaties die langer dan dat duren, die voorzien van een progress bar met voortgang en een cancel knopje is bijzonder aan te raden.

Microsoft heeft er ook een mening over:
[quote=http://msdn.microsoft.com/en-us/library/aa841990.aspx]
Use a progress indicator during operations that take more than 2 seconds.
• Use an hourglass mouse pointer if the process takes 2-7 seconds.
• Use a progress bar if the process takes 8 seconds or more.

[ Voor 22% gewijzigd door Gerco op 30-09-2008 09:07 ]

[MSalters]

2-3 seconden voor een JPEG? Dat is belachelijk, zelfs voor een multi-megapixel image. HDTV (1080p) laat meerdere megapixel images per seconde zien. Vind eerst eens uit wat er fout zit.

[_Thanatos_]

Als het een operatie is die 2-3 seconden duurt heb je natuurlijk helemaal geen echte progress indicator nodig. Een Throbber oid is genoeg.

Het is een applicatie die een image moet weergeven. Een throbber is dan out of the question. Ik wil dat een image net zo geladen wordt als in een browser: progressief. Dat houdt dus ook in dat cancellen mogelijk moet zijn als de user naar het volgende plaatje hopt terwijl de huidige nog aan het laden is.

2-3 seconden voor een JPEG? Dat is belachelijk, zelfs voor een multi-megapixel image. HDTV (1080p) laat meerdere megapixel images per seconde zien.

HDTV is video en werkt compleet anders. Daarnaast is er niets mis met de jpeg. Ik heb duizenden van zulke plaatjes en geen enkele applicatie laadt ze sneller dan ~2 seconden. Ik doe dan ook gewoon:

C#:

Image.FromFile(filename);

Daar zal toch geen fout in zitten? Dat gedeelte duurt echt 2 seconden, of de file nou van disk of direct uit de cache komt. Zelfs als ik em eerst naar een MemoryStream pomp (wat overigens in een split second gaat - geheel verwacht).
Echt, 2 seconden op een jpeg is NIET raar, het is gewoon groot. Anders zou ik graag een voorbeeld van je zien om een 3000x2000 jpeg in 100ms te laden, daar sta ik volledig voor open

[AtleX]

Progressive loading moet afaik ondersteund worden door het formaat van de afbeelding, dat zal je dus niet zomaar lukken. Kan je niet decoden terwijl je een message weergeeft zoals Gerco al voorstelt, en pas na het decoden de afbeelding weergeven? Ik denk dat je nu heel moeilijk een oplossing zoekt voor een zelfverzonnen probleem, terwijl de rest van de wereld gewoon algemeen geaccepteerd gedrag implementeert en dus een message weergeeft.

[_Thanatos_]

Het is geen zelfverzonnen probleem. Het is een probleem dat IEDERE image viewer heeft. Progressief weergeven wordt zeker weten door png, jpeg, gif en bmp ondersteund en geen van allen doen ze het. Logisch, want het afbeelding wordt eerst gedecoded en dan pas in een picturebox gegoten. Ja, ik kan ook een filename aan een picturebox geven en LoadProgressChanged gebruiken, maar again, dat is voor het lezen van een afbeelding, niet het decoden. Hij wordt dus eerst gedecoded, en dan pas weergegeven, maar dat gaat dus niet instantly.

In any case, het is een absoluut praktisch probleem. Ik heb een applicatie met een lijst bestanden waar de user doorheen kan rollen en een picture box. Ik wil niet dat als de user gewoon heel simpel de pijl-naar-beneden-knop ingedrukt houdt, iedere nieuwe selectie een seconde of 2 op zich laat wachten. Laden moet misschien niet progressief, maar wél asynchroon en normaal abortable. Pak er maar es een willekeurige image viewer bij, dan weet je wat ik bedoel.

Bottom line is dat het laden/decoden/whatever abortable moet zijn en dat is het niet. Image.FromFile of Image.FromStream returnt gewoon niet totdat de boel geladen is. Mijn stream die een exception opgooit werkt wel, maar alleen tijdens het laden. Het decoden daarna is weer onherroepelijk synchroon. En het is vies.

Dus vraag ik nogmaals om mee te denken tot een oplossing, en niet een workaround...

[ Voor 4% gewijzigd door _Thanatos_ op 30-09-2008 20:04 ]

[RobIII]

_Thanatos_ schreef op dinsdag 30 september 2008 @ 20:03:
Progressief weergeven wordt zeker weten door png, jpeg, gif en bmp ondersteund

Da's volgens mij niet zo zwart/wit als je het stelt: Een JPEG moet bijvoorbeeld wel als progressive opgeslagen worden wil je progressief kunnen weergeven en bij BMP en PNG kan bepaalde compressie zijn toegepast waardoor progressive weergeven verhinderd kan worden. Ik ben er weer een beetje uit qua low-level format van die bestanden voor dat kleine beetje dat ik er 'in' was, maar AFAIK is het dus niet altijd mogelijk.

_Thanatos_ schreef op dinsdag 30 september 2008 @ 20:03:
Bottom line is dat het laden/decoden/whatever abortable moet zijn en dat is het niet. Image.FromFile of Image.FromStream returnt gewoon niet totdat de boel geladen is. Mijn stream die een exception opgooit werkt wel, maar alleen tijdens het laden. Het decoden daarna is weer onherroepelijk synchroon. En het is vies.

Je zult dan toch écht zelf moeten gaan decoden of, again, naar 3rd party libraties moeten; en dan wens ik je veel plezier want da's geen kattepis

[ Voor 45% gewijzigd door RobIII op 30-09-2008 20:19 ]

[AtleX]

Het probleem is dat je decode time hoe dan ook hetzelfde blijft, en progressive loading is echt zo makkelijk nog niet tenzij je een decoder schrijft en ik denk dat dat niet de bedoeling is. Is het geen optie om de user een message te tonen terwijl je bijvoorbeeld de eerste 5 afbeeldingen decode? Daarna kan je op de achtergrond de overige afbeeldingen inladen. Dit zal tijdens het gebruik een snellere user experience bieden, maar je initiele laadtijd en geheugenverbruik gaan behoorlijk omhoog.

[ Voor 19% gewijzigd door AtleX op 30-09-2008 20:19 ]

[_Thanatos_]

Da's volgens mij niet zo zwart/wit als je het stelt: Een JPEG moet bijvoorbeeld wel als progressive opgeslagen worden wil je progressief kunnen weergeven en bij BMP en PNG kan bepaalde compressie zijn toegepast waardoor progressive weergeven verhinderd kan worden.

Kan allemaal wel zijn, maar het heeft geen invloed op de picturebox. Dus, bedankt voor de uitleg, maar ik heb er vrij weinig aan als .net er niets mee doet

Is het geen optie om de user een message te tonen terwijl je bijvoorbeeld de eerste 5 afbeeldingen decode? Daarna kan je op de achtergrond de overige afbeeldingen inladen.

Nee, door een lijst een heen scrollen gaat met zo'n 20 per seconde (probeer maar, gewoon in de verkenner) en dat is veel te snel om bij te houden als ik alle afbeeldingen die na 10% al afgebroken zouden worden, toch helemaal ga decoden...

[ Voor 57% gewijzigd door _Thanatos_ op 30-09-2008 20:32 ]

[Gomez12]

En als je nu gewoon de afbeeldingen gaat cachen? 1e impressie is afkomstig van multimegapixel afbeelding, dit genereert een thumbnail.
2e impressie is thumbnail met asynchroon het starten van het laden van de volledige afbeelding voor als iemand doorklikt.
Tonen van een volledige afbeelding betekent asynchroon laden van de vorige + volgende afbeelding.

Decoden van een afbeelding is heel simpel te ondervangen door gewoon een viewport buiten beeld te creeeren waarin je de volgende / vorige afbeelding laadt. Het daadwerkelijk naar volgende gaan is dan alleen maar een switch tussen viewports..

Kost je wat geheugen en redelijke problemen om een goede cache te krijgen maar in principe zou het volgens mij moeten werken.

[_Thanatos_]

Ik heb geen zin om mezelf te gaan quoten, want jouw "oplossing" is al eens genoemd en gaat niet handig zijn als ik een lijst van 1000 afbeeldingen van ieder 10MB heb en de user houdt het pijltje naar beneden ingedrukt. Denk je dat een dual quadcore dat zelfs kan bijhouden? Nee dus, en het moet ook op singlecore werken

Scrollen door een lijstje MOET mogelijk zijn, dat is het hele idee van de applicatie. Dat het lekker snel en vloeiend aanvoelt. Als je dingen gaat cachen, ga je het laden dus niet afbreken en wordt de applicatie lomper bij iedere volgende afbeelding die moet laden. Tenzij, zoals eerder gezegd, het mogelijk is om zulke afbeeldingen in 100ms te laden. Trager dan 100ms en het moet afgebroken worden. De user wil die afbeelding niet meer zien, dus het is zinloos om daar verder nog cpu-tijd aan te besteden.

[RobIII]

_Thanatos_ schreef op dinsdag 30 september 2008 @ 20:59:
Ik heb geen zin om mezelf te gaan quoten, want jouw "oplossing" is al eens genoemd en gaat niet handig zijn als ik een lijst van 1000 afbeeldingen van ieder 10MB

Dat is 1Gb en die wil je in een split second van schijf gelezen hebben en decoded hebben? Get real. Daat zul je linksom of rechtsom trucjes voor nodig hebben. Kijk eens naar applicaties als picasa e.d. Die maken ook thumbnails/caches.

_Thanatos_ schreef op dinsdag 30 september 2008 @ 20:59:
Nee dus, en het moet ook op singlecore werken

Again; het decoden zal überhaupt moeilijk te multithreaden zijn zover ik dat kan inschatten.

_Thanatos_ schreef op dinsdag 30 september 2008 @ 20:59:
Scrollen door een lijstje MOET mogelijk zijn

Best maar dan moet je geen belachelijke eisen gaan stellen en gewoon je neer leggen bij het feit dat je wat 'magie' gaat nodig hebben. Dat is preloaden/thumbnailen/cachen/whatever maar in een seconde door tig fotos van tig MB heen raggen gaan je, al scrollend, gewoon niet lukken en al zeker niet vanuit een .Net managed omgeving; hooguit als je specialized code in assembly gaat zitten fröbelen of high-performance 3rd party libs ofzo gaat gebruiken en dan nog is het twijfelachtig en dien je behoorlijk stevig in je schoentjes te staan.

_Thanatos_ schreef op dinsdag 30 september 2008 @ 20:59:
Trager dan 100ms en het moet afgebroken worden. De user wil die afbeelding niet meer zien, dus het is zinloos om daar verder nog cpu-tijd aan te besteden.

De user besluit in 0.1 seconden of 'ie de foto wil zien?

[Gomez12]

Ja, en?

Voor mij part bouw je het cachen in in het upload gedeelte.

Wat jij wilt is in 100 ms een plaatje laden en dat is gewoon onmogelijk met GD zonder caching en met multimega pixel plaatjes. Dan kun je 100x schreeuwen dat je het toch wilt, of je kan kijken naar mogelijkheden om het toch te doen.
Caching is imho een goede mogelijkheid om dit beschikbaar te maken, kan je alleen nog discussieren over het tijdstip waarop je de cache vult, dit kan tijdstip van aanlevering / nachtelijke cronjob / het viewen van de plaatjes zelf zijn en kan je toepassen op user niveau / systeem niveau.

Jij zegt dat het zinloos is om meer dan 100ms aan een plaatje te besteden omdat het te traag is voor een user en dat je het daarom maar afgebroken wilt hebben, ik zeg dat als er 1 proces is dat meer dan 100ms aan een plaatje besteed dat het dan voor iedereen bruikbaar is en geen verspilde cpu-tijd meer.

Als je dingen gaat cachen op systeemniveau wordt het alleen trager voor de 1e user, alle volgende users hebben het sneller. Ga je cachen op user-niveau dan gaat het alleen maar over de 1e keer.

Als ik jouw gedachtengang volg dan zou ik gewoon alle plaatjes die langer dan 100ms laden verwijderen want niemand wil ze toch zien.
Volgens mij heb je verschillende views en zijn mensen best bereid om langer om langer te wachten als ze echt het multi-mega-pixel bestand willen bewerken, alleen niet voor de thumbnail/fullscreen/quick-preview weergave hiervan( hier heb je dan ook de cache voor ).

Trager dan 100ms en het moet afgebroken worden. De user wil die afbeelding niet meer zien, dus het is zinloos om daar verder nog cpu-tijd aan te besteden.

Vind ik dan ook wel typerend, die cpu-tijd is niet zinloos, het is een investering in de volgende view.
Heb je louter en enkel single views dan kost het gewoon die tijd en daar doe je vrij weinig aan behalve misschien een import restrictie dat er geen mega-multi-pixel images geimporteerd mogen worden...

[MSalters]

Tja, ik heb commerciele code gezien om thumbnails te genereren van JPG. Dat was best snel voor ongeoptimaliseerde code, gebaseerd op de reference implementatie. JPEG is gecomprimeerd via DFTs op blokken van 8x8 of 16x16 pixels. Een 1/9 thumbnail is dus triviaal, dat is de [0][0] component van je DFT pakken. Dus geen enkele decompressie nodig. Heb je een tweede core beschikbaar, dan doe je een snelle bicubic interpolatie terwijl je in een andere thread de echte decompressie doet. Voila, genepte progressive JPG. (Echte progressive JPG plaatst de [0][0] componenten vooraan, maar disk I/O was snel genoeg hier)

Enne, je hebt vrijwel zeker een lagere resolutie in je display dan je JPG, gezien de groottes. Dat betekent dat je sowieso al een downscale nodig hebt; goede kans dat je 75% van de pixels direct kunt weggooien.

[ Voor 15% gewijzigd door MSalters op 30-09-2008 22:02 ]

[Gomez12]

RobIII schreef op dinsdag 30 september 2008 @ 21:08:
[...]
Again; het decoden zal überhaupt moeilijk te multithreaden zijn zover ik dat kan inschatten.

Yep, het decoden zelf is moeilijk te multithreaden, maar als je eenmaal 1 plaatje gedecode hebt dan staat ook je singlecore gewoon te idlen omdat de mens gewoon meer tijd nodig heeft om een plaatje te bekijken dan een computer.
Deze tijd is perfect te gebruiken om alvast te beginnen met in een andere thread het volgende plaatje te decoden ( geen statistisch bewijs, maar procentueel schat ik de kans groter in dat het merendeel naar het volgende / vorige plaatje gaat ipv een ander voorbepaald random plaatje )

[...]
maar in een seconde door tig fotos van tig MB heen raggen gaan je, al scrollend, gewoon niet lukken

@TS : Dat is juist mijn punt, je gebruiker willen niet door je multi-mega-pixel foto's heen raggen. Ze willen door kleine thumbnails heen raggen, cache je thumbnails dan ook gewoon. On the fly thumbnails maken van multi-mega-pixel foto's klinkt leuk totdat je uit gaat rekenen hoeveel het gaat kosten om dit te bereiken...
Alles is mogelijk, wil jij multi-mega-pixel foto's in 100ms op iemands scherm tonen dan is dit ook best mogelijk, alleen moet je dan wel state-of-the-art hardware bij de klant gaan financieren, wil je directie dit niet dan moet je kiezen tussen of je multi-mega-pixel foto's verwijderen of gewoon met meerdere gecachede weergaves gaan werken die wel binnen 100ms getoond kunnen worden.

[_Thanatos_]

De user besluit in 0.1 seconden of 'ie de foto wil zien?

Ja waarom niet? Je ziet 30 foto's op een rijtje, de eerste is geselecteerd. Wat doe je? Je pakt het toetsenbord en druk 10 keer op [pijl omlaag]. Of je houdt die knop ingedrukt. Dat probeer ik nu al een paar keer uit te leggen.

Alles is mogelijk, wil jij multi-mega-pixel foto's in 100ms op iemands scherm tonen dan is dit ook best mogelijk

Dat heb ik nooit gezegd. Ik wil alleen dat een foto progressief weergegeven wordt als het langer dan 100ms duurt (los van of het formaat dat ondersteunt). Als dan de eerste 10% geladen is, dan zie je ook de eerste 10%. Als je dan door die foto's heen aan het raggen bent en je ziet niets gebeuren, lijkt te applicatie traag, terwijl het juist heel snel is.

Nogmaals, ik wil foto's dus gewoon weergeven zoals een browser. Is dat zo onbegrijpelijk ofzo

[Gomez12]

_Thanatos_ schreef op dinsdag 30 september 2008 @ 22:20:
[...]
Ja waarom niet? Je ziet 30 foto's op een rijtje, de eerste is geselecteerd. Wat doe je? Je pakt het toetsenbord en druk 10 keer op [pijl omlaag]. Of je houdt die knop ingedrukt. Dat probeer ik nu al een paar keer uit te leggen.

De vraag is dus of jij 30 multi-mega-pixel foto's op een rijtje toont of dat je thumbnail representaties hiervan toont? IMHO toon je geen multi-mega-pixel foto's maar alleen representaties.
Nogmaals kijk eens naar acdsee / picasa / windows explorer applicaties die hanteren allemaal een cache, alleen jij lijkt er een aversie tegen te hebben en verplicht jezelf bijna die multi-mega-pixel foto's on the fly te willen resizen.
Het inladen van een multi-mega-pixel foto kost gewoon tijd, daar ontkom je niet aan. Alleen kan je veel sneller een redelijke representatie geven door gewoon een 1600x1200 image te cachen ( dit is dus niet multi-mega-pixel maar over het algemeen wel een adequate representatie )

[...]
(los van of het formaat dat ondersteunt).

Idd onbelangrijk detail...

Nogmaals, ik wil foto's dus gewoon weergeven zoals een browser. Is dat zo onbegrijpelijk ofzo

A : browser foto's zijn over het algemeen geoptimaliseerd voor het web, progressive etc.
B : Je begrijpt hopelijk toch wel dat een browser gewoon ook een interne cache heeft.
C : Als je het echt zo wilt doen als een browser wat is dan het probleem met embedded IE control?

Oftewel, het is niet onbegrijpelijk maar jij lijkt een aantal stappen over te slaan.

Na enige nadenken begin ik het idee te krijgen dat jij gewoon niet snapt hoe traag een user is tegenover een computer, of dat je niet weet om te gaan met idle-tijd. Juist met plaatjes heb je een gigantische idle-tijd als er nieuwe dingen zijn. Als iemand een enkel plaatje toevoegt dan is het imho 100% verklaarbaar waarom dit 2 sec langer duurt.
Wil iemand complete series aanleveren dan kan je aanbieden om gewoon crontabs te gaan draaien etc.
Het simpele feit blijft gewoon staan dat jij niet 1GB aan plaatjes in 1 sec op je scherm krijgt ( en dat 90% van de users dat ook niet wil dat is een 2e ), hoeveel assembly je er ook tegenaan gooit. Het is gewoon te veel data.
Als je toch 1GB in 1 sec aan je users wilt tonen dan moet je en je infrastructuur updaten ( want met 100 users concurrent users moet je 100GB per sec kunnen bieden ) en je rekencapaciteit upgraden ( want je users moeten 1GB per sec kunnen verwerken )

[ Voor 40% gewijzigd door Gomez12 op 30-09-2008 23:21 ]

[Stukfruit]

Laat maar, ik las verkeerd.

[ Voor 94% gewijzigd door Stukfruit op 30-09-2008 22:57 ]

[Gerco]

_Thanatos_ schreef op dinsdag 30 september 2008 @ 22:20:
Nogmaals, ik wil foto's dus gewoon weergeven zoals een browser. Is dat zo onbegrijpelijk ofzo

Dan zul je dus ook je rendering en decodering zelf moeten implementeren of 1 of andere library gebruiken die werkt zoals jij dat wilt. Je zult geen picturebox gewoon out of the box kunnen gebruiken voor progressieve weergave zoals je dat wilt. Hier gaat veel code in zitten.

Overigens ga je met die progressieve weergave ook niet krijgen wat je wilt, want als je dan de pijl naar beneden knop ingedrukt houdt zie je van elke foto de eerste twee of drie rijen met pixels voor ze weer van je scherm af zijn. Daar heb je als gebruiker ook helemaal niets aan.

_Thanatos_ schreef op dinsdag 30 september 2008 @ 23:02:
Ik hoop dat het nu eindelijk duidelijk is

Yep. Je gaat dus niets hebben aan de meegeleverde functionaliteit in .NET. Je zal dus ofwel zelf decoding moeten doen voor al je images of je moet ergens een progressive library vandaan halen.

[ Voor 34% gewijzigd door Gerco op 30-09-2008 23:05 ]

[_Thanatos_]

Nee nee nee!

Ik heb gewoon een lijstje met bestanden. Net als in de verkenner. NIETS speciaals aan. Sommige van die bestanden zijn megapixels foto's. Die foto's moeten progressief weergegeven worden. Let wel dat progressief niet hetzelfde is als progressief! Een "progressive" jpeg kun je progressief weergeven, maar de tegenhanger "interlaced", surprise suprise, kun je óók progressief weergeven.

Wat ik wil, is tijdens het laden gewoon weergeven wat er tot dusver geladen is. En als in die tijd inmiddels iets anders geselecteerd werd, het laden afbreken en het volgende item gaan laden, wat dat ook moge wezen.

Daar heb je geen thumbnailing of caching of forking of weet ik veel wat voor nodig. Daar heb je geen speciale images voor nodig. Dat werkt zelfs met png, gif, tiff, bmp, pcx en tga! En nee NATUURLIJK wil ik geen browser gaan embedden, als ik dat wil, dan ga je wel helemaal compleet los van het eigenlijke probleem. Bovendien is IE een slecht voorbeeld. En de interne cache van de browser staat er compléét los van, als je die uitzet heb je nog steeds progressieve images overal.

Ga nou es gewoon met je browser naar een willekeurige site met een grote foto en kijk hoe de browser het ding weergeeft. Dat duurt misschien 10 seconden, maar je ziet em stukje bij beetje opbouwen. en dat werkt met ieder soort jpg, png en gif!. Daar is geen speciaal soort encoding of wat ook voor nodig.

Ik hoop dat het nu eindelijk duidelijk is

[RobIII]

Dan neem je de source van Chrome/Firefox/whatever er bij en kijk je daar eens in?

[Gomez12]

_Thanatos_ schreef op dinsdag 30 september 2008 @ 23:02:
Ik heb gewoon een lijstje met bestanden. Net als in de verkenner. NIETS speciaals aan. Sommige van die bestanden zijn megapixels foto's.

Klinkt speciaal...

Wat ik wil, is tijdens het laden gewoon weergeven wat er tot dusver geladen is. En als in die tijd inmiddels iets anders geselecteerd werd, het laden afbreken en het volgende item gaan laden, wat dat ook moge wezen.

Dat biedt .Net niet standaard, en met goede redenen huidige functionaliteit is ongeveer 3 / 4x sneller vanwege alles in memory opbouwen tov gedeelte opbouwen en viewen, volgend gedeelte opbouwen etc.

Dat werkt zelfs met png, gif, tiff, bmp, pcx en tga!

Cool, jouw browser kan dus tiff/eps/tga progressief weergeven? Welke is dat ? Al diegene die ik heb kunnen het amper native weergeven laat staan progressive...

En nee NATUURLIJK wil ik geen browser gaan embedden, als ik dat wil, dan ga je wel helemaal compleet los van het eigenlijke probleem.

Sorry, maar zoals ik het lees wil jij een image weergeven als in een browser. Gebruik dan ook een browser.
Jouw probleem bestaat imho alleen maar uit het feit dat jij in een browser iets ziet en je geen browser element wilt gebruiken wat wil je dan?

En de interne cache van de browser staat er compléét los van, als je die uitzet heb je nog steeds progressieve images overal.

Ik weet niet waar jij rondzwerft, maar als er overal progressieve images in browsers getoond werden had ik waarschijnlijk 9 van de 10 aggresieve caching methodes op mijn plaatjes-georienteerde websites niet hoeven toepassen.
Of noem aub een browser die overal progressieve plaatjes toont ( dan kan ik deze aanraden voor intranet oplossingen) of stel het aub iets minder krachtig. Er is een reden dat GoT een check-images heeft ingevoerd en die was niet dat overal progressieve images kwamen...

Ga nou es gewoon met je browser naar een willekeurige site met een grote foto en kijk hoe de browser het ding weergeeft. Dat duurt misschien 10 seconden, maar je ziet em stukje bij beetje opbouwen. en dat werkt met ieder soort jpg, png en gif!. Daar is geen speciaal soort encoding of wat ook voor nodig.

Grappig, opeens mis ik tiff/bmp etc. Om nog maar te zwijgen over eps / tga etc. Om maar nog harder te zwijgen over eigengemaakte image-sites waar zonder magic dit helemaal 100% niet opgaat.
Sowieso denk ik dat je bij jezelf eens heel hard te raden moet gaan of die 2 sec vertraging echt onoverkomelijk is als het 10 sec duur als je het op een andere manier gaat doen...

Ik hoop dat het nu eindelijk duidelijk is

Zoals iemand anders al zei, ga eens in de source van IE / FF / Chromium kijken hoe zei het voor elkaar krijgen om elk plaatje progressief weer te geven, ik gok dat je niets speciaals vind omdat het imho gewoon onwaar is wat je nu beschrijft

[Ruudjah]

Als het progressief laden kan, kan het multithreaded decoden natuurlijk ook met performance winst. Progressief laden betekend gewoon dat er slechts een gedeelte word geladen. Als één thread een gedeelte kan decoden, kunnen meerdere threads dit natuurlijk simpel tegelijketerijd doen. Lijkt mij een no-brainer.

Een andere creatieve, maar nogal arbeidsintensieve (lees: lotsa low-level code) oplossing zou zijn om je GPU het decoden te laten doen. Dit gaat magnitudes sneller, en de kans is best aanwezig dat je helemaal geen progressive loading nodig hebt: de GPU tovert een megapixel image in luttele milliseconden op het scherm. Knelpunten hier lijken me de adoptie van GPU libraries in .NET, en de kans dat de client simpelweg geen GPU heeft. Blijf je nog steeds zitten met hetzelfde probleem.

Als .NET hier dus geen standaard oplossing voor biedt, dan zal je denk ik toch echt een eigen klasse moeten gaan schrijven om images te gaan loaden. Wellicht kan je hier en daar nog wat juice encapsuleren, scheelt weer wat werk. Dan implementeer je gewoon zelf de LoadImage() methode met je eigen callback mechanismes. Kan je twee bovengenoemde items erin mee verwerken (GPU based decoding en multithreading).

Ik ben zelf niet bekend met libraries voor .NET die jouw beschreven functionaliteit implementeren. Maar het is een interresante. Overigens vind ik de reacties die je krijgt nogal vreemd voor wat je wil: een rich user experience. Je zou zeggen dat dit standaard in .NET zou moeten zitten, en dat een zichzelf respecterende developer dit ook zou moeten willen.

[ Voor 3% gewijzigd door Ruudjah op 01-10-2008 07:56 ]

[LauPro]

Gomez12 schreef op dinsdag 30 september 2008 @ 23:40:
[...]
Cool, jouw browser kan dus tiff/eps/tga progressief weergeven? Welke is dat ? Al diegene die ik heb kunnen het amper native weergeven laat staan progressive...

Kijk eens naar Konqueror - met de juiste plugins kom je redelijk ver.

Wat ik mis in deze draad is de sowieso de EXIF metadata thumbnail feature in JPG? Daarbij is het mogelijk om dus gewoon on the fly de thumbnail uit te lezen en is er geen scaling nodig. Voor de rest zal je veel threads moeten maken voor preloading, er is geen andere oplossing voor bijv. een BMP - wat een absolute ramp is als je er een van een paar honderd MB tegen komt, in Konqueror (khtml) hebben ze een limiet gemaakt op filesize voor caching.

[ Voor 5% gewijzigd door LauPro op 01-10-2008 05:47 ]

[Teunis]

Wil je dus eigenlijk een Filmstrip in je eigen applicatie ?
dan is misschien Thumbs.db
wel te misbruiken

[_Thanatos_]

Allemaal oplossing voor problemen die ik helemaal niet heb.

Klinkt speciaal...

Ja een map met foto's is heel speciaal. Dat heeft haast niemand

Dat biedt .Net niet standaard, en met goede redenen huidige functionaliteit is ongeveer 3 / 4x sneller vanwege alles in memory opbouwen tov gedeelte opbouwen en viewen, volgend gedeelte opbouwen etc.

Dat het sneller is, betekent nog niet dat het ook sneller aanvoelt. Als je even niks ziet gebeuren (al is dat maar een halve seconde), dan voelt het al traag aan.

Sorry, maar zoals ik het lees wil jij een image weergeven als in een browser. Gebruik dan ook een browser.

Die excuses zijn inderdaad op z'n plaats. Want het is complete onzin om als ik bepaald gedrag zoek, maar gewoon een applicatie te embedden die dat gedrag al biedt. Als je een rich text editor in je applicatie wilt, ga jij zeker ook MS Word of OOo Writer embedden

Of noem aub een browser die overal progressieve plaatjes toont ( dan kan ik deze aanraden voor intranet oplossingen) of stel het aub iets minder krachtig.

Firefox, Opera, you name it. Maar ik stel het zo krachtig omdat het niet over lijkt te komen. Het lijkt hier alsof ik tegen een muur praat.

Wat ik mis in deze draad is de sowieso de EXIF metadata thumbnail feature in JPG?

Dat is JPG- en PNG-only en ik heb nog maar een handjevol afbeeldingen gezien die dat ook daadwerkelijk gebruiken. Bovendien wil ik geen thumbnails, ik wil de hele afbeelding showen.

Wil je dus eigenlijk een Filmstrip in je eigen applicatie ?
dan is misschien Thumbs.db wel te misbruiken

Nee, ik wil een plaatje tonen dat getoond wordt tijdens het laden. Ik heb geen thumbs.db en die wil ik ook nergens tegenkomen.

[LauPro]

_Thanatos_ schreef op donderdag 02 oktober 2008 @ 01:00:
Firefox, Opera, you name it. Maar ik stel het zo krachtig omdat het niet over lijkt te komen. Het lijkt hier alsof ik tegen een muur praat.

Dat is allemaal leuk en aardig, maar browsers zijn gemaakt voor het weergeven van webcontent, en een BMP van 100+ MB's is geen webcontent, evenals een JPEG van 4 MB. Je gebruikt de verkeerde applicatie voor deze toepassing.

Dat is JPG- en PNG-only en ik heb nog maar een handjevol afbeeldingen gezien die dat ook daadwerkelijk gebruiken. Bovendien wil ik geen thumbnails, ik wil de hele afbeelding showen.

Dan zou je kunnen denken aan een service welke alle JPEG's prepareert met de juiste thumbnails - volgens mij kan je de grootte zelf bepalen uiteraard moet je wel de bestanden hiervoor modificeren.

Nee, ik wil een plaatje tonen dat getoond wordt tijdens het laden. Ik heb geen thumbs.db en die wil ik ook nergens tegenkomen.

Zoals eerder gesteld zal deze case zonder caching(provider) een absurde hardwareconfiguratie vereisen. Het is gewoon onmogelijk om met standaard hardware gecomprimeerde afbeeldingen welke enkele honderden MB's ongecomprimeerd kunnen zijn op een dergelijke manier on the fly weer te geven. Punt.

Als GDI+ geen ondersteuning voor deze feature heeft zul je zelf een andere lib moeten zoeken, ik zou eens zeggen duik eens in khtml en de renderengine voor afbeeldingen, daar zit een behoorlijke hoeveelheid functies in die jij volgens mij zoekt.

[Gomez12]

_Thanatos_ schreef op donderdag 02 oktober 2008 @ 01:00:
Allemaal oplossing voor problemen die ik helemaal niet heb.
[...]
Ja een map met foto's is heel speciaal. Dat heeft haast niemand

Multi mega pixel foto's die zonder caching binnen 100ms op een scherm getoond worden, nee ik schat inderdaad dat niemand dat heeft. Elke hedendaagse image viewer ( en windows explorer ook ) gebruikt een cache juist vanwege dit soort images.

[...]
Dat het sneller is, betekent nog niet dat het ook sneller aanvoelt. Als je even niks ziet gebeuren (al is dat maar een halve seconde), dan voelt het al traag aan.

Zorg er dan voor dat je caching zo ingesteld is dat 1 persoon er last van heeft en 300 personen er plezier van hebben. Nogmaals 1GB aan images in 1 sec inladen is gewoon niet realistisch te doen.

[...]
Die excuses zijn inderdaad op z'n plaats. Want het is complete onzin om als ik bepaald gedrag zoek, maar gewoon een applicatie te embedden die dat gedrag al biedt. Als je een rich text editor in je applicatie wilt, ga jij zeker ook MS Word of OOo Writer embedden

Praktisch gezien, ja wel als ik weet dat mijn publiek word / writer geinstalleerd heeft. Ik ga geen spellingscontrole / bold / underline / italic / plaatjes invoegen etc. nabouwen als er al een complete component is die precies doet wat ik wil. Beetje zonde van mijn tijd.
Jij zoekt specifiek gedrag wat jij in een app gezien hebt, ga dit dan aub niet nabouwen ( met alle nadelen van dien ) maar gebruik gewoon wat er al is.

[...]
Firefox, Opera, you name it. Maar ik stel het zo krachtig omdat het niet over lijkt te komen. Het lijkt hier alsof ik tegen een muur praat.

Misschien dat die muur er lijkt te zijn omdat firefox gewoon geen bmp's progressive load bij mij. JPG's die niet progressive zijn opgeslagen worden hier ook niet progressive getoond...

[...]
Dat is JPG- en PNG-only en ik heb nog maar een handjevol afbeeldingen gezien die dat ook daadwerkelijk gebruiken. Bovendien wil ik geen thumbnails, ik wil de hele afbeelding showen.

Dus oftewel jij wilt multi mega pixel afbeelding showen met tientallen tegelijk? Mag ik even vragen of jij het hebt over een videowall ofzo? Een afbeelding van 2000x3000 pixels past bij mij al niet meer op mijn beeldscherm, daar vind al scaling op plaats...

[...]
Nee, ik wil een plaatje tonen dat getoond wordt tijdens het laden. Ik heb geen thumbs.db en die wil ik ook nergens tegenkomen.

Dan wil jij imho dus iets waarvoor je de hardware niet hebt. AFAIK kan een niet-decoded niet-interlaced / niet -progressive opgeslagen plaatje in theorie zelfs in de laatste decoded pixels nog het pallet hebben zitten.
Om dat te voorkomen is er juist progressive uitgevonden.
Of je kan je plaatjes bij binnenkomst opnieuw opslaan als progressive en dan een andere .net lib pakken die wel progressive weergave ondersteunt of je moet gewoon even wat extra hardware voor je klanten kopen zodat deze de complete afbeelding kunnen decoderen in 100ms.

[Sebazzz]

Kijk eens naar de broncode van het - jawel, in C# geschreven - Paint.NET en kijk hoe hun het hebben gedaan. Want hun doen het mét voortgangsbalk.

[H!GHGuY]

_Thanatos_ schreef op dinsdag 30 september 2008 @ 20:03:
Het is geen zelfverzonnen probleem. Het is een probleem dat IEDERE image viewer heeft.

Er is misschien een reden waarom al die image viewers het niet oplossen. Heb je _daar_ al eens over nagedacht?
Mijn gok is omdat het geen probleem is.

_Thanatos_ schreef op donderdag 02 oktober 2008 @ 01:00:
[...]
Die excuses zijn inderdaad op z'n plaats. Want het is complete onzin om als ik bepaald gedrag zoek, maar gewoon een applicatie te embedden die dat gedrag al biedt. Als je een rich text editor in je applicatie wilt, ga jij zeker ook MS Word of OOo Writer embedden

Net wel!. Hergebruik is goed. Waarom iets zelf doen als iemand anders het beter kan. Waarom iets zelf doen als iemand anders er zijn brood mee verdient en het voor jou slechts een klein deel is van je functionaliteit.

[...]
Het lijkt hier alsof ik tegen een muur praat.

Wat baten kaars en bril, als de uil niet zien wil.

Ik denk dat men hier al genoeg heeft aangetoond dat wat jij wil:
- een imaginair probleem is. (Gebruikers maken er in het algemeen geen probleem van)
- niet kan met de standaard GDI+ library.
- niets helpt: Ik kan uit de eerste 10 rijen pixels van een 3000x2000 image of de eerste blurred image die uit een interlaced 3000x2000 image komt weinig halen. Kortom, de gebruiker moet nog langer wachten.
Als een gebruiker daadwerkelijk zo snel scrollt dan is het omdat de gebruiker beter weet dan jij welke foto hij zoekt (bvb aan de filenaam. Foto is halverwege de reis geschoten, dus uit een collectie van 300 foto's zoek ik best rond de 100-200 range) Geef hem dan de mogelijkheid om op die criteria te zoeken.

[...]
Dat is JPG- en PNG-only en ik heb nog maar een handjevol afbeeldingen gezien die dat ook daadwerkelijk gebruiken. Bovendien wil ik geen thumbnails, ik wil de hele afbeelding showen.

Jij wil _hele_ afbeeldingen van 3000x2000 gaan showen op... een monitor van 1280x1024 in... een picturebox van 150x100. Right. Ga nou maar voor de thumbnails oplossing met caching. Dan heb je heel die progressieve problematiek niet. Dan toon je in 50ms (12ms HD seek time, 13ms read time en 15ms decoding en 10ms display) een thumbnail.

Wees eens lekker pragmatisch:
Scenario1 - progressieve images
Je hebt een library nodig die na elke stap JPG decoding (be it interlaced of progressive) een output geeft (1d zoeken)
Heb je die niet, dan moet je zelf een JPEG library schrijven die dit ondersteunt of een bestaand JPEG library wijzigen. Dit is zeker een of meer weken werk afhankelijk van je kennis.
Daarna moet je die library nog inbouwen in je applicatie. (1d)

Scenario 2 - thumbnails in cache
Kies een voor jou optimale caching strategie (wanneer thumbnail maken, hoe bijhouden, ...) (30min)
Implementeer deze strategie (Image resizing en opslag) (4u).
Implementeer het weergeven van thumbnails uit de cache en het viewen van de full image als er op geklikt wordt (4u)

Wat de performance aangaat, zoals hierboven al iemand zei: Het progressief weergeven van een image kost danig veel meer tijd dan het decoden alleen. Dus als jij 3 images progressief weergeeft, kon je er misschien al 9 volledig getoond hebben. Met een cache gaat je performance zelfs naar een niet te onderschatten veelvoud.

Zie je nu waarom alle grote vendors ervoor kiezen om te gaan cachen? Een 150x100 thumbnail van een 3000x2000 JPEG neemt een fractie van de plaats in en laadt een veelvoud sneller. Afhankelijk van de rest van je app kun je er dan nog steeds voor kiezen om multicore in te schakelen bij de thumbnail generatie.

[urk_forever]

Toevallig zat ik gisteren bij een oud-collega met een mac die wat foto's liet zien. De mac 'verkenner' werkte ook met thumbnails die getoond werden en als er geen thumbnail was moest je daar even op wachten. Niks progressive images, voortgang van laden etc. Als de thumb er is zie je hem en anders zie je een standaard plaatje. Dan kan je snel scrollen en als je het plaatje wilt zien moet je even wachten.

Dit gebeurde zeker en vast niet met de originele 8+ megapixel foto's. Volgens mij wil de TS iets wat gewoon niet mogelijk is en als het mogelijk is niet iets is wat de gebruikers zouden willen omdat het zo langzaam is.

Zojuist nog even getest met Irfanview (mijn favoriete image viewer!!) met een aantal 8MP foto's. Het laden duurt daarin ook 2-3 seconden per foto's en die laat ook niets progressive zien. Ik klik op volgende, de zandloper verschijnt, hij laad de foto en als het laden gereed is laat hij de foto zien.

[_Thanatos_]

Nou vooruit dan, ik heb het op jullie manier gedaan. Het blijft zuur dat een image niet progressief getoond kan worden, maar eerst maar es kijken of ie geladen kan worden. Ik wil het laden kunnen afbreken, dus ik gooi de boel in een thread.

De code voor het aanroepen van de thread:

C#:

if (imageLoader != null) {
    imageLoader.Abort();
}
imageLoader = new Thread(LoadImage);
imageLoader.Start(info.FullName);

En de thread zelf:

C#:

private void LoadImage(object parameters) {
    string filename = parameters as string;
    Image image = null;
    MemoryStream m = null;

    try {
        using (FileStream fs = new FileStream(filename, FileMode.Open, FileAccess.Read, FileShare.Read)) {
            m = new MemoryStream((int) fs.Length);
            StreamHelper.StreamToStream(fs, m);
            m.Position = 0;
        }
        image = Image.FromStream(m);
    }
    catch (ThreadAbortException) { }
    catch (Exception e) { }
    finally {
        if (m != null)
            m.Close();
    }

    this.Invoke(new MethodInvoker(delegate() {
        if (image != null)
            pictureBox1.Image = image;
        imageLoader = null;
    }));
}

En waarom doe ik het zo? Eerst had ik het veel simpeler. Gewoon rechtstreeks van file laden. Maar als je deze thread maar vaak genoeg afbreekt en opnieuw start, willen images gewoon niet meer laden. Ook images die nooit eerder geladen waren. Ik kreeg dan een "generic error ocurred in GDI+". Lekker duidelijk

Dus toen maar omgebouwd en de boel eerst in een MemoryStream gegooid, zodat ik zeker weet dat er niet iets raars gebeurt tijdens het van disk laden. Maar het probleem bestaat nog steeds. Op een gegeven moment wordt er na een paar reads die generieke exception opgegooid, zonder een manier om te kijken wat nou het probleem is.

Het kan geen handle zijn die nog openstaat, want er zit een using-clause om de FileStream heen, dus die wordt gesloten. Zelfde geldt voor de MemoryStream: als ik die niet sluit, krijg ik out-of-memory exceptions. Het kan ook niet zijn dat de thread aborted wordt, want dan zou ie niet eens beginnen met laden, en ik zou geen generieke exception maar een ThreadAbortException moeten krijgen.

Dus hoe zouden jullie dit dan doen?

[AtleX]

Wordt die handle niet pas opgeruimd zodra de Garbage Collector langskomt? Dan zou je handle dus alsnog open kunnen staan, tenzij je zelf expliciet sluit.

[RobIII]

Een "generic error ocurred in GDI+" duidt toch behoorlijk op GDI objecten die niet netjes gedisposed worden. Misschien toch maar eens goed nakijken.

[Not Pingu]

_Thanatos_ schreef op donderdag 02 oktober 2008 @ 15:41:
Nou vooruit dan, ik heb het op jullie manier gedaan. Het blijft zuur dat een image niet progressief getoond kan worden, maar eerst maar es kijken of ie geladen kan worden. Ik wil het laden kunnen afbreken, dus ik gooi de boel in een thread.

Progressief laden is ook alleen bedoeld voor gevallen waarin je je image als stream binnenhaalt. Door gewoon Image.FromFile te doen snap je zelf ook wel dat de hele file eerst wordt ingeladen en daarma pas een Image object gemaakt wordt. 'Progressief' heeft ook alleen te maken met de volgorde waarin de blocks worden opgeslagen.

Dus met een StreamReader kun je de file binair uitlezen en vervolgens zo decoden en de ontvangen pixels tonen en daarna updaten naarmate meer data binnenkomt.

Succes!

[roy-t]

Het klinkt misschien gek, maar je kunt het misschien oplossen door XNA te gebruiken (I know het is voor games). Hiermee kun je een SpriteBatch gebruiken die in 1x duizenden afbeeldingen kan laten zien. (Door ze door de videokaart te laten decoderen en dan in 1 batch door de videokaart te laten tekenen op het beeld).

Je zult wel veel aan moeten passen, maar XNA kan gebruikt worden binnen een Windows Forms environment, heeft een CPU fallback voor als er geen pixelshader 1.1+ videokaart aanwezig is.

Het grootste probleem hierbij is waarschijnlijk het aanpassen van de ContentManager om on the fly die afbeeldingen te laden, maar mogelijk kun je dit ook anders doen (omdat je immers ook de hele .Net library kan gebruiken en mogelijk de images kan laden met een Stream, en dan via een MemoryStream er een Texture2D van kunt maken.

Anyway, longshot maar misschien krijg je het zo aan de praat als je wilt, en het is iig heel erg snel.
(niet met grote afbeeldingen gespeeld maar 10.000 kleine afbeeldingen krijg je met in 15ms op het scherm als je het in 1 batch doet)

Edit: dit verplaatst de bottleneck natuurlijk naar de HD/Image importer, maarja iig gaat het decoden/tekenen snel

[ Voor 5% gewijzigd door roy-t op 02-10-2008 16:46 ]

[Gomez12]

roy-t schreef op donderdag 02 oktober 2008 @ 16:43:

Edit: dit verplaatst de bottleneck natuurlijk naar de HD/Image importer, maarja iig gaat het decoden/tekenen snel

Niet echt, zolang je over 1GB aan compressed data blijft praten ( 1000'en multi mega pixel plaatjes ) duurt het laden gewoon lang... Probably is XNA sneller standaard zolang je vid-kaart het ondersteund.

Als je vid-kaart het niet ondersteunt vermoed ik dat de performance triest inzakt... En ik vermoed niet echt dat het default super gaming systemen zihn.

[Ruudjah]

Niet echt, zolang je over 1GB aan compressed data blijft praten ( 1000'en multi mega pixel plaatjes ) duurt het laden gewoon lang... Probably is XNA sneller standaard zolang je vid-kaart het ondersteund.

Jawel, omdat het hier gaat over één image. Niet over duizenden.
Mooie oplossing, dat XNA. Ga er eens naar kijken, aangezien ik ook veel met image processing doe. Absoluut de toekomst. Tegenwoordig krijgen steeds meer devices een videokaart (typemachines met Vista, mobiele telefoons, etcetera), aan ons dus om dat ding eens aan het werk te zetten en niet iedere keer layback-style naar de CPU te gaan. En dan vervolgens te zeggen dat de CPU te traag is voor die bewerkingen. Zo creeeren we wel heel makkelijk het excuus (sorry: de CPU kan het niet, dus doen we het maar niet).
'ns kijken of we een performante thumbnail generator on-the-fly kunnen maken met XNA/ de GPU.

[Gomez12]

Ruudjah schreef op donderdag 02 oktober 2008 @ 21:50:
[...]
Jawel, omdat het hier gaat over één image. Niet over duizenden.

Zie stukje meerdere afbeeldingen tegelijk tonen.

en niet iedere keer layback-style naar de CPU te gaan. En dan vervolgens te zeggen dat de CPU te traag is voor die bewerkingen. Zo creeeren we wel heel makkelijk het excuus (sorry: de CPU kan het niet, dus doen we het maar niet).

Welk excuus? Afaik zijn caching praktijken heel normaal en gewoon algemeen geaccepteerd.
Als jij maar 100x150 pixels toont dan is het imho gewoon gekkenwerk om on the fly een plaatje van 2000x3000 in te laden, right tool for the right job etc.
Toon jij een image verkleind dan heb je volgens mij een makkelijke afweging te maken, gebeurt dit eenmalig ( thumbnail wordt te duur om te maken dus dan maar on the fly ) of gebeurt dit meerdere keren ( mijn cpu heeft wel iets beters te doen dan continu hetzelfde plaatje te resizen, 1x resizen / thumbnailen en dan cachen is veel effectiever )

'ns kijken of we een performante thumbnail generator on-the-fly kunnen maken met XNA/ de GPU.

Lijkt me vrij sterk, misschien wel, maar volgens mij kan je de image niet meer terug krijgen...

[Stukfruit]

Ruudjah schreef op donderdag 02 oktober 2008 @ 21:50:
[...]

Jawel, omdat het hier gaat over één image. Niet over duizenden.
Mooie oplossing, dat XNA. Ga er eens naar kijken, aangezien ik ook veel met image processing doe. Absoluut de toekomst. Tegenwoordig krijgen steeds meer devices een videokaart (typemachines met Vista, mobiele telefoons, etcetera), aan ons dus om dat ding eens aan het werk te zetten en niet iedere keer layback-style naar de CPU te gaan. En dan vervolgens te zeggen dat de CPU te traag is voor die bewerkingen. Zo creeeren we wel heel makkelijk het excuus (sorry: de CPU kan het niet, dus doen we het maar niet).
'ns kijken of we een performante thumbnail generator on-the-fly kunnen maken met XNA/ de GPU.

Vergeet je niet de heerlijk "performante" leessnelheid vanuit het videogeheugen bij je enthousiasme in te calculeren?

[Ruudjah]

Welk excuus?

sorry: de CPU kan het niet, dus doen we het maar niet

dus bijvoorbeeld

Best maar dan moet je geen belachelijke eisen gaan stellen en gewoon je neer leggen bij het feit dat je wat 'magie' gaat nodig hebben. Dat is preloaden/thumbnailen/cachen/whatever maar in een seconde door tig fotos van tig MB heen raggen gaan je, al scrollend, gewoon niet lukken en al zeker niet vanuit een .Net managed omgeving; hooguit als je specialized code in assembly gaat zitten fröbelen of high-performance 3rd party libs ofzo gaat gebruiken en dan nog is het twijfelachtig en dien je behoorlijk stevig in je schoentjes te staan.

Oftewel: De CPU moet het uitvoeren, en daarom wordt het een moeilijk verhaal. Ik zeg: Je gebruikt de CPU als excuus voor het niet willen implementeren van on-the-fly thumb generatie. Gebruik de GPU, en de user wacht niet op die thumb, omdat ie in 50msec voor z'n neus staat. Of ie nou gecached is of niet. Ergo: geen progressive loading technieken of voortgangsbalkjes. Omdat die simpelweg irrelevant zijn geworden door de processingtijd.

Als jij maar 100x150 pixels toont dan is het imho gewoon gekkenwerk om on the fly een plaatje van 2000x3000 in te laden, right tool for the right job

Soms werkt caching niet of is ongewenst. Wat als de user de window resized, zodat de thumbnails groter/kleiner worden? Dan moet je hoe dan ook thumbnails gaan resizen. Bovendien: Een GPU is gemaakt voor dit soort dingen. Waarom zouden we hem dan niet gebruiken? Tuurlijk moet je een vorm van caching gebruiken, anders wordt het wel heel jammer, iedere keer dezelfde berekeningen doen. Zoals we zowat alles cachen in software zal je ook hier caching moeten gaan toepasen. Je zegt het verder zelf al: right tool for the right job. Een GPU gebruiken om thumbs te genereren dus, niet een CPU. Die is daar nogal slecht in ivm een GPU. Jammer is alleen dat die 'tool' (GPU voor image taken) nog niet goed ontwikkeld is (high level API's zijn er nog nauwelijks, of niet eens (XNA?)). Als je stelt dat een CPU the right tool is, heb je het IMHO niet begrepen.

Vergeet je niet de heerlijk "performante" leessnelheid vanuit het videogeheugen bij je enthousiasme in te calculeren?

AFAIK is videogeheugen meestal sneller dan normaal werkgeheugen. Ik heb geen kennis van hoe je videogeheugen in general purpose functionaliteit aanspreekt, maar het lijkt me niet dat dit nu erg langzaam gaat.

[roy-t]

Gomez12 schreef op donderdag 02 oktober 2008 @ 22:04:
[...]

Zie stukje meerdere afbeeldingen tegelijk tonen.


[...]

Welk excuus? Afaik zijn caching praktijken heel normaal en gewoon algemeen geaccepteerd.
Als jij maar 100x150 pixels toont dan is het imho gewoon gekkenwerk om on the fly een plaatje van 2000x3000 in te laden, right tool for the right job etc.
Toon jij een image verkleind dan heb je volgens mij een makkelijke afweging te maken, gebeurt dit eenmalig ( thumbnail wordt te duur om te maken dus dan maar on the fly ) of gebeurt dit meerdere keren ( mijn cpu heeft wel iets beters te doen dan continu hetzelfde plaatje te resizen, 1x resizen / thumbnailen en dan cachen is veel effectiever )


[...]

Lijkt me vrij sterk, misschien wel, maar volgens mij kan je de image niet meer terug krijgen...

code:

RenderTarget.GetTexture();

Maar als je dan toch zoiets (lichtelijks omslachtigs) gebruikt wil je het natuurlijk ook meteen door je videokaart op het beeld laten renderen.

[Gomez12]

Ruudjah schreef op donderdag 02 oktober 2008 @ 22:51:
[...]
Oftewel: De CPU moet het uitvoeren, en daarom wordt het een moeilijk verhaal. Ik zeg: Je gebruikt de CPU als excuus voor het niet willen implementeren van on-the-fly thumb generatie. Gebruik de GPU, en de user wacht niet op die thumb, omdat ie in 50msec voor z'n neus staat. Of ie nou gecached is of niet.

A : Je moet een GPU hebben die dit ondersteunt, anders is het waarschijnlijk alleen maar langzamer
B : Dingen als GPU gebruiken zijn highly experimental op dit moment, je kan het doen als je de juiste kennis hebt, maar kan jij de performance garanderen als er op de achtergrond nog een app gebruikt maakt van de GPU ( dingen als pipelining optimalisatie etc zijn voor een CPU allemaal geregeld, ik durf niet met zekerheid te zeggen dat dit ook opgaat voor een GPU )
Oftewel, je gaat je heel erg ophangen aan een GPU die er misschien niet is, misschien iets anders aan het doen is. En op die momenten klapt je performance in elkaar, wil je daarvan afhankelijk zijn?
Heel simpel voorbeeld, straks gaan mensen je app gebruiken in een Terminal Server / Citrix omgeving zonder GPU kan jij dan nog enige garanties geven over performance?

[...]
Soms werkt caching niet of is ongewenst. ....
Tuurlijk moet je een vorm van caching gebruiken, anders wordt het wel heel jammer, iedere keer dezelfde berekeningen doen. Zoals we zowat alles cachen in software zal je ook hier caching moeten gaan toepasen.

Moet hij nu wel of geen caching toepassen volgens jou?

Je zegt het verder zelf al: right tool for the right job. Een GPU gebruiken om thumbs te genereren dus, niet een CPU. Die is daar nogal slecht in ivm een GPU.

Op desktop gaming machines misschien, als het een zakelijke app is die gebruikt kan worden in Terminal Server / Citrix omgevingen dan wordt het een iets ander verhaal. CPU is een bekend gegeven, GPU is een variabele afhankelijk of het beschikbaar is...

Als je stelt dat een CPU the right tool is, heb je het IMHO niet begrepen.

Over het algemeen bij een algemene app zeg ik toch echt dat een CPU the right tool is. Het is namelijk de enige zekere tool die je hebt. GPU kan sneller zijn, maar is geen zekerheid...
Beetje app moet toch wel een beetje consistente performance kunnen afgeven, niet afhankelijk zijn van wat voor GPU er in zit.

[LauPro]

Ruudjah schreef op donderdag 02 oktober 2008 @ 21:50:
[...]
Mooie oplossing, dat XNA. Ga er eens naar kijken, aangezien ik ook veel met image processing doe.

XNA is gewoon een toolkit om eenvoudig audiovisuele toepassingen te maken, het decoden van JPEG's is nooit een taak van een GPU, die gaat namelijk over grafische berekeningen bijvoorbeeld met het renderen van een scene.

Bij een GPU gebruikt men over het algemeen geen compressie om juist de doorvoersnelheid zo hoog mogelijk te houden. Sowieso worden resources tot in het oneindige geschaald, decoderen van een bronformaat is dan alleen maar overhead. Ik kan mij hooguit voorstellen dat er MPEG4-achtige chips zijn die bepaalde formaten eenvoudig verwerkbaar maken maar ik heb nog nooit zoiets gehoord voor JPEG icm GPU's. En bovendien is JPEG een opslagformaat en in principe niet geoptimaliseerd voor een supersnelle weergave (afhankelijk van wat parameters natuurlijk).

Verder gaat het met de gebruikelijke gefragmenteerde bestandssystemen redelijk kansloos worden om binnen een seconde meerdere (10+ als we het hebben over 100ms) bestanden van 4MB in te lezen.

[Stukfruit]

Ruudjah schreef op donderdag 02 oktober 2008 @ 22:51:
AFAIK is videogeheugen meestal sneller dan normaal werkgeheugen. Ik heb geen kennis van hoe je videogeheugen in general purpose functionaliteit aanspreekt, maar het lijkt me niet dat dit nu erg langzaam gaat.

Ja, het is sneller, maar hou je ook rekening met de extra copieen die er in bepaalde gevallen tussen hangen? De langere pipeline waar al je bewerkingen doorheen gaan? Het langzame uitlezen van het videogeheugen? (alleen schrijven is redelijk snel, voor zover ik weet)

En dat XNA.. tja, de marketingheren van Microsoft zullen het vast de beste uitvinding sinds gesneden brood vinden, dat geloof ik best.

[Ruudjah]

Even checken of je een GPU hebt zou geen grote moetie moeten zijn. Heb je geen GPU, kies je gewoon een ander render methode.

Dingen als GPU gebruiken zijn highly experimental op dit moment, je kan het doen als je de juiste kennis hebt, maar kan jij de performance garanderen als er op de achtergrond nog een app gebruikt maakt van de GPU ( dingen als pipelining optimalisatie etc zijn voor een CPU allemaal geregeld, ik durf niet met zekerheid te zeggen dat dit ook opgaat voor een GPU )

Kennis kan je verschaffen. Koop een boek, lees de overlopende stapel, lees het internet. Hoe het zit met performance als je meerdere dingen tegelijk doet met een GPU weet ik niet, maar ik kan me zo voorstellen dat hier wel aardig wat mouwen aan te passen zijn. Zoals: kies de CPU als de GPU het erg druk heeft.

Op desktop gaming machines misschien, als het een zakelijke app is die gebruikt kan worden in Terminal Server / Citrix omgevingen dan wordt het een iets ander verhaal. CPU is een bekend gegeven, GPU is een variabele afhankelijk of het beschikbaar is...

Ff checken of we een GPU kunnen gebruiken dus.

Beetje app moet toch wel een beetje consistente performance kunnen afgeven, niet afhankelijk zijn van wat voor GPU er in zit.

Juist bij GPU's heb ik het idee dat die dingen consistent presteren. Als een game hapert is dat echt de fout van de level designer/engine designer. Veel software hapert doordat het van disk moet lezen, omdat de CPU 100% staat te stampen... Ik heb nog nooit gehad dat de GPU te druk was zodat ik moest wachten. Jij wel?

Bij een GPU gebruikt men over het algemeen geen compressie om juist de doorvoersnelheid zo hoog mogelijk te houden.

Bij een GPU wordt juist wel en nogal veel compressie toegepast. Ook lossy compressie, als ik me niet vergis, maar dan is het nauwelijks zichtbaar. Als je data voor 50% kan comprimeren, heb je dus een tweevoudige doorvoersnelheid.

Verder gaat het met de gebruikelijke gefragmenteerde bestandssystemen redelijk kansloos worden om binnen een seconde meerdere (10+ als we het hebben over 100ms) bestanden van 4MB in te lezen.

Tsjah. De persistente storage wordt dan inderdaad de bottleneck.

[roy-t]

Stukfruit schreef op vrijdag 03 oktober 2008 @ 11:09:
[...]


Ja, het is sneller, maar hou je ook rekening met de extra copieen die er in bepaalde gevallen tussen hangen? De langere pipeline waar al je bewerkingen doorheen gaan? Het langzame uitlezen van het videogeheugen? (alleen schrijven is redelijk snel, voor zover ik weet)

En dat XNA.. tja, de marketingheren van Microsoft zullen het vast de beste uitvinding sinds gesneden brood vinden, dat geloof ik best.

*hier moest ik even hardop om lachen*

XNA is niet meer en niet minder dan 'Managed DirectX Framework', een erg goede met leuke extra's. Maar het is niet de heilige graal, ik opperde alleen een mogelijkheid naast CUDA en dergelijke, dit gebruikt gewoon DirectX en is daarom wat vaker te gebruiken (niet Nv only). Verder kun je zelf shaders schrijven die bijvoorbeeld een JPEG zouden kunnen decoderen, of iig sneller tekenen dan een ImageBox.

(Btw, ik werk zelf erg veel met XNA, vind het prachtig net als veel indie-gamedevelopers en andere mensen die graag wat met de videokaart doen, om nu MS-Marketing er weer bij te halen met een statement dat nergens opslaat, tsja dat kan ik alleen maar zien als een soort van antifanyboy, volgens mij heb je het zelfs nooit gebruikt, wat toch wel een vereiste is voordat je er zoiets over kan zeggen.)

(en imho is gesneden brood niet zo revolutionair )

Ik blijf er nogsteeds bij dat XNA of een andere videokaart oplossing een long-shot is, maar als je iets speciaals wilt zou het misschien kunnen helpen.

[Stukfruit]

Ruudjah schreef op vrijdag 03 oktober 2008 @ 14:06:
Juist bij GPU's heb ik het idee dat die dingen consistent presteren. Als een game hapert is dat echt de fout van de level designer/engine designer. Veel software hapert doordat het van disk moet lezen, omdat de CPU 100% staat te stampen... Ik heb nog nooit gehad dat de GPU te druk was zodat ik moest wachten. Jij wel?

Veel software hapert omdat het niet minstens een extra thread gebruikt voor het lezen/schrijven en/of de message loop doodgooit met te lange wachttijden. Wat heeft dat precies met de snelheid van een GPU te maken?

roy-t schreef op vrijdag 03 oktober 2008 @ 14:28:
om nu MS-Marketing er weer bij te halen met een statement dat nergens opslaat, tsja dat kan ik alleen maar zien als een soort van antifanyboy

Uiteraard.

[Gomez12]

Ruudjah schreef op vrijdag 03 oktober 2008 @ 14:06:
Even checken of je een GPU hebt zou geen grote moetie moeten zijn. Heb je geen GPU, kies je gewoon een ander render methode.

En kom je dus weer terug op de initiele vraag van dit topic.

[...]
Kennis kan je verschaffen. Koop een boek, lees de overlopende stapel, lees het internet. Hoe het zit met performance als je meerdere dingen tegelijk doet met een GPU weet ik niet, maar ik kan me zo voorstellen dat hier wel aardig wat mouwen aan te passen zijn. Zoals: kies de CPU als de GPU het erg druk heeft.

Makkelijk neergezet, maar in de praktijk zijn er zeer weinig frameworks / programmeertalen die dit standaard ondersteunen. Kijk, ik geloof bijv best dat je met assembly de snelste apps kunt maken, maar praktisch doet niemand dit meer omdat het totaal niet meer te onderhouden is met een windows omgeving.
Zolang er geen GPU-ondersteuning op een behoorlijke manier in bijv Visual Studio zit is het leuk dat het kan en voor sommige toepassingen misschien zeer geschikt, maar imho niet voor een app die even wat plaatjes moet tonen.
Daar zijn gewoon andere wel geaccepteerde oplossingen voor...

[...]
Juist bij GPU's heb ik het idee dat die dingen consistent presteren.

Hoeveel GPU's heb je getest om dit soort uitspraken te doen? Kan jij zeggen of je app snel / traag is als de klant een ATI Radeon 9800 XL heeft? Of een ATI Radeon 9700 XS? ( niet op typenrs letten, die ken ik niet en zijn 100% verzonnen )

[quote[
[...]
Tsjah. De persistente storage wordt dan inderdaad de bottleneck.
[/quote]
Dus oftewel je hebt in sommige situaties ( snelle GPU ) de bottleneck verplaatst. In andere situaties ( geen geschikte GPU ) is de bottle neck er nog steeds.
En je app heeft nog steeds snelheidsproblemen ( alleen nu misschien vanwege een andere factor )
Leg me aub nog eens een keer uit waarom ik dit discutabele traject in zou willen gaan als er gewoon proven methods ( caching / thumbnailing ) zijn die mits goed toegepast altijd goed werken...

[LauPro]

Ruudjah schreef op vrijdag 03 oktober 2008 @ 14:06:
Even checken of je een GPU hebt zou geen grote moetie moeten zijn. Heb je geen GPU, kies je gewoon een ander render methode.

Je verspreekt hier jezelf al, een GPU is een rendersysteem en geen image decoding-systeem.

Bij een GPU wordt juist wel en nogal veel compressie toegepast. Ook lossy compressie, als ik me niet vergis, maar dan is het nauwelijks zichtbaar. Als je data voor 50% kan comprimeren, heb je dus een tweevoudige doorvoersnelheid.

Het zal allemaal best dat er intern optimalisaties zijn maar het hele punt is nou juist dat je die afbeeldingen eerst bij de GPU moet krijgen, en ik geloof ik dat een GPU native een JPEG uit kan pluizen, dat gaat altijd via de CPU.

[Ruudjah]

Je verspreekt hier jezelf al, een GPU is een rendersysteem en geen image decoding-systeem.

GPU=Graphics Processing Unit. Een plaatje == graphics. Decoden=processen van imagedata. In theorie zou je dus best mogen verwachten dat een GPU een image decode en vervolgens rendert (resizen/resamplen). Maar, zoals gezegd: Er zijn nog geen Nvidia/AMD/Intel libraries die dit soort dingen op hoog niveau implementeren. Dus een API waarbij je in Java/C# kan doen GPU.LoadImage(bestand). Of dat de windowmanager dit automagisch voor z'n rekening neemt.

Het zal allemaal best dat er intern optimalisaties zijn maar het hele punt is nou juist dat je die afbeeldingen eerst bij de GPU moet krijgen

In het alternatieve verhaal (de CPU gebruiken), moet je de afbeeldingen eerst bij de CPU krijgen. Ik zou zeggen dat je liever je imagedata bij de GPU sneller hebt, aangezien het uiteindelijk er toch weer heen moet. Nadat je een image decodede, moet je ervoor zorgen dat je GPU ergens die data weer krijgt en gaat renderen (dus resamplen/resizen en op je juiste plaats op het scherm toveren). In het geval dat je de GPU gebruikt voor het decoden, lijkt me dat dus efficienter. Imagedata gaat dan PS -> RAM -> Southbridge -> PCIE -> GPU (decoden) -> GPU (renderen) -> scherm in plaats van
PS -> RAM -> CPU (decoden) ->RAM -> Southbridge -> PCIE -> GPU (renderen) -> scherm. Hij gebruikt de CPU voor het decoden (wat in theorie toch echt inefficienter en trager is dan een GPU) en hij gebruikt extra RAM geheugen (voor het gecodeerde image en gedecodeerde image). Alhoewel ik me afvraag hoe de WinForms API omgaat met imagedata die in een control zit; zou best kunnen dat via meer omwegen uiteindelijk bij de GPU terecht komt. If at all (dus dat de CPU direct op een canvas gefaciliteerd door de GPU schrijft).

[Gomez12]

Ruudjah schreef op donderdag 09 oktober 2008 @ 06:53:
[...]
Maar, zoals gezegd: Er zijn nog geen Nvidia/AMD/Intel libraries die dit soort dingen op hoog niveau implementeren.

Dus gewoon niet doen zolang je prog niet voor 99% op graphics verkoopt, dan zit je 100x zo veel uren te maken tegen een hele kleine winst ( de mensen zonder GPU maken hier namelijk geen gebruik van... )

[...]
Alhoewel ik me afvraag hoe de WinForms API omgaat met imagedata die in een control zit; zou best kunnen dat via meer omwegen uiteindelijk bij de GPU terecht komt. If at all (dus dat de CPU direct op een canvas gefaciliteerd door de GPU schrijft).

Gok zomaar even dat winforms hier vrij weinig mee doet. Hence the name forms... Het is op dit moment voor een applicatie anders dan een game gewoon een zeer twijfelachtige micro-optimalisatie vanwege tijd / baten verhouding...
Misschien dat het over 2 tot 5 jaar interessant wordt omdat er dan misschien genoeg GPU's zijn om high-level api's te maken vanuit fabrikanten waarna programmeeromgevingen er library's etc van kunnen maken...

Maar op dit moment is het gewoon totaal niet relevant zolang je niet voor 99% afhankelijk bent van graphics....

[Ruudjah]

Het is nu niet echt een micro-optimalisatie. Het is nu niet dat we if/else statements aan het vervangen zijn door switch statements, omdat die beter kunnen worden geoptimaliseerd door de post compiler. Het gaat hier om een fundamenteel andere manier van het benaderen van image data.
Het gaat hier om het verschil tussen wel of geen rich user experience. Dat noem ik nu niet een micro-optimalisatie. Als we het wél implementeren, kunnen we in theorie een megapixel preview op het scherm toveren in een fractie van de tijd dan dat de CPU hiervoor nodig zou hebben. Dat zorgt op zijn beurt weer voor een veel betere user experience: Megapixel image previews gaan opeens een stuk rapper. Zó rap, dat de user niet echt een laadbalkje meer nodig heeft. Althans, dat is de theorie (welke min of meer bewezen is door de verschillende special purpose GPU software als games, die nogal met imagedata werken).

Gok zomaar even dat winforms hier vrij weinig mee doet.

Assumption ...

Je hebt natuurlijk gelijk dat vanuit het oogpunt van de business case de optimalisatie minder relevant is, en andere technieken misschien een betere ROI hebben.