amiga-news 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 - ]

29.08.2011, 18:16 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
29.08.2011, 22:18 Uhr

gerograph
Posts: 621
Nutzer 		@Holger:

Sorry, du hast recht, aber dieser Hinweis versteckt sich so ziemlich in der Hilfe. Von der Bedienung dann auch unlogisch:

Wähle ich resize bekomme ich die schlechte Qualität
Wähle ich resample, kann ich den Algo wählen und er downscaled in einer besseren Qualität

@Wanderer
Window downscaling ist schon super... Vielleicht macht es mehr Sinn, upscaling Algos in dein "Algenpool" aufzunehmen !

So hier noch das Testpic mal mit Hollywood/Jack runtergescaled:

Bild: http://www.geobiz.de/screenshots/320x200/testpic-jack.png

und windowscaling:
Bild: http://www.geobiz.de/screenshots/320x200/hermite.png

Bei Hollywood ist die Schrift deutlich schlechter... und die dritte Figur obere Reihe "subjektiv" besser. Vom Foto her tut sich nicht viel würd ich sagen.

[ Dieser Beitrag wurde von gerograph am 29.08.2011 um 22:20 Uhr geändert. ]

[ Dieser Beitrag wurde von gerograph am 29.08.2011 um 22:33 Uhr geändert. ]

[ Dieser Beitrag wurde von gerograph am 29.08.2011 um 22:34 Uhr geändert. ]

[ Dieser Beitrag wurde von gerograph am 29.08.2011 um 22:35 Uhr geändert. ]

[ Dieser Beitrag wurde von gerograph am 29.08.2011 um 22:38 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
29.08.2011, 22:55 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
30.08.2011, 09:26 Uhr

DrNOP
Posts: 4118
Nutzer 		Also der Unterschied, den ich in diesen beiden Bildern sehe, ist daß im oberen (Hollywood) die Zeile in der die Icons stehen die gleiche Farbe hat wie der Hintergrund des Beitrags (in diesem Fall grau). Und das untere Bild (windowscaling) hat diese Zeile schwarz.

Schwarze Ränder um die Icons fallen mir nicht auf.

Und die graue "Trennlinie" zwischen dem oberen Teil des Bildes und der Iconzeile hatten andere hier gezeigte Algorithmen auch schon.
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]
30.08.2011, 10:10 Uhr

gerograph
Posts: 621
Nutzer 		@DrNOP:
Zitat:
hat wie der Hintergrund des Beitrags (in diesem Fall grau). Und das untere Bild (windowscaling) hat diese Zeile schwarz.

das liegt an mir/IrfanView da wir festgestellt haben, das IrfanView ebenfalls windowscaling macht, habe ich das IrfanView windows scaling bild hochgeladen. In IrfanView krieg ich keinen Alphakanal (hier: Transparenz) hin. Wenn man es mit Amiblitz macht, dann hast Du das ohne schwarzen Hintergrund !

[ - Antworten - Zitieren - Direktlink - ]
30.08.2011, 12:08 Uhr

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

[ - Antworten - Zitieren - Direktlink - ]
31.08.2011, 10:35 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von gerograph:
@Holger:
Sorry, du hast recht, aber dieser Hinweis versteckt sich so ziemlich in der Hilfe.
Das sollte keine Kritik sein. Der Hinweis auf die Anleitung diente nur dazu klarzustellen, dass das Verhalten dem Autor von IrfanView bekannt, bzw. gewollt und kein Bug ist.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
14.09.2011, 12:52 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
14.09.2011, 20:19 Uhr

gerograph
Posts: 621
Nutzer 		@Der_Wanderer:

mal nen bisserl offtopic, für das Packen von Bildern nutzt AB3/image.include die zlib.library, richtig ? Betrifft das nur das Formate jpeg und png, oder noch weitere ? Gibts, oder wäre es möglich zlib.library PPC nativ zu machen ?

[ - Antworten - Zitieren - Direktlink - ]
15.09.2011, 12:04 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
15.09.2011, 14:26 Uhr

whose
Posts: 2156
Nutzer 		@Der_Wanderer:

Mal wieder on topic: Hast Du evtl. Links auf Referenzimplementationen der einzelnen Algos (Sprache ist nicht ganz so wichtig)? Ich hab bisher nur still mitgelesen, aber das Thema als solches interessiert mich sehr.
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]
15.09.2011, 15:57 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
15.09.2011, 16:11 Uhr

whose
Posts: 2156
Nutzer 		@Der_Wanderer:

Hm, für den "Standard-Kram" wie Nearest Neighbour etc. habe ich entsprechendes gefunden (wobei das eh einer der simpelsten Algorithmen ist und ich genau den schon mal implementiert hatte). Cosinus-Interpolation wird seltsamerweise wenn überhaupt nur am Rande erwähnt? In der englischen Wikipedia zum Beispiel kommts gar nicht vor, dafür so Exoten wie seam carving und ähnliches Zeug.

Windowed Scaling wiederum taucht als Implementation nirgendwo auf und etwaige Fundstellen beziehen sich auf speziellere Abarten aus der Bilderkennung oder eben auf die beim IEEE hinterlegten Schriften zu dem Thema. An letztere ist für mich etwas schwierig dranzukommen ;)

Von daher wäre der AB3-Code schon mal interessant. Mit etwas Mühe sollte ich das in einfacher lesbaren Code "rückübersetzen" können, notfalls frage ich halt dumm nach :D
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]
15.09.2011, 18:33 Uhr

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

[ - Antworten - Zitieren - Direktlink - ]
15.09.2011, 23:00 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Der_Wanderer:
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.

Ja, das ist mir auch aufgefallen... jede Menge Zeug, das unter "Window scale" firmiert... teilweise sogar "Window resampling" und ähnliches. Da brauche ich mich nicht zu wundern, daß ich kaum was finde :)

Zitat:
Der sieht in AB3 so aus:

Und ich finde, das sieht recht lesbar aus. Ok, als C-Coder fällts mir von Natur aus etwas leichter, aber trotzdem... vielen Dank! :)

Mit etwas Grübeln sollte man auch gut dahinter kommen, was das genau macht. Ganz grob (grob! ;) ) gesagt arbeiten die meisten Scaling-Algorithmen ja nach bekanntem Schema... Pixel bewerten. Entweder Pixel rund um einen Stützpunkt im Quellbild oder im Zielbild. Im ersten Überfliegen sieht das hier ziemlich ähnlich aus.
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]
16.09.2011, 10:36 Uhr

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

[ - Antworten - Zitieren - Direktlink - ]
18.09.2011, 22:37 Uhr

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

[ - Antworten - Zitieren - Direktlink - ]
20.09.2011, 21:35 Uhr

gerograph
Posts: 621
Nutzer 		@Der_Wanderer:

Hier kann man ja noch was lernen....

[QUOTE]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.[/QUOTE]

Hä ? Ne, ernsthaft, da bin ich jetzt zu müde, um das zu durchdenken. Manchmal glaub ich mein Gehirn ist nach einem Tag Hauptschüler unterrichten nicht mehr in der Lage soetwas aufzunehmen.... war früher mal anders, da hab ich soetwas zumindest versucht zu verstehen. Aber hey, macht euch nicht die Mühe mir das zu erklären.

Interessant sind meiner Meinung nach die nur "marginalen" Unterschiede.

[ - Antworten - Zitieren - Direktlink - ]
21.09.2011, 12:00 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
25.09.2011, 20:42 Uhr

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

[ - Antworten - Zitieren - Direktlink - ]
25.09.2011, 21:53 Uhr

inq
Posts: 445
Nutzer
Zitat:
Original von Der_Wanderer:

Ich habe gesehen dass die Implementierung von Cubic in Paint.NET noch "weichere" Ergebnisse liefert.... Der Aufwand ist aber relativ hoch, vom Tippen und vom Rechnen her, deshalb mache ich das erstmal nicht.
Evtl. implementiere ich noch Lanzcos.

finde ich gut, daß du dir soviel Mühe machst, alles zu vergleichen. das ist nicht wirklich "nur" für AB3, oder? Hört sich schon fast wie eine Doktorarbeit an. Dann solltest du allerdings o.g. nicht außen vor lassen.
Wenn's denn wirklich irgendwas in Richtung Education wird, veröffentlichst du doch sicher ein PDF, ja?

inq

p.s.: ich weiß, du bist sehr beschäftigt, aber: Wie weit ist denn nun NTUI? 8)

[ - Antworten - Zitieren - Direktlink - ]
26.09.2011, 09:16 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 10:45 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		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


[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 10:55 Uhr

Thore
Posts: 2266
Nutzer 		> Ich bin mal gespannt, ob jemand was Besseres "bieten" kann.

Hängt ja mitunter vom Bild ab ;)

Wie performant ist dein Algorithmus? Lohnt es sich, diesen in Assembler umzusetzen und die BitMapScale Routine des OS zu patchen? Nur mal so als Nebenfrage... ;)

[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 11:07 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		@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


[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 14:37 Uhr

Thore
Posts: 2266
Nutzer 		Sofern der Algo bekannt ist, dürfte das auf 68k Assembler nicht sonderlich schwierig sein. (Sofern man Assembler kann).
Man muss sich lediglich strikt an die API halten und die Register retten, sonst crashts.
Aber wenns nicht performant genug ist, dann sollte mans lieber sein lassen.

[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 15:15 Uhr

Thore
Posts: 2266
Nutzer 		@gerograph
Wegen der Zweierpotenz und dem Schieben, falls dich die Rechnung noch interessiert. Ganz einfach:
Schiebst du Bits um eine Stelle nach links ist es das gleiche wie wenn du mal zwei rechnest.
Umgekehrt, schiebst du sie nach rechts, teilst du jeweils um 2.
Da mit jedem Bit der Faktor sich verdoppelt, (2, 4, 8, 16, 32) sieht man daß es Zweierpotenzen sind. (Liegt dem Binärsystem ja schon zugrunde, 2 Zustände)
Also um 3 Stellen nach links ist schieben ist gleich wie *8 zu nehmen.
Drei Stellen nach rechts = geteilt durch 8.

Shiften ist wesentlich schneller als eine Division der CPU. Viele Compiler optimieren das aber bereits schon.

[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 15:50 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Umgekehrt, schiebst du sie nach rechts, teilst du jeweils um 2.
Bei positiven Zahlen. Das wird gerne vergessen.
Zitat:
Shiften ist wesentlich schneller als eine Division der CPU. Viele Compiler optimieren das aber bereits schon.
Sofern sie das überblicken können, d.h. i.A. nur, wenn der Divisor konstant ist. Wenn wie hier durch eine Variable geteilt wird, muss der Programmierer selbst dafür sorgen, dass der Divisor eine Zweierpotenz ist und dieses Wissen in eine explizite Shift-Operation münden lassen.

Der Trick lässt sich auch für nicht-Zweierpotenzen ausnutzen, z.B. in dem man statt durch 10 zu teilen, mit 52429 multipliziert und dann um 19 Bits nach rechts schiebt. Dabei darf der Dividend offensichtlich nicht zu groß sein, was wiederum selten vom Compiler überblickt werden kann und deshalb Handarbeit erfordert.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 16:05 Uhr

Thore
Posts: 2266
Nutzer 		@Holger
Ja positive Integer sind gemeint.

Die meisten Compiler können z.B. bei *3 umbauen, indem sie einmal shiften, dann nochmal addieren. Das geht für einige Faktoren.
Ich bezog mich auf das vorangegangene Statement:
"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."
Und dem anschließenden "Hä" von gerograph. Deshalb hier nur eine kurze Erklärung wie das technisch gemeint war mit dem shiften.

[ - Antworten - Zitieren - Direktlink - ]
28.09.2011, 16:55 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Die meisten Compiler können z.B. bei *3 umbauen, indem sie einmal shiften, dann nochmal addieren.
Was aber je nach CPU nichts bringt, weil Multiplikationen nicht so teuer wie Divisionen sind.
Zitat:
Ich bezog mich auf das vorangegangene Statement:…
Ich auch ;)
Zitat:
Und dem anschließenden "Hä" von gerograph. Deshalb hier nur eine kurze Erklärung wie das technisch gemeint war mit dem shiften.
Ja, und ich hielt es noch für erwähnenswert, dass das in diesem konkreten Fall nicht vom Compiler automatisiert werden kann.

--
Good coders do not comment. What was hard to write should be hard to read too.

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