|
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 - ] |
|
28.09.2011, 16:59 Uhr Thore Posts: 2266 Nutzer |
@Holger Sollte auch nur eine allgemeine Stellungnahme sein, was mit Zweierpotenz und shiften gemeint war  Shiften ist sowohl schneller als multiplizieren und dividieren, schon allein wenn man die Durchlaufzeit der Gatter sieht. [ - Antworten - Zitieren - Direktlink - ] |
|
28.09.2011, 22:50 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die bestimmt aber nicht alleine die Ausführungszeit. Eine Multiplikation besteht aber vor allem sowieso nur aus Shiften, gefolgt von Addieren. Das Aufsplitten einer Multiplikation mit Faktor drei in eine Shift-Operation und eine Addition, ausgeführt als zwei separate Instruktionen bringt deshalb nicht immer Vorteile. Für den einfachen Fall der Zweierpotenzen, die zu einer einzelnen Shift-Instruktion transformiert werden, ist der Vorteil natürlich eindeutig. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.10.2011, 23:26 Uhr inq Posts: 445 Nutzer |
Zitat: @Der_Wanderer Aus Neugier: Ist das beim Optimizer in AB3 auch so? Und, spuckt der Compiler Logs aus, was/warum/wie optimiert wurde, mit Resultat (ExecFile size, Stack use, Speed)? [ - Antworten - Zitieren - Direktlink - ] |
|
02.10.2011, 10:35 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ich habe den Optimizer nicht geschrieben, sondern Bernd. Aber ich denke das macht der Optimizer nicht, weil AB3 nur signed Typen kennt, und da darf man nicht so einfach shiften statt dividieren. Es gibt nur selten den Fall, dass der Optimizer sowas automatisch tun kann. Was ich oben meinte ist, dass ich die Ratio newWidth/oldWidth beim Skalieren auf eine Zweierpotenz "runde", dann kann man shiften. Das kann natürlich kein Optimizer machen, da der Algorithmus numerisch nicht mehr das gleiche Ergebnis liefert und man dazu einiges Wissen muss, z.B. dass die Ratio niemals negativ wird. Der AB3 Optimizer schreibt kein Log. Es ist auch kein seperater Vorgang, sondern im Compiler integriert. -- -- 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 - ] |
|
02.10.2011, 22:31 Uhr inq Posts: 445 Nutzer |
Zitat: Hey, du bist der Guru  Ich versuch noch mal einen andersfarbigen Pfahl: Gibt evtl. AB3 eine Nachricht (Dialogbox) aus, a la: Hooray! I've managed do optimize your <exec> to half the size! Nah?? [ - Antworten - Zitieren - Direktlink - ] |
|
02.10.2011, 23:36 Uhr Der_Wanderer Posts: 1229 Nutzer |
Wie schon gesagt, sind Compiler, Codegenerator und Optimizer ein und das selbe Ding ein AB3. Deshalb gibt es auch nicht sowas wie Exe Größe vorher und nachher. Beim Optimieren für Geschwindigkeit wird übrigends der Code in der Regel größer. Z.b tauscht man ein Mul geben ein Shift und Add aus, oder man rollt einen Loop aus sodass man seltener bedingt springen muss. Man kann an der Filegröße die Dead Code Elemination beobachten, indem man mehrmals compiliert. -- -- 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 - ] |
|
03.10.2011, 11:32 Uhr Thore Posts: 2266 Nutzer |
Die Größe des Binary ist kein Garant der Geschwindigkeit. Es kann auch sein, daß größere Programme schneller laufen. Ausschlaggebend ist zum einen der Algorithmus, zum anderen die eingesetzten Mnemonics. Je nach CPU dann noch kritische Punkte wie Register-Wartezeiten, Sprünge, etc. Hier mögliche Szenarien (nur eine Auswahl) Beispiele wann ein Programm schneller aber trotzdem größer wird: - Loop Unroll, durch weniger Sprünge schneller - Aufdröseln von Multiplikation/Division in mehrere "billigere" Befehle Beispiele wann ein Programm kleiner wird aber nicht unbedingt schneller: - Entfernen von Dead Code Beispiele wann ein Programm schneller wird aber nicht kleiner: - Befehlstausch um Register Wartezeit optimal zu nutzen - Ersatz von Befehlen durch schnellere gleichwertige Befehle Beispiele wann ein Programm kleiner und schneller wird: - Ersatz von Longs durch Shorts oder Bytes wenn möglich - Verwenden von Near Jumps wenn möglich (z.B. nach Dead Code Entfernung) Man kann also nach Größe optimieren, oder nach Geschwindigkeit, oder ein Optimum an beidem herstellen. [ - Antworten - Zitieren - Direktlink - ] |
|
04.10.2011, 13:18 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wobei es „das Optimum“ gar nicht gibt. Denn auch innerhalb derselben Prozessorfamilie gibt es (teilweise erhebliche) Unterschiede in der Ausführungszeit bestimmter Instruktionen und bei den Cache-Größen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.10.2011, 17:13 Uhr Thore Posts: 2266 Nutzer |
@Holger Richtig, deshalb schrieb ich auch "ein Optimum" und nicht "das Optimum". Nicht nur die CPU (welche natürlich auch eine große Rolle spielt), sondern auch der Algorithmus an sich spielt dabei eine Rolle. Und der Compiler wird nicht wissen, was nun das Optimum in dem speziellen Code darstellt. Aber ein gutes Mittelmaß kann man schon erreichen. [ Dieser Beitrag wurde von Thore am 04.10.2011 um 17:14 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
08.10.2011, 22:25 Uhr inq Posts: 445 Nutzer |
Zitat: Ooookaaaayyyy.... Du willst nicht antworten, oder? Du bist schon Professor, oder? Du ignorierst Zaunpfähle, auch, wenn sie dir ins Gesicht schlagen? P.S.: Eigentliche Frage: Gibt der Optimizer in AB3, mit oder ohne AB3, IRGENDEINE Msg ab, warum/wie/wohin/whatever optimiert wurde ??? inq [ Dieser Beitrag wurde von inq am 08.10.2011 um 22:28 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.10.2011, 15:32 Uhr Der_Wanderer Posts: 1229 Nutzer |
@inq: > Du willst nicht antworten, oder? Doch, tue ich das nicht die ganze Zeit? > Du bist schon Professor, oder? Nein, noch nicht. > Du ignorierst Zaunpfähle, auch, wenn sie dir ins Gesicht schlagen? Ich sehe weit und breit keinen Zaunpfahl, hab ich was verpasst? > Gibt der Optimizer in AB3, mit oder ohne AB3, IRGENDEINE Msg ab, warum/wie/wohin/whatever optimiert wurde ??? Kurze Antwort: NEIN. Lange Antwort: Der "Optimzier" in AB3 ist steng genommen gar keiner. Die Compiler Direktive "optimize" schaltet verschiedene Features des Compilers and/aus. Der Code wird aber direkt erzeugt, deshalb gibt es kein Vorher/Nachher das man ausgeben könnte, wie z.B. "habe 123 Bytes eingespart". Dazu brauchst du logischerweise eine Baseline, die es aber eben nicht gibt. Was genau "optimize" macht, seht in der Docu. Vereinfacht gesagt schaltet optimize 1 68020 Code an, wodurch z.b. Integer, vor allem 32bit, etwa 4x so schnell werden wie mit 68000 Code. Optimize 2 schaltet die FPU an, also 68882 Code. Dadurch werden Floats etwa 20x so schnell und der Type .d, also double ist möglich. Optimize 4 schaltet Compilererweiterungen an, die BlitzBasicII nicht kennt. Z.b. wird der Overhead einen Function Calls minimiert, mehr als 7 Parameter sind möglich, neben binär, decimal und hex sind auch 256-er Zahlen erlaubt @"ILBM", es gibt eine "FAST" Direktive für Function Calls etc. etc. etc. -- -- 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 - ] |
|
13.10.2011, 21:42 Uhr inq Posts: 445 Nutzer |
Zitat: Danke für deine Ausführungen trotz meiner Anpissungen  Oh, und danke dafür, daß ich deinen Thread verbiegen darf... Zitat:Ok. verstehe ich. Die "Baseline" könnte aber ein Pre-Compile sein, oder? Z.b. ein Zwischenschritt vor dem eigentlichen Exe, oder ein Log zwischen den Builds? Immerhin schreibt AB ja letztendlich ein Exe. Und der Compiler muß an sich eigentlich garnichts wissen: Die IDE kennt die Änderungen und weiß, welches File wohin in welcher Größe geschrieben wird. Oder? Möglicherweise kann man auch die VARTRACE-Sachen (gibts die noch?) nutzen um die Exec-Zeit für ein Profiling zu nehmen, pro Function-Block oder so. Achso: für die Doks hast du einen Link oder so? War gerade auf der Ab3-Site und da sind "nur" FAQs und Tuts. Zitat:Wie macht man sowas? Der Compiler hält also doch den Status/Buffer des vorherigen Compilats fest, oder wie? Woher sollte er sonst Dead Code feststellen?? [ Dieser Beitrag wurde von inq am 13.10.2011 um 21:46 Uhr geändert. ] [ Dieser Beitrag wurde von inq am 13.10.2011 um 21:52 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.10.2011, 23:07 Uhr Der_Wanderer Posts: 1229 Nutzer |
@inq: Die Docs sind in der Distribution mit drin. Du wirfst da Entwicklungsumgebung, Compiler, Codegenerator, Optomizer und Profiler irgendwie durcheinander. Um Dead Code zu finden benötigt der Compiler tatsächlich mehrere Passes. Das muss man nicht, aber so ist es einfacher zu Implementieren und ist quasi ein Abfallprodukt des Aufstellens der Compilerstatistiken. Geschrieben hat das Bernd (Ehre, wem Ehre gebührt). -- -- 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 - ] |
|
14.10.2011, 22:16 Uhr inq Posts: 445 Nutzer |
Zitat:Ok. Um das hier mal meinerseits abzuschließen: Es gibt also Daten, Statistiken. Wäre doch schön, wenn der User das zu Gesicht bekäme, oder? <Compiler hat -14- Zeilen unbenutzten Code ignoriert.> Oder so ähnlich. inq [ - Antworten - Zitieren - Direktlink - ] |
|
17.10.2011, 13:40 Uhr Der_Wanderer Posts: 1229 Nutzer |
Sooo, Cubic Interpolation ist nun eingechecked im SVN und darf offiziell benutzt werden. Auch beim verkleinern erhält man gute Ergebnisse, wenn man vorher auf 200% scaliert (z.B. mit Window), und danach auf 100% mit Cubic, oder im "richtigen" Stairstep Verfahren, was allerdings sehr viel rechenintensiver ist, z.B. in 10% Schritten herunterscalieren. @Gerograph Wenn du das in iBatch verwendest, sollten wir evtl. noch kurz diskutieren was die beste Strategie ist zum hoch/runterscalieren. -- -- 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 - ] |
|
18.10.2011, 08:06 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer: Danke,.... ja in iBatch wollte ich es auch nutzen. Die beste Strategie ? Da es ja hauptsächlich um runterscalieren geht, würde ich wie von dir vorgeschlagen erst aufs doppelte hochskalieren und dann auf die gewünschte Größe runterskalieren ? Etwas einfacher und Resourcenschonender umzusetzen wäre natürlich ohne hochskalieren. Vielleicht biete ich auch beides an, muß mir die Ergebnisse mal anschauen. Wie gesagt, zum skalieren ist in der neuen Version ein Cyclegadget vorgesehen, bei dem ich den Algo festlegen kann (default=window) + weiteres Gadget für Sharpness. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2011, 11:29 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ich schlage folgendes vor: 1. Default 2. Fast Bild: http://www.hd-rec.de/pics/downscale_window.png 3. Quality Bild: http://www.hd-rec.de/pics/downscale_cubic_aa.png 1. Für Default gibst du einfach -1 an, das ist dann der Default der image.include, der sich auch ändern könnte wenn es andere Algorithmen gibt. Das ist i.A. ein guter kompromiss zwischen Speed und Qualität. 2. Da solltest du zum Runterscalieren Window Scaling mit Schärfe 0 nehmen, und zum Hochscalieren Linear. Ich würde kein Nearest Neighbour anbieten, wenn du dämliche Kommentare vermeiden willst. Window ist auch schon recht schnell in Relation zum Laden des Bildes. 3. Hochscalieren immer Cubic, aber wenn der Scalierungsfactor <50% ist, erstellst du eine Zwischen-Bitmap mit Window Scaling/Schärfe 0, idealerweise 2x so groß wie die Zielgröße, und wendest danach Cubic an. Beispiel: 100x100px => 150x150px : Cubic 100x100px => 75x75px : Cubic 100x100px => 33x33px : Window nach 66x66px, und dann Cubic von 66x66=>33x33px Man kann das noch weiter Treiben, das nennt man dann Stair-Step Verfahren, aber das ist unverhältnismäßig "teuer" im Vergleich zu dem was es bringt. Merke die einfach, Cubic, Linear und Cosinus darfst du niemals mehr als 50% verkleinern, denn dann gibt es Aliasing. Dann sollte man entweder einen Tiefpassfilter darauf anwenden (was ich nicht direkt implementiert habe weil teuer) oder ein Verfahren nehmen was das implizit schon drin hat, wie z.B. Window Scaling (ohne Schärfe). Der Schärfe Parameter in der image_Resize() Funktion wirkt sich momentan nur bei Window Scaling aus, die anderen Algorithmen werden davon nicht beeinflusst, das ist aber ok so. Hier nochmal alle im Vergleich: Bild: http://www.hd-rec.de/pics/downscale_nn.pngNearest Neighbour (#image_interpol_none) Bild: http://www.hd-rec.de/pics/downscale_linear.pngLinear (#image_interpol_linear) Bild: http://www.hd-rec.de/pics/downscale_cos.pngCosinus (#image_interpol_cos) Bild: http://www.hd-rec.de/pics/downscale_window.pngWindow Schärfe 0 (#image_interpol_window) Bild: http://www.hd-rec.de/pics/downscale_win05.pngWindow Schärfe .5 (#image_interpol_window) Bild: http://www.hd-rec.de/pics/downscale_cubic.pngCubic (#image_interpol_cubic) Bild: http://www.hd-rec.de/pics/downscale_cubic_aa.pngCubic + Window (#image_interpol_window/#image_interpol_cubic) Bild: http://www.hd-rec.de/pics/downscale_cubic_aa05.pngCubic + Window Schärfe .5 (#image_interpol_window/#image_interpol_cubic) Bild: http://www.hd-rec.de/pics/downscale_gui05.pngGUI (#image_interpol_gui) Und hier nochmal die, die am Besten für Fotos geeignet sind: Window 0 / Win 0 +Cubic / Window 0.5 / Win 0.5 + Cubic Bild: http://www.hd-rec.de/pics/downscale_window.png Bild: http://www.hd-rec.de/pics/downscale_cubic_aa.png Bild: http://www.hd-rec.de/pics/downscale_win05.png Bild: http://www.hd-rec.de/pics/downscale_cubic_aa05.png Eine stufenlose Schärferegelung würde ich nicht einbauen, da die meisten Leute den Schärfe Regler voll aufdrehen werden nach dem Motto "je schärfer je besser" und danach über die Qualität nörgeln. Du kannst ja z.B. "Cubic" und "Sharp Cubic" anbieten. -- -- 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 18.10.2011 um 11:55 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2011, 11:50 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer: 1. Was ist den Default ? Windows ? Ich hätte gerne Windowscaling als Default. 2. Was ist die konstante für Nearest Neighbour ? muss jetzt weg... geht irgendwann weiter... sorry ..... so da bin ich wieder... hast ja schon ergänzt, Frage 2 hat sich damit erledigt. Ich denke dann, werd folgendes anbieten: 1. Downscaling window (fast downscaling - good quality) 2. Downscaling bicubic (slow downscaling - best quality) ggf. mit Zwischenschritt 3. Upscaling linear (fast upscaling) 4. Upscaling bicubic (slow upscaling - best quality) Nr. 1 und 2. (wenn Zwischenschritt) mit Sharpnessfaktor (nach einigen Testläufen, denke ich, dass soft=0, medium=0.5, sharp=0.75 ,extra=1 und none ausreichend und sinnvolle Optionen sind). [ Dieser Beitrag wurde von gerograph am 18.10.2011 um 14:18 Uhr geändert. ] [ Dieser Beitrag wurde von gerograph am 18.10.2011 um 14:20 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2011, 15:18 Uhr Der_Wanderer Posts: 1229 Nutzer |
Default wäre, was die image.include zur Zeit als default macht. Als Sharpness Faktor würde ich nicht über 0.5 gehen, sonst gibt es zu viel Aliasing und 0.5 ist schon recht viel. Ich würde auch nur Sharpness on/off anbieten. Das ist auch die Frage ob du die Algorithmen so nach aussen legen willst. Viele Leute wissen damit nichts anzufangen. Du willst also zwei Cycles anbieten für down/up scaling? Da linear für downsampling uninteresant ist, und window für upsampling, würde da nicht fast/quality ausreichen? Keep-it-simple! -- -- 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 18.10.2011 um 15:20 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2011, 18:15 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer:Zitat:Ganz ehrlich, ich habs durchgetestet mit einigen Fotos, und meine Werte machen durchaus Sinn, insbesondere "Soft". Über den Wert 1 kann man noch diskutieren. Denke nicht, dass ich nur on/off machen, sorry. Zitat:Die Benunnung der o.g. vier Optionen stehen noch nicht fest, im GUI ist nur das zu sehen was in den Klammern steht, aber auch das gefällt mir noch nicht so richtig... (Bicubic, Windows... wird nirgendwo stehen). Zitat:Nein, alle vier Optionen in einem Cyclegadget, war angedacht, Schwerpunkt soll aber auf Downscaling sein, ich muß da nochmal ne Nacht drüber schlafen. Gruß, Danke für die Ideen, Algos und Hinweise. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2011, 20:49 Uhr Der_Wanderer Posts: 1229 Nutzer |
@gerograph: "Soft" bedeuted sharpness=0 ? Das ist etwas schneller als sharpness != 0. Werte über .5 führen zu deutlichem Aliasing. Das merkst du bei Fotos direkt von der Digicam normalerweise nicht so stark, weil sie auf Pixelebene betrachtet recht unscharf sind, je mehr Mega-Pixel, je unschärfer natürlich. Deshalb fällt das dort kaum auf, da wird selbst Nearest Neighbour noch nicht katastrophal aussehen, zumindest wenn man nicht zu stark verkleinert. I.A. gilt das aber nicht, z.B. hier bei dem Testbild. Und schärfer im Sinne von "besser" wird's auch nicht wirklich. Da du in den Einstellungen noch nicht weist, ob die Bilder größer oder kleiner werden, macht es eigentlich keinen Sinn EIN Cycle zu haben mit Einstellungen explizit für down ODER up scaling. Deshalb würde ich nur Fast (= linear up, window down) und Quality (= cubic up, cubic+win down) machen. Sharpness könnte man weich (0) scharf(.25) und sehr scharf (.5) machen. Das Problem bei kontinuierlichen Einstellung ist oft, dass die User lediglich die extremen Einstellungen auswählen, vor allem wenn sie keinen Anhaltspunkt haben wie "scharf" 0.312 nun ist. Etwas anderes wäre es, wenn es einen Preview gäbe, aber man kann auch nicht von einem Bild auf alle schliessen. -- -- 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 - ] |
|
18.10.2011, 21:18 Uhr Der_Wanderer Posts: 1229 Nutzer |
Hier die Schärfen im Vergleich: Bild: http://www.hd-rec.de/pics/downscale_window.png 0 Bild: http://www.hd-rec.de/pics/downscale_win01.png 0.1 Bild: http://www.hd-rec.de/pics/downscale_win025.png 0.25 Bild: http://www.hd-rec.de/pics/downscale_win05.png 0.5 Bild: http://www.hd-rec.de/pics/downscale_win075.png 0.75 Bild: http://www.hd-rec.de/pics/downscale_win1.png 1.0 -- -- 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 18.10.2011 um 21:19 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2011, 20:27 Uhr gerograph Posts: 621 Nutzer |
@Der_Wanderer:Zitat:Ja richtig, aber sie "gaukeln" insbesondere bei Aufnahmen von Bäumen, Gittern, Zäunen, Architektur eine gewisse Schärfe vor. Ich habe also nochmal getestet. Meine Entscheidung: soft(0), medium(.25), sharp(.5) und extra(.75). Zitat:Gute Idee... hier meine Entscheidung: very fast = Interpol none good and fast = linear up/window down (bisher window) = mein default quality = cubic up, cubic+win down (bisher linear/very good and slow)* *was ja mal definitiv blödsinn war Also, die Idee, den Algo abhängig von down-/upscaling zu wählen ist gut. Die Variante "very fast" möchte ich lassen, da sie um 30%-56% schneller ist als "windows"/"windows-sharp". Und wenn ich einen schnellen überblick brauche oder die Dinger als Passfotos ausdrucke ist das teilweise sogar besser. Abgesehen davon gibt es Systeme die nicht so schnell sind wie mein SAM mit 677Mhz. Ja, und ich weiß, Dir ist es nicht simpel genug. Auf der anderen Seite waren die Ergebnisse bisher schon so gut, dass eine Veränderung der Skalieralgos in meinen Augen für "Average Joe" eh kaum Sinn macht... Es macht nur dann Sinn wenn es mehr in Richtung "Bildbearbeitung" geht*, was impliziert das der User mehr Möglichkeiten an die Hand bekommt => Also so ne Art Mittelweg..... und dann ist auch langsam das Ende der Fahnenstange erreicht, weitere Funktionen würden das GUI überfrachten...d.h. für Version 2.0 hab ich dann schon eine komplett andere Strategie im Kopf ;-) *In der nächsten Version wird es ja weitere Bildbearbeitungsfunktionen geben (image_filter{}, watermark,...) Gruß [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2011, 23:05 Uhr Der_Wanderer Posts: 1229 Nutzer |
@gerograph: Ok, deine Entscheidung was du anbieten willst. Linear ist etwas schneller als Window Scaling. Aber hat keinen Tiefpass Filter. > Also, die Idee, den Algo abhängig von down-/upscaling zu wählen ist gut. Das ist sogar ein Muss. Denn: Eigentlich geht Scalieren so: Schritt 1: Zuerst müssen wir das Nyquist Theorem zufrieden stellen. (http://de.wikipedia.org/wiki/Nyquist-Shannon-Abtasttheorem) Beim Hochscalieren ist das automatisch der Fall. Beim Herunterscalieren müssten wir einen Tiefpass-Filter auf das Bild anwenden. Schritt 2: Neu-Abtastung des Bildes. Dabei kann man nun einen Algorithmus auswählen wie Nearest Neighbour, Linear, Cosinus oder Cubic. Das nennt man auch die Rekonstruktionsfunktion. Bei NN ist das eine waagerechte Gerade, bei Linear eine beliebige Gerade, bei Cubic ein Polynom dritten Grades, bei Cosinus eine halbe Cosinus Funktion. Cubic ist natürlich von den o.g. am besten, weil es am meisten Information in die Rekonstruktion mit einbezieht, nämlich 4 Pixel, dagegen Linear/Cosinus nur 2 Pixel und NN nur 1 Pixel. Aber die Neuabtastung, egal wie toll die Rekonstuktionsfunktion ist, macht Aliasing, wenn man vorher nicht Tiefpass filtert. Window Scaling ist ein Trick, wo man beides auf einmal macht. Nicht optimal, aber bereits sehr gut. Man kann Window Scaling also dazu benutzen, auf etwa das Doppelte des Zielbildes zu zoomen, um anschließend eine Neuabtastung machen. -- -- 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 19.10.2011 um 23:46 Uhr geändert. ] [ - 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. |
|
