|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Skalieren und so | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 3 | [ - Beitrag schreiben - ] |
|
27.08.2011, 17:37 Uhr Der_Wanderer Posts: 1229 Nutzer |
Dieser Thread geht über das Skalieren von Bildern, und welchen Algorithmus man am besten dafür wählt. Gundsätzlich kann man Hoch- (Anzahl der Pixel erhöhen, engl. upscaling) oder Runterskalieren (Anzahl der Pixel verringern, engl. downscaling). Hochskalieren Informationstheoretische Betrachtung: Zum Speichern eines Bildes ist Hochskalieren wenig sinnvoll, da man keinerlei neue Information hinzufügt, sondern lediglich die gleiche Information mit mehr Pixeln darstellt. Da ein Kompressionsalgorithmus wie zlib oder JPEG das nicht weis, versucht er die Information dann so zu packen als könnte jedes neue Pixel komplett Information enthalten. Die daraus resultierende Datei ist i.A. größer, auch wenn keinerlei Information dazu gekommen ist. Als Beweis könnte man sich einen Algorithmus vorstellen, der das Hochskaliere Bild wieder exakt auf das original Bild herunterskaliert, speichert, und beim entpacken das Original lädt und wieder hochskaliert. Damit ist gezeigt, dass es einen Algorithmus gibt, der das Hochskalierte Bild genauso klein packen kann wie der beste vorstellbare Packer des Originalbildes. Es kann also keine neue Information dazu gekommen sein. Beispiel für Hochskalieren: Original 3x3 => Nearest Neighbour / Lineare Interpolation / Cosinus Interpolation: Bild: http://www.hd-rec.de/pics/int_none.png => Bild: http://www.hd-rec.de/pics/int_nn.jpg Bild: http://www.hd-rec.de/pics/int_lin.jpg Bild: http://www.hd-rec.de/pics/int_cos.jpg Hochskalieren kann sinnvoll sein, wenn man eine bestimmte Auflösung liefern muss, und das eigene Bild ist kleiner, z.b. um es Vollbild anzuzeigen. In der Regel ist ein Hochskalieren aber nicht erstrebenswert, da das Resultat in der ein oder anderen Form immer unscharf oder seltsam detailarm aussieht. Eine kleine Ausnahme gibt es dennoch, das sog. "Hollywood Scaling". Man kennt das aus Filmen oder Serien wie CSI, wenn das Standbild einer Sicherheitskamera grossgezoomed wird, das zunächst furchbar noisy und unscharf ist, dann aber durch einen Filter (der auf die Frage "Kriegen Sie es noch ein wenig schärfer?" reagiert) wieder "scharf" gemacht wird, sodass neue Details erkennbar werden die vorher nicht zu sehen waren. Das geht natürlich auch mehrmals hintereinander bis man den Mörder erkennen kann ;-) Das geht in Wirklichkeit aber nur, wenn neue Information dem Bild hinzugefügt wird, die vorher nicht im Bild war. Und das geht tatsächlich. Man versucht dabei aus einer (sehr grossen) Bilder-Datenbank (wie z.B. dem Internet) Teile wiederzuerkennen, die im eigenen, durch Hochskalieren unscharf gewordenen Bild vorkommen. Der Ausschnitt aus der Datenbank, z.B. ein Gesicht, das eine höhere Auflösung besitzt, ergänzt dann die hohen Frequenzen im unscharfen Bild (unscharf = mangel an hohen Frequenzen). Die so neu gewonnen Information sind allerdings nur geraten, und nicht aus der Wirklichkeit abgeleitet, sodass man natürlich keine kriminalistischen Schlüsse daraus ziehen kann. Für das Auge sieht es trotzdem plausibel aus. Für unsere Amigas ist das aber sowohl vom Rechenaufwand als auch vom Speicheraufwand utopisch, und in unserer limitieren Freizeit auch nicht nachprogrammierbar (... obwohl? ;-) Es gibt noch weitere Tricks, wie man ein Hochskalieren kann ohne "unscharf" zu werden. Oft macht das aber nur für eine ganz bestimmte Anwendung oder Bilder-Art Sinn. Z.b. der HQ3x Algorithmus (http://www.hiend3d.com/hq3x.html) versucht Linien/Muster zu erkennen und durch eine feinere Auflösung zu ersetzen. Bei Farb-Indizierten oder comichaften Bildern, wo sich die Farbe nicht ständig von Pixel zu Pixel ändert, kann man damit ganz gute Ergebnisse erzielen. Bei Emulatoren von Systemem mit niedriger Auflösung (C64, Amiga OCS/AGA) kann man oft durch sog. Scannlines die Auflösung verdoppeln, wobei jede zweite Zeile einfach keine Information, nur einen schwarzen Balken enthält. Man überlässt dann dem Gehirn, sich die zusätzliche Information dazu zu denken, was erstaunlich gut funktioniert. Oft wird hier auch das simple Wiederholen der Pixel und die daraus resultierenden Pixel-Blöcke als besser empfunden als eine Interpolation, die das Bild unscharf macht. Für Fotos oder beliebige Bilder sind solche Verfahren aber alle nicht geeignet. Beispiele: Original => Normale Interpolation / Pixel Verdopplung, Nearest Neighbour / Scanlines / HQ3x Bild: http://www.hd-rec.de/pics/randam_orig.png => Bild: http://www.hd-rec.de/pics/randam_lin.png Bild: http://www.hd-rec.de/pics/randam_nn3x.png Bild: http://www.hd-rec.de/pics/randam_sl3x.png Bild: http://www.hd-rec.de/pics/randam_hq3x.png * Bild genommen von http://www.hiend3d.com/hq3x.html Runterskalieren Beim Runterskalieren verringert man die Anzahl der Pixel im Vergleich zum original Bild, und verliert daher Information. Die resultierende Datei ist dann i.A. kleiner als das original Bild, was oft der Hauptgrund des Herunterskalierens ist. Der Vorgang ist aber nicht mehr umkehrbar. Die JPEG Kompression nutzt z.B. Herunterskalieren, um Bilder noch kleiner zu packen (allerdings nur der Farbe, nicht der Helligkeit, weil unser Auge für Helligkeit sensibler ist als für Farbgebung). Neben dem Einsparen von Speicher gibt es für das Herunterskalieren viele weitere Gründe. Z.B. man möchte ein Foto auf dem Bildschirm anzeigen, das heutzutage oft in einer sehr viel höheren Auflösung als die des Bildschirms vorliegt. Beim Bearbeiten von Grafiken ist es oft vorteilhaft, in einer höheren Auflösung zu arbeiten, als das Bild später benötigt wird. Das nennt man auch Super-Sampling. Zum einen werden dadurch kleinere Fehler und Ungenaugigkeiten verziehen, man bekommt Anti-Aliasing geschenkt und hält sich die Möglichkeit offen, verschiedene kleinere Größen zu erzeugen, z.B. bei Icons. Bild: http://www.hd-rec.de/pics/aiss_save_c7.png (hier im Vergleich mit AISS, die nur in 24px vorliegen, wodurch der Anwendungsbereich eingeschränkt wird) Man erhält deutlich bessere Ergebnisse, wenn man z.B. in 400px arbeitet und daraus eine 100px und 90px Version erzeugt, als wenn man in 100px arbeitet und daraus eine 90px Version erzeugt. Das liegt daran, dass die 400px Version mehr Informationen enthält wo genau die Farbwerte im 90px Bild liegen müssen. Generell sind Skalierungsfaktoren zwischen 0.5 und 1.0 unvorteilhaft, was am Aliasing liegt. Bild: http://www.hd-rec.de/pics/400_90x.png Die Skalierung von 100=>90px lässt das Bild (oben) deutlich mehr vermatschen als die Skalierung von 400=>90px, obwohl die Skalierung von 400=>100px durch den ganzzahligen Faktor sehr gut gemacht werden kann. Aliasing Beim Runterkalieren hat man nicht das Problem (Pseudo-)Information hinzufügen zu müssen, sondern Information wegzuschmeissen. Das ist in der Regel sehr viel einfacher. Aber es wäre zu schön, wenn es da nicht noch das Problem mit dem Aliasing gäbe. Wenn wir ein Bild herunterskalieren, können wir die feinsten Details (=hohe Frequenzen) des original Bildes nicht mehr darstellen. Wenn wir nichts unternehmen, und das Bild einfach neu abtasten, dann kann es sein dass wir wichtige Punkte im Bild überspringen, z.b. eine dünne Linie. Dadurch können unerwünschte Effekte im Bild auftreten, die man Aliasing nennt. Um dem entgegen zu wirken muss man vor dem Runterskalieren also erstmal alle Details entfernen, die in der Zielauflösung nicht dargestellt werden können. I.A. macht man das mit einem Tief-Pass Filter. Das Resultat ist erstmal ein unscharfes Bild, dass dann aber durch Neu-Abtatung in der niedrigeren Auflösung kein Aliasing mehr aufweist und der Auflösung entsprechend wieder "scharf" ist. Da es in der Natur und in der digialen Welt keinen perfekten Filter gibt, vor allem was die flankensteilheit anbelangt ist nun auch klar, warum Skalierungsfaktoren zwischen 0.5 und 1.0 unvorteilhaft sind. Um Aliasing zu vermieden, muss man hohe Frequenzen herausfiltern. Da die Flankensteilheit aber nicht unandlich ist, muss man zu viel wegfiltern und das Resultat ist etwas unschärf. Oder man filtert gar nicht, bekommt dann aber Aliasing Effekte. Original => Bild: http://www.hd-rec.de/pics/scalingtest.png => Nearest Neighbour / Lineare Interpolation / Window Interpolation / Weighted Window Interpolation Bild: http://www.hd-rec.de/pics/scalingtest_nn2.png Bild: http://www.hd-rec.de/pics/scalingtest_lin2.png Bild: http://www.hd-rec.de/pics/scalingtest_win2.png Bild: http://www.hd-rec.de/pics/scalingtest_gui2.png * Neaest Neighbour: Man sieht deutlich, wie einzelne Linien verloren gehen, weil sie übersprungen werden * Linear Interpolation: Schon viel besser, aber da vorher kein Tiefpass Filter angewand wurde, "verpasst" auch die lineare Interpolation ein paar Details. * Window Interpolation: Die Window Interpolation hat automatisch einen Tiepass Filter mit drin, und "verpasst" daher kein Detail, allerdings werden die dünnen linien grau, obwohl sie vorher schwarz waren. * Weighted Window Interpolaton: Hier werden Farbwerte höher gewichtet, die lokal seltener sind. Dadruch bleiben die schwarzen Linien fast schwarz, Details werden nicht mit dem Hintergrund verschmolzen und drohen unterzugehen. Nachteil ist, dass die Geometrie die Pixel leidet, z.B. die Abstände der Linien scheint nicht mehr äquidistant zu sein. Man sieht auch schön, dass bei dem grossen unscharfen Fleck so gut wie kein Unterschied besteht, egal welche Interpolation und mit oder ohne Tiefpass, weil der Fleck nur aus tiefen Frequenzen besteht. Gefahr durch Aliasing besteht hier also nicht. Algorithmen Es gibt viele verschiedene Algorithmen zum skalieren. Man könnte sie grob so einteilen: 1. Simple Neuabtastung (Nearest Neighbour) Vorteile: sehr schnell, farbentreu (das Zielbild enthält nur Farbwerte die im Original auch vorkommen, daher praktikabel für farb-indizierte Grafiken) Nachteile: ohne Tiefpass Filter Aliasing Effekte, Unstetigkeiten im Bild (Treppeneffekte) 2. Neuabtastung mit Interpolation (linear, cosinus, quadratisch, cubisch, sinc/lanscoz, splines) Vorteile: keine Unstetigkeiten/Treppeneffekte Nachteile: Je nach Interpolationsmethode deutlich aufweniger/langsamer 3. Algorithmen die den Inhalt des Bildes interpetieren (Weighted Widnow/Entropy, HQ3x) Vorteile: In speziellen Fällen oft deutlich bessere Skalierung Das wird dadruch erreicht, dass ein Bild nicht starr neu abgetastet wird, sondern bestimmte Kriterien angelegt werden, welcher Pixel wie viel Beitrag zum Zielpixel leisted. Z.b. kann ein Nearest Neigbour beim herunterskalieren so modifiziert werden, dass er Pixel überspringt die ähnlich zu bereits übernommenen Pixeln sind, und Pixel bevorzugt, die deutlich anders sind als die Umgebung. Dadurch können Details erhalten bleiben. Nachteile: aufwendig, nicht generell einsetzbar, manchmal unpassende Vorhersage und dadurch Artefakte Beispiel: Weighted Window Interpolation (funktioniert gut für kleine Icons): Bild: http://www.hd-rec.de/pics/iconscale2_c.png Lineare Interpolation / Entropy Weighted / Original Nach all dieser Theorie möchte ich jetzt die Suche nach einem praktikablen Algorithmus starten da ja des öfteren Kritik geäussert wurde. Dabei hoffe ich auf eure Mithilfe. Diese Algorithmen würde ich dann in meinen Algorithmen Pool aufnehmen, der Hauptsächlich in Amiblitz3 abgebildet ist (als App zu finden z.B. in iBatch oder dem ImageConverter oder NTUI), allerdings nutze ich diese Dinge auch woanders. Beurteilung der Algorithmen Die Geschwindigkeit könnte man unterteilen in * echtzeitfähig (<<20ms@1MP) * schnell (<1s@1MP) * langsam (<10s@1MP) * experimentell (>10s@1MP). Anmerkung: 1MP = 1 Megapixel, also ein Bild mit etwa 1000x1000 Auflösung oder z.B. die gängige Laptop Auflösung 1280x800. "Echtzeit" ist heutzutage eher uninteressant, weil das die Hardware macht, und ohne HW kommt eigentlich nur NN in Frage oder linear ohne AA Filter. "Schnell" sollte so laufen, dass man damit eine Stapelverarbeitung in erträglicher Zeit durcharbeiten kann, z.B. ein Verzeichnis mit Fotos auf Website größe oder Thumbnails zu skalieren. Oder in einem Spiel Grafiken auf die gewählte Auflösung skaliert, wie in AmegaOne oder PanZers. Mit "langsam" wäre das auch möglich, aber auf schwächeren Rechnern kaum noch erträglich, da er Minuten bis Stunden oder gar über Nacht laufen müsste. Und bei "experimentell" spielt die Zeit keine Rolle, es geht nur um das Ergebnis. Der Rechner darf also ruhig einen Tag lang am Ergebnis rechnen. Die Qualität in * schlecht * zur Darstellung geeignet * zur Verarbeitung geeignet * ausserordentlich "Schlecht" wäre, wenn man deutliche Artefakte sieht, z.B. NN., das Bild also wirklich kein Augenschmaus mehr ist. "Zur Darstellung geeignet" wäre die Qualität in einem Bildbetrachter oder in einem Thumbnail, aber noch nicht gut genug um das in einem Grafikbearbeitungsprogram zu akzeptieren. (z.B. linear?) "Zur Verarbeitung geeignet" wäre die Qualiät, wenn man damit bedenkenlos sein Fotoalbum skalieren könnte für eine Website oder Grafiken auf ihre finale Auflösung in einer GUI bringt. "ausserordentlich" ist alles, was überdurchschnittlich gute Qualität liefert, die auch von Photoshop oder anderen Referenzprogrammen nicht übertroffen wird. Test-Bild Damit man Algorithmen vergleichen kann, sollte man auch das gleiche Bild skalieren. Dabei ist es wichtig, dass in dem Bild alles vertreten ist was man testen möchte. Vorschläge? -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
27.08.2011, 18:18 Uhr inq Posts: 445 Nutzer |
@Der_Wanderer: Sehr viel Text, ich muß schon sagen  Dar war mal was Vielversprechendes zum Thema of Golem zu lesen: Golem Artikel Konnte das w.u. verlinkte PDF allerdings noch nicht runterladen. allerdings ist mit Beispielen auch gut erklärt, wie es funktioniert. Für Leute, die Zeit haben, einen eigenen Algo daraus zu basteln. gruß inq [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 11:32 Uhr Doc Posts: 355 Nutzer |
@inq: Ich hatte den Artikel vor einiger Zeit gelesen. Für eine Echtzeittransformation in Emulatoren scheinen mir heutige Rechner zu langsam zu sein(?). Die Heuristik, mit der "ideell" verbundene Pixel ermittelt werden, klingt aber sehr brauchbar. Wenn man sich auf eine (z.B.) Vervierfachung oder besser Verneunfachung der Auflösung beschränken kann, könnte man die Vektorisierung vielleicht fortlassen und verbundene Pixel durch einfaches Setzen neuer Pixel an den entsprechenden Stellen hervorheben. Die Bildelemente werden so zwar nicht 'runder', aber Kanten bleiben gewahrt und keine Unschärfe wird eingeführt. Das Ergebnis einer solchen Transformation würde ich gerne mal sehen :-). -- C= A4000/030/882, 25MHz, 16MB, OS3.0 [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 13:40 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ich hoffe der lange Einleitungstext hat nicht zu viele abgeschreckt!  Also eigentlich geht es hier darum, erstmal einen gewöhnlichen Skalierungsalgorithmus auszuwählen der für allgemeine Zwecke gut funktioniert, ohne dass z.B. zu iBatch immer Kommentare kommen über die angeblich schlechte Skalierungsqualität. eigentlich bin ich auch der Meinung, dass Window-Scaling vollkommen ausreicht, aber lasse mich gerne eines besseren belehren. Dinge wie Vektorisieren oder HQ3x sind Spezial-Algorithmen für ein Nischenproblem, das ich in meiner Abhandlung der Vollständigkeit halber aufgeführt habe. Wirklich interessant ist das für den Thread erstmal nicht. Also dann werde ich mal ein Test-Bild generieren und die Ergebnisse meiner bisher implementierten Algorithmen vorstellen. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 14:55 Uhr Doc Posts: 355 Nutzer |
@Der_Wanderer: Er hat nicht abgeschreckt, sondern ist interessant :-). Generell würde ich immer bikubisch interpolieren, wenn über das anzuzeigende Bild automatisch keine relevanten Informationen abzuleiten sind, die etwas anderes hergeben. Das Ergebnis sieht nie schlecht aus und ist nur um einen nicht allzu großen Faktor langsamer als lineare Interpolation. Die Gleichungen aus dem LGS lassen sich ja im Vorfeld hinschreiben und sind trivial. Für die Anzeige kann man sich dazu auf die dargestellte Auflösung beschränken und muss nicht das ganze Bild skalieren. So sehe ich das jedenfalls. -- C= A4000/030/882, 25MHz, 16MB, OS3.0 [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 17:04 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer Nur kurz, da im Augenblick wenig Zeit: Bisher haben sich erst zwei Leute (Anonym) über AmiBlitz/iBatch Skalierungsqualität beschwert (Von über 1000 Downloads V 1.0 bis 1.2). Also nicht überbewerten. Wie auch immer, zum Thema Qualität, habe ich viel getestet: http://www.geobiz.de/QA/testtable1.html Auch die Geschwindigkeit habe ich getestet (was nat. nur bedingt etwas über die Qualität des Algos aussagt): http://www.geobiz.de/QA/testtable2.html Da es in iBatch hauptsächlich um Fotos geht, habe ich natürlich als Testbild eins von meiner Digicam genommen und ersteinmal ins BMP Format gewandelt um dann weiter zu skalieren. Mittelfristig möchte ich div. Graphikbefehle (z.B. grausstufen erzeugen, Sepia,..., ggf. div. Skalieralgos) also Plugins realisieren, was im Hinblick auf iBatch eine komplett neue Benutzerführung und dann auch neue GUI Engine bedeutet. Wir sollten generell nicht aus dem Auge verlieren, dass a) wir schnelle Algos brauchen ggf. mit schlechterer Qualität, da unsere Rechner langsam b) ich/iBatch hauptsächlich an Downscaling von Fotos interessiert bin c) ggf. Leichtes Upscaling/Umrechnen auf div. Bildschirmformate wichtig ist d) das Windows-Scaling schon ziemlich gut ist Könnte man in Amiblitz PPC native Skalieralgos implementieren ? Gruß gerograph [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 17:27 Uhr Der_Wanderer Posts: 1229 Nutzer |
Das mit den schnellen Algos ist schon richtig, aber wenn die Qualität unbrauchbar ist, dann nützt das auch nix (Nearest Neighbour). Auch sollte das Verhältnis zum laden und Speichern des Bildes gewahrt bleiben. Es nützt nichts, wenn der NN in 10ms resized, laden und speichern des Bildes aber 2 sec dauert. Dann kann ich mir 0,5 sec leisten fürs resizen, ohne dass es auffällt. Bei dem Speed Test vom Resizen würde mich interessieren, wie der Sharpen Parameter beim Window Scaling war. Wenn er 0 ist, sollte es deutlich schneller sein. Auch beim neuesten AB3 sind ein paar Speedups drin. https://sourceforge.net/projects/amiblitz3/files -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 19:34 Uhr inq Posts: 445 Nutzer |
Zitat:Nun, ich bin da natürlich anderer Meinung. Alleine die Tatsache, daß Skalieren auf Vektorgfx wesentlich besser anwendbar ist, führt zwangsweise in eben diese Richtung. Als Beispiele sind daher im genannten Artikel ebenso GUI-Icons getestet (siehe Bildergalerie). Wie kannst du das so generell beiseite schieben? inq [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 19:35 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer: Wenn bei image_resize "@sharpness" per default gleich 0 ist, dann ist es in iBatch auch 0 ! (den Guide den ich hab schweigt sich über den resize Befehl aus...). Wie auch immer, ich nutze noch ne alte AmiBlitz Version (3.5 - 26.5.2010 - Build 0.146). Danke für den Hinweis. Zu den Speedmessungen: bei 5 Images die ich resize wird jedes geladen, dann mit image_resize{} gescaled und dann gespeichert. Zwischendurch wird noch ein Progressbar bedient. Alle anderen Programme machen das aber ähnlich. Vielleicht kostet das speichern soviel Zeit. Ich muss die 5 Bilder mal mit dem neusten ImageConverter (Link ?/ oder Aminet ?) scalen und dann Zeitnahme machen. Zitat:Richtig, aber: IrfanView auf meinem i5 arbeitet um Längen schneller, das Speichern auf dem SAM sollt aber via SATA im DMA Modus nicht deutlich länger dauern als bei meiner i5 Windows Kiste. Also muß es am Prozessor liegen. Bedeutet einzigste Optimierungsmöglichkeit ist dann der Algo an sich. [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 19:41 Uhr inq Posts: 445 Nutzer |
Zitat: Genau, ist aber aus meiner Sicht garnicht so schlimm: ich finde schon die Qualität der Resultate erstaunlich bis sensationell, wenn man mal bedenkt, daß hier nichts wirklich "neues" auf den Tisch kommt. Es ist halt sehr clever kombiniert. Auch speziell für kleine Icons, eben für so GUI-Zeugs vom Wanderer, bietet sich das doch geradezu an. Da braucht man eben nur einmal einen Durchlauf und hat dann die Pix vektorisiert. Kann nicht besser, echt. Und es ist allemal systemunhabhängig im Ergebnis. Das könnte dann selbst noch ein Uralt-Handy auf den Schirm bringen. Natürlich wäre es sowieso smarter, sofort alles in Vektoren zu gießen, klar. Will der Wanderer aber nicht?  GRuß inq [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 19:54 Uhr Doc Posts: 355 Nutzer |
@inq: Ich muss zugeben, dass ich gar nicht weiß, worum's genau geht, inq :-). Vektorisierung hat viele Anwendungen, aber zur Skalierung taugt es erstaunlicherweise oft eben nicht, es sei denn, man will unbedingt Kanten herausarbeiten und Farbflächen 'unverwässert' erhalten - dann ist's natürlich toll. Hier habe ich es aber so verstanden, dass beliebige Bilder skaliert werden sollen. Da nimmt man dann besser etwas anderes her, finde ich, insbesondere bei Fotos. -- C= A4000/030/882, 25MHz, 16MB, OS3.0 [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 20:14 Uhr Der_Wanderer Posts: 1229 Nutzer |
Also erstmal brauchen wir einen normalen Skalierungslagorithmus, bevor was experimentelles auf den Tisch kommt. Für Fotos und sonstige 24bit Grafiken, auch mit Alpha Channel. Und zwar einen der schnell und passabel ist, und einen der langsamer (aber vertretbar) ist und sehr gute Ergebnisse liefert. Und das auf beliebigen Bitmaps. Wenn man das hat, kann man sich um spezielle Geschichten kümmern. Das habe ich aber eigentlich nicht vor, wer braucht schon sowas wie HQ3x, ausser für Pixelgrafik von alten Spielen? Wie schon erwähnt, wenn man Icons resized, dann liegt das Bild in der Regel in höherer Auflösung oder als Vektor Bild bereits vor, sonst hat man was beim Erstellen falsch gemacht. Vektorisieren um danach Hochzuskalieren ist in etwa so wie Zucker in die Suppe schütten weil man sie vorher versalzen hat, eine Art Verzweiflungsakt eben, weil es keine bessere Quelle gibt. @gerograph Wenn du incl. Laden und Speichern misst, dann machst du ja eher einen Benchmark der Datatypes bzw. der Speicherroutine. Das ist nicht wirkich aussagekräftig wie schnell der eigentliche Algorithmus zum skalieren ist. Die Plattengeschwindigkeit spielt dabei auch eine verschwindend geringe Rolle. Unter Windows wird die Datei sowieso erstmal nur gecached. Wenn das speichern 1s dauert, dann sind davon 999ms das packen bzw. aufbereiten des Bildes zum abspeichern. Und da ist ein i5 halt bestimmt 50x so schnell wie der PPC im SAM. Die Dinger gehen nämlich richtig ab. Die Testbilder von dir finde ich etwas unglücklich gewählt, weil sie bereits so unscharf sind, dass es fast egal ist was für einen Algorithmus man darauf los lässt. Ich werde ein Testbild vorbereiten, was die schwächen der Algorithmen richtig bloßstellt. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 21:18 Uhr Der_Wanderer Posts: 1229 Nutzer |
So, hier wäre mein Vorschlag zu testen: Bild: http://www.hd-rec.de/pics/testpic.png Die Icons (und damit das Bild) ist mit Alpha Transparenz. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 21:34 Uhr Der_Wanderer Posts: 1229 Nutzer |
Und hier mit den von mir implementierten Algorithmen (von 512x320 => 320x200 das sind auf 62.5%) Nearest Neighbour / Lineare Interpolation (ohne Tiefpass) Bild: http://www.hd-rec.de/pics/testpic_nn.png Bild: http://www.hd-rec.de/pics/testpic_lin.png Window Scaling / Window Scaling + 0.5 sharpnes Bild: http://www.hd-rec.de/pics/testpic_win.png Bild: http://www.hd-rec.de/pics/testpic_win05.png Weighted Window Scaling (für Icons) Bild: http://www.hd-rec.de/pics/testpic_gui.png -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 22:25 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer: O.k. wie oben angemerkt, sind die "speedtests" natürlich nur bedingt aussagekräftig im Hinblick auf den Algo. Nach Deiner Auflklärung defakto garnicht. Entscheidend ist also im "täglichen" gebrauch die "Entpack" Geschwindigkeit. Verstanden. Zitat:Na ja, es sind nur kleine Ausschnitte. Das gesamte Bild wurde mit dem Automatikprogramm der Kamera aufgenommen und ist somit entsprechend scharf. Zumindest sowie im Ottonormalverbraucher Alltag üblich. Das Bild habe ich dann immer im ganzen skaliert, jeweils zwei Ausschnitte angefertigt und hoch gezoomt um besser vergleichen zu können. Vielen Dank für das Testbild, ich werde es auch mal durchjagen. Allerdings ist die Ausgangsauflösung/-größe etwas gering, da in der Regel die Digicams höhere Auflösungen liefern. Gruß Gero [ - Antworten - Zitieren - Direktlink - ] |
|
28.08.2011, 23:54 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich weiß nicht, wie IrfanView das macht, aber der Knackpunkt bei Batch-Verarbeitung lautet Parallelverarbeitung. DMA-fähige Hardware kann Daten schaufeln, während die CPU mit dem Bild beschäftigt ist. D.h. während ein Bild von der CPU verarbeitet wird, wird das vorhergehende gespeichert und das nachfolgende geladen. Die Zeit, die eine Festplatte zum Laden und Speichern jeweils eines Bildes benötigt, ist aus Sicht der CPU eine Ewigkeit, die oftmals schon an sich ausreicht, um die Skalierung durchzuführen. Klar, auf einem i5 geht das Ganze noch eine Ecke schneller, wo das Kodieren und Dekodieren auch noch auf unterschiedlichen Kernen parallel zum Skalieren ausgeführt werden kann. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 00:23 Uhr Der_Wanderer Posts: 1229 Nutzer |
@gerograph Entscheidend sind alle drei Dinge die passieren, wenn du den kompletten Vorgang misst. 1. Laden (= von Platte holen und entpacken) 2. Resizen 3. Speichern (= packen und auf Platte schreiben) Uns interessiert hier aber eigentlich nur das Resizen, und die einzelnen Programme können sich bereits sehr stark beim Laden und Speichern unterscheiden. Das Problem mit den Fotos ist, dass sie auf 1:1 Pixelebene recht unscharf sind. Deshalb hier bereits ein kleines Bild mit vielen Details. Dadurch kann man besser sehen, was der Algorithmus macht. Wenn er darauf gut funktioniert, dann sicher auch auf deinen Fotos. @holger Parallelisieren ja, aber uns interessiert hier der Algo, weniger die Anwendung oder das eigentliche Batch Processing. Der Algo kann auch für andere Dinge eingesetzt werden, z.B. bei einem Spiel um die Sprites zu skalieren oder Icons in einer GUI. Also bitte nicht Off-Topic gehen, es geht hier darum die verschiedenen Algos zum Resizen, vor allem Herunterscalieren, zu evaluieren. Die tatsächliche Laufzeit spielt auch keine so große Rolle wie die Komplexität des Algorithmus, da die Laufzeit stark von der Optimierung und dem Geschick der Implementation abhängt. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 29.08.2011 um 00:24 Uhr geändert. ] [ Dieser Beitrag wurde von Der_Wanderer am 29.08.2011 um 00:27 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 00:44 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die Praxisrelevanz sollte nicht ignoriert werden. Ich habe lediglich auf die Aussage „Bedeutet einzigste Optimierungsmöglichkeit ist dann der Algo an sich“ geantwortet. Die, nebenbei gesagt, eine Antwort auf eine Aussage von Dir war, die da lautete: Zitat:Offenbar existiert der Algorithmus doch nicht im leeren Raum… -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 10:07 Uhr gerograph Posts: 621 Nutzer |
@Holger: Klar, dieser thread beschäftigt sich mit dem Skalieralgarithmus, ich werde mal mit dem Testbild testen... Für mich stellt sich dennoch in Zukunft (also wenn ich mal an iBatch 2.0 arbeite) die Frage wie kann man die Geschwindigkeit verbessern. Da scheint einerseits das entpacken (über Datatype) ein Flaschenhals zu sein, sowie eine fehlende Paralellverarbeitung... Wie auch immer back on topic, ich werd jetzt mal mit dem Bild und irfanview testen. Gruß gero [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 10:13 Uhr Der_Wanderer Posts: 1229 Nutzer |
@gerograph Das Entpacken kannst du nicht beschleunigen. Und auch nicht parallelisieren. Das müsste der Datatype Author machen. Das Entpacken benötigt in der Regel deutlich länger als das holen der Daten von Disk. Deshalb würde ich mir darüber keinen Kopf machen was Holger da in den Raum geschmissen hat. Das gleiche gilt für das Packen, dass vermutlich nochmal deutlich länger dauert als das Entpacken. Ich mache mal bei mir einen Timing Test, damit du ein Bild davon hast wie die Relationen sind. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 10:42 Uhr gerograph Posts: 621 Nutzer |
Irfan View... einfaches Resize: Bild: http://www.geobiz.de/screenshots/320x200/resize.png hermite: Bild: http://www.geobiz.de/screenshots/320x200/hermite.png triangle: Bild: http://www.geobiz.de/screenshots/320x200/triangle.png mitchell: Bild: http://www.geobiz.de/screenshots/320x200/mitchell.png bell: Bild: http://www.geobiz.de/screenshots/320x200/bell.png b-spline: Bild: http://www.geobiz.de/screenshots/320x200/bspline.png lanczos: Bild: http://www.geobiz.de/screenshots/320x200/lanczos.png [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 11:28 Uhr Holger Posts: 8116 Nutzer |
Zitat:Selbstverständlich kann man das parallelisieren. Einfach einen zweiten Task starten, der für das Laden und Speichern zuständig ist und die Reihenfolge anpassen. Erst nächsten Bild laden, dann vorheriges, fertiges Bild speichern. Und schon hat man parallelisiert. Zitat:Tss, wie kann man nur so einen Unsinn schreiben. Auf dem Classic Amiga gibt es Geräte zwischen 150kB/s und 30MB/s und CPUs zwischen 7MHz und 90MHz. Aber Du kannst pauschal sagen, ob das Entpacken oder der Transfer länger dauert... Und noch ein kleiner Denkanstoß: auf PowerUp-Systemen gibt es PPC-Datatypes. Das heißt, solange das eigentliche Programm in 68k Code vorliegt, würde selbst das Entpacken parallel zum Skalieren ausgeführt werden. Und das ohne zusätzlichen Programmieraufwand. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 13:38 Uhr Der_Wanderer Posts: 1229 Nutzer |
@gerograph Dir ist irgendwie der Alpha Kanal verloren gegangen. Daher kann man das nicht ganz vergleichen. Die Filter sehen ehrlich gesagt alle sehr ähnlich aus. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 13:56 Uhr Der_Wanderer Posts: 1229 Nutzer |
Das hier sind die Benchmark ergebnisse auf meinem i5 unter WinUAE. Ist alelrdings mit etwas Vorsicht zu geniessen, da Windows die Files cached. Ich habe daher von RAM Disk nach RAM Disk gemacht. Resizen von (1920x1080) => (800x450) using window interpolation Time for loading: 53 ms (JPEG) Time for loading: 84 ms (BMP) Time for loading: 95 ms (PNG) Time for scaling: 19 ms (none) Time for scaling: 234 ms (Window) Time for scaling: 3145 ms (GUI) Time for scaling: 3681 ms (linear) Time for saving: 73 ms (JPEG) Time for saving: 174 ms (BMP) Time for saving: 335 ms (PNG) Interessant finde ich dass JPEG so Hölle schnell ist. Hätte ich nicht erwartet. Lineare Interpolation sollte eigentlich schneller sein, das habe ich wohl nicht wirklich optimiert. Scheint auch etwas seltsam, dass GUI so viel langsamer als Window ist. Eigentlich sollte es nur etwa 3x so langsam sein. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 16:04 Uhr Holger Posts: 8116 Nutzer |
@Der_Wanderer: Wenn Du Datatypes verwendest, solltest Du auch hinschreiben, welche verwendet wurden und in welcher Version. Es gibt ja für jeden Datentyp mehr als eines. Kannst Du im nachhinein ermitteln, welchen Kompressionsgrad die JPEGs haben? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 16:12 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer: Ja, der Alphakanal ist verloren gegangen, in IrfanView kann ich lediglich eine (!) Farbe als Transparent wählen. Alphakanal Unterstützung hat das Ding nicht (bzw. nicht in meiner genutzten Version, oder ich bin zu blöd das zu finden). In der Tat, die Bilder sehen alle sehr gleich aus und ich habe fast den Eindruck, wesentlich besser/praxistauglicher als Windowsscaling ist nicht notwendig. [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 16:55 Uhr Der_Wanderer Posts: 1229 Nutzer |
Lanczos / Window Scaling Bild: http://www.geobiz.de/screenshots/320x200/lanczos.png Bild: http://www.hd-rec.de/pics/testpic_win.png Und hier beide nebeneinander, ich sag jetzt mal nicht in welcher Reihenfolge ;-) Bild: http://www.hd-rec.de/pics/test_lancwin.png @Gerograph Bist du wirklich sicher, dass dein Lanczos Bild mit Lanczos gemacht wurde? Ich muss mir mal einen Diff machen, aber ich glaube die Bilder sind (fast?) identisch. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 17:00 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Gerograph Du hast irgendwo einen Fehler gemacht. Deine Bilder sind alle identisch, d.h. mit dem gleichen Scalierungsalgo gemacht. Und vermutlich mit "Window Scaling", das Ergebnis ist auch bis auf kleine numerische Abweichungen identisch zum Window Scaling. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 17:34 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ja, IrfanView benutzt für's Downscaling immer den gleichen, internen, nicht näher spezifizierten Algorithmus. Die Auswahlbox gilt nur für's Upscaling. So steht's in der Anleitung. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.08.2011, 17:58 Uhr Der_Wanderer Posts: 1229 Nutzer |
> nicht näher spezifizierten Algorithmus. Es dürfte sich dann hierbei wohl um Window Scaling handeln. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 3 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Skalieren und so | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|
