amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 3 -4- 5 6 7 8 9 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)
Der_Wanderer   Nutzer

04.11.2011, 13:39 Uhr

[ - Direktlink - ]
Thema: Diverse WinUAE Probleme eines Powerusers
Brett: AROS und Amiga-Emulatoren

Hallo!

Ich arbeite täglich mit WinUAE (Full Window, RTG 1920x1600, JIT, 40er, FPU, 1 GB RAM, 128MB VRAM) und mir sind einige Bugs aufgefallen die mir immer mehr Probleme machen.
Es kann natürlich sein, dass die Bugs nicht von WinUAE sind, aber sie tauchen auf, vielleicht weis der ein oder andere wie man das fixt.

1. Nach längerer intensiver Benutzung fängt die Maus an zu Springen. D.h. wenn man längere Zeit in eine Richtung fährt, springt der Pfeil auf einmal wieder ein gutes Stück zurück. Meistens wenn man sich nach oben bewegt, selten auch nach rechts. Noch nie hatte ich unten oder links.
Das ist extrem ärgerlich, weil man dann die Menus nicht mehr erreichen kann. Der Pfeil springt so oft zurück, dass man sich eher nach unten als nach oben bewegt. Wenn ichs nicht besser wüsste, dann würde ich auf ein "Gag" Programm Tippen.
Ich kann die Maus aber noch mit AMIGA+Pfeiltasten bewegen.

Ein Reboot hilft nicht, man muss WinUAE neu starten um das Problem zurückzusetzen.

2. Shift, Capslock, Alt etc. bleiben des öfteren hängen. Vor allem wenn man öfter zum Windows Desktop umschaltet. Die einzige Möglichkeit das zu beheben ist mit F12 ins WinUAE Menu zu gehen und wieder verlassen, dann ist alles zurückgesetzt. Drücken der betroffenen Tasten hilft nicht.

3. Wenn ich zum Windows Desktop wechsele, und WinUAE im Hintergrund aktiv bleibt, dann empfängt er zwar keine Keyboard Events mehr, aber Maus Events und Clipboard Events (ich nutze Shared Clipboard).
Das kann seeeeehr böse enden, je nachdem was man unter AmigaOS gerade offen hat.

4. Wegen 3. habe ich probiert, die Emulation zu pausieren, wenn Windows Desktop vorne ist. Wenn man dann zurückkehrt, ist die Workbench gefreezed. Die meisten anderen Programme und das OS selbst laufen aber noch. Vermutlich irgend ein Timer Problem, weil der Timer stehengeblieben ist. Ich schätze mal die Uhr bleibt auch stehen, was nicht gerade ideal ist. Die Sync Funktion mit der Windows Uhr funktioniert nicht korrekt, d.h. der Timer wird nur "langsam" an die Uhr angepasst. Hat man mehrer Minuten oder Stunden verpasst, dann läuft die Uhr ständig viel zu schnell und macht dadurch einige Programme unbenutzbar.

5. Im Fullscreen Modus braucht WinUAE beim Umschalten eine gefühlte Ewigkeit. Dehalb nutze ich Full Window Modus. Leider ist da WinUAE deutlich träger. Ich vertstehe den Performance Unterschied nicht wirklich.

Puh, das wars erstmal. Hat jemand Ideen?

EDIT: Ich benutze WinUAE 2.3.3 unter Windows7 64bit.
Früher hatte ich mit der gleichen AmigaOS install diese Probleme nicht, die scheinen so ab etwa WinUAE 2.3.x aufzutreten. Ich werde mal ältere Versionen testen.

--
--
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 05.11.2011 um 11:19 Uhr geändert. ]
 
Der_Wanderer   Nutzer

01.11.2011, 18:59 Uhr

[ - Direktlink - ]
Thema: Frage an MIDI-Profis
Brett: Amiga, AmigaOS 4

@hansfaust:

Ungenauigkeiten die von der Maschine eingeführt werden tragen wohl kaum dazu bei, dass die Musik besser oder lebendiger wird. Es wird einfach nur wackeliger oder behäbiger. Was ein (guter) Musiker an "Ungenauigkeiten" einbaut sind kein Zufall und folgen einem bestimmten Muster, das den Rhythmus unterstützt, z.B. ein gewisser Drift zum triolischen Timing (Shuffle Factor). I.A. findet das Ohr aber "maschinenmäßig" exaktes Timing am besten, zzgl. der o.g. systematischen Abweichugnen vom "Soll-Zeitpunkt".

Die Ungenauigkeit von CPU/Ausgabe sind normalerweise vernachlässigbar im Vergleich zu den 32k Baud von MIDI und dem Synthesizer der hintendran hängt.

Wenn es nicht hinhaut, dann bleibt wohl nicht viel übrig als die Tracks zu shiften bzw. für die MIDI Kanäle die Latenzzeit einzustellen, sofern der Sequencer das erlaubt.

BTW, HD-Rec sollte auf einem 60er bereits gut laufen. Evtl. einfach Audio abstellen, wenn das nicht benötigt ist, das bringt eine Menge. Alleine das "Anschalten" von AHI kostet bei mir ca. 20-30% CPU.

--
--
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

 
Der_Wanderer   Nutzer

31.10.2011, 10:54 Uhr

[ - Direktlink - ]
Thema: Frage an MIDI-Profis
Brett: Amiga, AmigaOS 4

Bei HD-Rec kann man die Latenz Zeit für die einzelnen MIDI Ports einstellen. Das muss man dann einmal für sein Setup kalibirieren (z.B. mit einem HitHat Sound).

Sehr wichtig ist übrigends auch die "Last" auf einem MIDI Port. Deshalb kann man in HD-Rec einstellen, welche "Priotität" ein Track hat. Einem Drum Track würde man dann den Vorzug vor z.B. Streichern geben.



--
--
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

 
Der_Wanderer   Nutzer

19.10.2011, 23:05 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

@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. ]
 
Der_Wanderer   Nutzer

18.10.2011, 21:18 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

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. ]
 
Der_Wanderer   Nutzer

18.10.2011, 20:49 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

@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

 
Der_Wanderer   Nutzer

18.10.2011, 15:18 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

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. ]
 
Der_Wanderer   Nutzer

18.10.2011, 11:29 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

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. ]
 
Der_Wanderer   Nutzer

17.10.2011, 13:40 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

13.10.2011, 23:07 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

@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

 
Der_Wanderer   Nutzer

10.10.2011, 15:32 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

@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

 
Der_Wanderer   Nutzer

02.10.2011, 23:36 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

02.10.2011, 10:35 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

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

 
Der_Wanderer   Nutzer

28.09.2011, 11:07 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

@Thore

Nein, für Echtzeit ist das zu langsam. Dann eher Window für Runterskalieren und Linear zum Hochskalieren.

Ich stelle mir das in Assembler auch etwas kompliziert vor.


--
--
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

 
Der_Wanderer   Nutzer

28.09.2011, 10:45 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

So, hier ist mein Favorite:

Bild: http://www.hd-rec.de/pics/testpic_cubic_ss.png

Das Verfahren nennt sich Stair Step, in dem Fall Cubisch.
Man skaliert dabei mehrfach in kleineren Schritten. Dadurch erreicht man einen guten Kompromiss zwischen Aliasing und Schärfe.

Ich bin mal gespannt, ob jemand was Besseres "bieten" kann.

--
--
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

 
Der_Wanderer   Nutzer

26.09.2011, 09:16 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Ich mache in der Tat gerade meine Doktorarbeit, aber das ist ein ganz anderes Kaliber und hat mit Bildverarbeitung nichts (zumindest nicht viel) zu tun. Das Nachprogrammieren von bekannten Algorithmen ist ja keine wissenschaftliche Arbeit, macht aber Spass und man lernt einiges dabei.
Und ja, das ist Teil der Amiblitz3 Runtime. Ich benutze Amiblitz aber für alle möglichen Projekte (auch wissenschaftlich und auch kommerziell), ist also nicht ganz selbstlos.

--
--
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

 
Der_Wanderer   Nutzer

25.09.2011, 20:42 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

So, hier sieht man schön nochmal die einzelnen Implementierungen in Amiblitz3 im Vergleich beim Hochscalieren. Dadurch wird die sog. Rekonstruktionsfunktion sichtbar. Beim Bearbeiten von Fotos hat das natürlich nicht viel Relevanz, da man selten so extrem skaliert.

Nearest Neighbour / Window (degradiert zu NN) / Linear / Cosinus / Cubic (catmull Rom) / Cubic Stair Step (Test)
Bild: http://www.hd-rec.de/pics/test_s2.nn.png Bild: http://www.hd-rec.de/pics/test_s2.win.png Bild: http://www.hd-rec.de/pics/test_s2.lin.png Bild: http://www.hd-rec.de/pics/test_s2.cos.png Bild: http://www.hd-rec.de/pics/test_s2.cubic.png Bild: http://www.hd-rec.de/pics/test_s2.ss.png


Zum Herunterscalieren eignet sich, zumindest bei mehr als 1/2 nur Window Scaling, weil die anderen kein AA machen.
Man kann aber zwischen Bitmaps berechnen, das werde ich evtl. mal versuchen.

Cubic Stair Step benutzt die Cubische Interpolation, aber jeweils in kleinen Schritten bis zur vollen Größe. Dadurch werden die Tangenten auch etwas weicher.

Ich habe gesehen dass die Implementierung von Cubic in Paint.NET noch "weichere" Ergebnisse liefert. Das liegt daran, dass mehr als 16 Pixel pro Zielpixel verwendet werden und dadurch die Tangenten besser geschätzt werden. Der Aufwand ist aber relativ hoch, vom Tippen und vom Rechnen her, deshalb mache ich das erstmal nicht.
Evtl. implementiere ich noch Lanzcos.


--
--
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 25.09.2011 um 20:45 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 25.09.2011 um 20:48 Uhr geändert. ]
 
Der_Wanderer   Nutzer

21.09.2011, 12:00 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

So marginal sind die Unterschiede nicht, vor allem beim Hochskalieren.

Wenn ich alles fertig habe poste ich noch ein paar Beispielbilder, bei denen das gut zu sehen ist.

--
--
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

 
Der_Wanderer   Nutzer

18.09.2011, 22:37 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Ich habe nun auch (bi)cubic und Cosinus implementiert (allerdings noch Prototypen, wie man an den Rändern sehen kann...), sowie linear einen Bug gefixed.
Hier nochmal der Vergleich beim Downscaling (Achtung: ich mache kein AA (also kein Tiefpass), deshalb ist das nicht ganz fair)

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

BiCubic (ohne Tiefpass) / Cosinus (ohne Tiefpass)
Bild: http://www.hd-rec.de/pics/testpic_cubic.png Bild: http://www.hd-rec.de/pics/testpic_cos.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) / EDIT: Cubic Stair Step
Bild: http://www.hd-rec.de/pics/testpic_gui.png Bild: http://www.hd-rec.de/pics/testpic_cubic_ss.png

EDIT: Hollywood Jack / EDIT: MacOS Previewer
Bild: http://www.hd-rec.de/pics/testpic-jack.png Bild: http://www.hd-rec.de/pics/testpic_macos.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



[ Dieser Beitrag wurde von Der_Wanderer am 27.09.2011 um 23:36 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 28.09.2011 um 10:50 Uhr geändert. ]
 
Der_Wanderer   Nutzer

16.09.2011, 10:36 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Window Scaling (aka Window Resampling, Box Resampling etc.) legt über das Originalbild quasi das neue Raster imaginär drüber, und ließt für jedes "Fenster", also Zielpixelfläche, die Anteile der hineinfallenden Ursprungspixel aus und addiert sie und teilt sie durch das "Gesamtgewicht" des Fensters.

Bild: http://www.hd-rec.de/pics/winscalinggrid.png

Der obige Sourcecode ist aus Anschauungsgründen etwas vereinfacht. Was fehlt ist das Alpha-Gewichten und der Überlauf-Check. Denn hier muss "Altebreite*Neuebreite*256" in 32 bit passen. Man braucht für die Farbe aber gar keine so hohe Genauigkeit, deshalb kann man da noch etwas tunen.

Mir fällt gerade auf, man könnte auch die 4 Divisionen los werden, wenn man das Verhältnis auf eine Zweipotenz normalisiert. Dann kann man shiften. Werde ich mal ausprobieren, dann sollte der Algo noch etwas schneller 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



[ Dieser Beitrag wurde von Der_Wanderer am 16.09.2011 um 10:46 Uhr geändert. ]
 
Der_Wanderer   Nutzer

15.09.2011, 18:33 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Das Problem bei Window Scaling ist, dass es mathematisch nicht gut beschrieben werden kann, und daher als wenig "sophisticated" gilt und selten in Literatur auftaucht. Deshalb hat es auch keinen eindeutigen Namen der sich durchgesetzt hat, wie z.B. Lineare Interpolation oder nächster Nachbar. Oft findet man es auch als "Box" Resampling oder sowas.


Der sieht in AB3 so aus:

code:
sxs.l  = imagedat(srcimage)\img_width
    sys.l  = imagedat(srcimage)\img_height
    dxs.l  = imagedat(dstimage)\img_width
    dys.l  = imagedat(dstimage)\img_height
    fracX.l = 0
    fracY.l = 0
    sy.l = 0
    pw.l = sxs*sys
          For dy.l=0 To dys-1
            weightY1.l = (dys-fracY)
            cy.l=0 : fracY+sys : While fracY>dys:fracY-dys:cy+1:Wend
            sptr.l = imagedat(srcimage)\raw_ptr + sy * imagedat(srcimage)\bpr
            dptr.l = imagedat(dstimage)\raw_ptr + dy * imagedat(dstimage)\bpr
            fracX.l = 0
            For dx.l = 0 To dxs-1
              weightX1.l = (dxs-fracX)
              cx.l=0 : fracX+sxs : While fracX>dxs:fracX-dxs:cx+1:Wend

              ; Calculate the pixel...
              R.l = 0 : G.l = 0: B.l = 0 : A.l = 0
              weightY.l = weightY1
              nsptr.l = sptr + (cx LSL 2)
              For m.l = 0 To cy
                weightX.l = weightX1
                If m = cy Then weightY = weightY + (fracY-dys)
                For n.l = 0 To cx
                  If n = cx Then weightX = weightX + (fracX-dxs)
                  tpw.l = weightX*weightY
                  A.l + (Peek.b(sptr  ) & $FF) * tpw
                  R.l + (Peek.b(sptr+1) & $FF) * tpw
                  G.l + (Peek.b(sptr+2) & $FF) * tpw
                  B.l + (Peek.b(sptr+3) & $FF) * tpw
                  weightX = (dxs)
                  sptr+4
                Next
                sptr - 4*(cx+1) + imagedat(srcimage)\bpr
                weightY = (dys)
              Next
              sptr = nsptr

              Poke.b dptr  ,A / pw
              Poke.b dptr+1,R / pw
              Poke.b dptr+2,G / pw
              Poke.b dptr+3,B / pw
              dptr+4
            Next
            sy+cy
          Next


Bei Gelegenheit kann ich das ja mal aufhübschen.


Cosinus interpolation ist das gleiche wie linear, nur dass der Interpolationscoeffizient nochmal durch 0.5 - 0.5*cos(pi*r) geschossen wird, was dann sehr viel weicher aussieht als linear:

Bild: http://www.hd-rec.de/pics/int_lin.jpg Bild: http://www.hd-rec.de/pics/int_cos.jpg


--
--
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 15.09.2011 um 18:34 Uhr geändert. ]
 
Der_Wanderer   Nutzer

15.09.2011, 15:57 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Nein, es gibt keine Referenzimplementationen da es ja keine zentrale Stelle gibt (wie bei JPEG, ZLIB oder MP3) die das definiert. Zumindest nicht für Nearest Neighbour, Window Scaling, Linear, Quadratisch und Kubische Interpolation.

Die Algorithmen sind aber alle, bis auf vielleicht Lanzcos, so einfach, dass ein bisschen googeln ausreichen sollte.
Ansonsten kann ich natürlich den Source von Window Scaling (Amiblitz) für hier posten, falls das interessant wäre. Problem ist natürlich oft, dass durch viele Optimierungen die Lesbarkeit leidet.
Recht schick finde ich überigends auch Cosinusinterpolation, wie im Eingangspost am Anfang zu sehen ist. Der Vorteil gegenüber Kubisch ist, dass es sehr schnell ist und oft bereits sehr gute Ergebnisse liefert. Cosinus Interpolation nutze ich z.B. bei PerlinFX um die niedrigen "Oktaven" zu zoomen.
--
--
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

 
Der_Wanderer   Nutzer

15.09.2011, 12:04 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Die zlib wird benutzt zum Speichern von PNG und AB3I (Amiblitz3 Image), sowie zum Laden von 32bit ARGB PNGs.

Die Library unterstützt bereits PPC, da sie ein Mixed-binary ist.

Trotzdem würde ich gerne ohne die Lib auskommen, da sie eine echte Problemquelle ist, weil diverse PPC "Ports" im Umlauf sind die schlichtweg nicht funktionieren.

JPEG Bilder werden via Datatypes geladen und gespeichert via jpeg.library. Die gibt es meines Wissens nach funktionsfähig auch als PPC Port.

--
--
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

 
Der_Wanderer   Nutzer

14.09.2011, 12:52 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Also da sich nun niemand meldet, der Window Scaling schlecht findet und was besseres anbieten kann, denke ich kann man es ruhig verwenden.

Für das Hochskalieren ist das allerdings in der Tat nicht so gut, da werde ich bei Gelegenheit Cubisch oder Lanzcos implementieren.

Die Alpha Kanal Version werde ich dann demnächst in AB3 standardmäßig einbauen, d.h. auch Bilder mit Alpha Channel (z.b. Icons) werden (im Gegensatz zu vielen anderen Programmen wie ArtEffect oder Hollywood) korrekt berechnet.

--
--
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

 
Der_Wanderer   Nutzer

30.08.2011, 12:08 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

@Dr. Nop

Hier nochmal zur verdeutlichung was ich meine:

Bild: http://www.hd-rec.de/pics/testpic_alphabug.png

Hollywood (Alpha Bug) / Amiblitz3.5 (Window Scaling)
Bild: http://www.geobiz.de/screenshots/320x200/testpic-jack.png Bild: http://www.hd-rec.de/pics/testpic_win.png

Die grauen Outlines kommen daher, dass das Bild brute-force skaliert wird, ohne darauf zu achten ob der Pixel sichtbar ist oder nicht. So mischen sich die unsichtbaren Pixel (in dem Fall schwarz, könnte aber auch Pink oder sonstwas sein) mit den sichtbaren Pixeln und werden auch sichtbar. Gerade bei Icons oder Game-Sprite ein no-go.

--
--
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 30.08.2011 um 12:12 Uhr geändert. ]
 
Der_Wanderer   Nutzer

29.08.2011, 22:55 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Doch da ist schon ein Unterschied. Das Hollywood Bild hat leichtes Aliasing drin. Deshalb ist es einerseits schärfer, andererseits gibt es Aliasing Effekte.
Wenn du Beim Window Scaling Schärfe 0.25 nimmst, dann dürfe das in etwa so aussehen.

Der Hollywood Scaler hat aber einen Bug, den gleichen den Arteffekt auch hat:
Er respektiert den Alphakanal nicht richtig, sondern behandelt ihn wie eine der 3 Farbkanäle (ist einfacher so).
Deshalb bekommen alle Icons dunkle Ränder, sieht man auch an dem weißen Hintergrund, der nach unten hin eine graue Linie hat. Sollte natürlich nicht so sein.

Der Window hatte das gleiche Problem, deshalb gibt es in AB3 noch eine "alpha" Variante. Die werde ich demnächst "freischalten" dass sie automatisch verwendet wird wenn das Bild Alpha Informationen hat.
(GUI Algorithmus macht das schon sei jeher richtig).


--
--
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

 
Der_Wanderer   Nutzer

29.08.2011, 18:16 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

Interessant:

http://stackoverflow.com/questions/384991/what-is-the-best-image-downscaling-algorithm-quality-wise

Demnach wäre fürs Downsampling Sinc oder Gaussian angebracht, und fürs Upsampling Mitchel oder Lanczos. Wobei Window als "near-optimal" bezeichnet wird. Sooo schlecht kanns also nicht 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

 
Der_Wanderer   Nutzer

29.08.2011, 17:58 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

> 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

 
Der_Wanderer   Nutzer

29.08.2011, 17:00 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

@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

 
Der_Wanderer   Nutzer

29.08.2011, 16:55 Uhr

[ - Direktlink - ]
Thema: Skalieren und so
Brett: Programmierung

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

 
 
1 2 3 -4- 5 6 7 8 9 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.