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

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

-1- [ - Beitrag schreiben - ]

23.08.2010, 20:31 Uhr

Ralf27
Posts: 2779
Nutzer 		Mich hat es am Sonntag Abend etwas gejuckt und ich wollte unbedingt wissen wie man RGB16 dekodiert und in einer festen 8Bit-Farbpalette wieder auf denn Bildschirm wirft.
Nunja, ich hab es etwas "dreckig" implementiert. Die Farben können aber so nicht so ganz stimmen. Nunja, erst mal etwas Code:

code:
REM testweise auslesen von rgb16,
REM ist total schwach und *nur* testweise
REM 20.08.10
REM testbild=800*600 in 16bit, aber testweise nur 300*200 laden
SCREEN 1,300,200,8,1
WINDOW 2,,,128,1
 FOR r=0 TO 5
  FOR g=0 TO 6
   FOR b=0 TO 5
    PALETTE r+g*6+b*42,r/5,g/6,b/5
   NEXT
  NEXT
 NEXT
 REM rgb, 5,6,5, max 32,64,32
 r=0:g=0:b=0
OPEN"cache:rgb16.test"FOR INPUT AS 1
 FOR y=0 TO 199
  t$=INPUT$(1600,1)
  FOR x=0 TO 299
   f&=PEEKW(SADD(t$)+x+x)
   r=(f& AND &hF800)>>11
   g=(f& AND &h7E0)>>5
   b=f& AND 31
   PSET(x,y),r6+(g10)*6+(b6)*42
  NEXT
 NEXT 
CLOSE

Das ist mal die Kurzfassung. Mir ist klar das einzelne Punkte total ineffektiv sind. Hab es inzwischen mit WriteChunkyPixel() umgebaut, aber eigentlich müßte es so doch auch laufen, wenn auch wesentlich langsamer. Kann es wirklich so hinhauen?

Nochmals: Mir ist klar das das dreckig programmiert ist. War nur auf die schnelle zum entspannen.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
23.08.2010, 21:07 Uhr

thomas
Posts: 7718
Nutzer 		@Ralf27:

Was macht der Operator ? Ich vermute mal Division ohne Rest.

Dann würde ich das so machen:

r = (r * 5) 31
g = (g * 6) 63
b = (b * 5) 31
PSET(x,y),r+g*6+b*42

Ist etwas genauer als deins.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]
23.08.2010, 22:00 Uhr

Ralf27
Posts: 2779
Nutzer 		@thomas:

Hm, stimmt, da werden die Rundungsfehler korrigiert. Aber, die Farben wollen so einfach nicht stimmen. Ich hab das ganze jetzt mal nach HAM8 umgebaut:

code:
REM testweise auslesen von rgb16,
REM testbild=800*600 in 16bit, aber testweise nur 300*200 laden
SCREEN 1,320,200,8,1,2048
WINDOW 2,,,128,1
 REM rgb, 5,6,5, max 32,64,32
OPEN"cache:rgb16.test"FOR INPUT AS 1
 FOR y=0 TO 199
  t$=INPUT$(1600,1)
  ar=0:ag=0:ab=0
  FOR x=0 TO 299
   f&=PEEKW(SADD(t$)+x+x)
   r=(f& AND &hF800)>>11
   g=(f& AND &h7E0)>>5
   b=f& AND 31
   u=ABS(ar-r):m=1
   ug=ABS(ag-g)
   ub=ABS(ab-b)
   IF ug>u THEN u=ug:m=2
   IF ub>u THEN
    ab=b:f=64+b+b
   ELSE 
    IF m=1 THEN ar=r:f=128+r+r ELSE ag=g:f=192+g
   END IF
   PSET(x,y),f
  NEXT
 NEXT 
CLOSE

Und: ist wieder nur zum testen. Aber, die Farben kommen nicht so richtig hin. Ich versteh das nicht so ganz...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
23.08.2010, 23:50 Uhr

whose
Posts: 2156
Nutzer 		@Ralf27:

Hm, das mit den Farben müßte man mal sehen, um es beurteilen zu können... "nicht richtig" ist ein ziemlich dehnbarer Begriff ;)

Eine Möglichkeit wäre, daß der "Farbraum" noch angepaßt werden müßte. Das ist z.B. eins der Probleme bei einem Palette-Modus (256 Farben).

Bei HAM wiederum mußt Du bedenken, wie der HAM-Modus funktioniert. Ich kann jetzt aus Deinem Code nicht direkt erkennen, ob Du das "Nachbarpixel-Problem" korrekt behandelst. Paßt Du jeweils den richtigen Farbanteil in Bezug auf den vorhergehenden Pixel an oder wandelst Du die Farbwerte "einfach so"? Bei letzterem müßte es auch horizontales "Tearing" geben, nicht nur "nicht richtige" Farben...
--
---

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

[ - Antworten - Zitieren - Direktlink - ]
24.08.2010, 13:55 Uhr

thomas
Posts: 7718
Nutzer
Zitat:
Original von Ralf27:
Und: ist wieder nur zum testen. Aber, die Farben kommen nicht so richtig hin. Ich versteh das nicht so ganz...

Du darfst nicht vergessen, daß du versuchst, 65536 mögliche Farben mit 252 Palette-Einträgen darzustellen. D.h. du behältst nur 0,38% der Farbinformationen, den Rest schmeißt du einfach weg. Daß das dem Originalbild kaum noch ähnlich sieht, dürfte klar sein.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]
24.08.2010, 16:41 Uhr

Thore
Posts: 2266
Nutzer 		Im HAM8 sollte er bei richtiger codierung 262144 Farben (abhängig) darstellen können :)

[ - Antworten - Zitieren - Direktlink - ]
24.08.2010, 20:16 Uhr

Ralf27
Posts: 2779
Nutzer 		Ähnliche HAM-Routinen habe ich beim BMPReader-Projekt eingesetzt. Daran sollte es nicht liegen. Ich erkenne aber daran, das ich wohl mehr Testbilder brauche. Bzw. kann ich hier auf dem AGA-Rechner nur AGA-Grafik darstellen.

Kurzum, ich brauch Referenzsoftware, bzw. ein Programm das mir das RGB16-Bild irgendwie auf meinem Rechner an die Scheibe wirft.

Vielleicht geht ja das Programm da oben richtig und das Bild hat seltsame Farben... :)

Also, mit welchem Programm kann ich RGB16-Bilder konvertieren und/oder anzeigen?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
24.08.2010, 20:50 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		Wo hast du denn die RGB16 Bilder her?
Gibt es zu dem Format eine Dokumentation?

Du solltest herausfinden, wie die Bits aufgeteilt sind.
Ich vermute, dass es 5+5+5 ist, nicht 5+6+5. Aber das kann man natürlich nicht wissen.

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

[ - Antworten - Zitieren - Direktlink - ]
24.08.2010, 21:29 Uhr

Ralf27
Posts: 2779
Nutzer 		Problem gefunden. Es war eine Eigenheit von MaxonBasic. Es ist einfach verrückt. Wenn man im obigen Code statt f& einfach f nimmt (es ist ja alles mit defint a-z als integer deklariert), dann sollte es zwar nicht richtig gehn, aber es geht?!?. Ich hab sowas schon vermutet und einfach mal getestet, daran hat es gelegen. Der Code läuft so.
Aber dennoch hab ich so ein ungutes Gefühl, obwohl jetzt die Farben scheinbar recht gut stimmen.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
25.08.2010, 15:46 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Wenn man im obigen Code statt f& einfach f nimmt (es ist ja alles mit defint a-z als integer deklariert), dann sollte es zwar nicht richtig gehn, aber es geht?!?.
Wenn Du glaubst, dass f& das gleich macht, wie DEFINT f ... f, dann verstehe ich nicht, wieso es nicht gehen sollte, wenn Du einfach f nimmst. Andererseits, wenn DEFINT f doch etwas anderes als f& bewirkt (das vermute ich mal), dann hast Du doch einen Hinweis darauf, wo der Unterschied liegt. Da Du z.B. r, g, und b und nicht r&, g&, und b& verwendet hast, gibt es ja schon mal mindestens eine Typkonvertierung, wenn Du f& verwendest.

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

[ - Antworten - Zitieren - Direktlink - ]
25.08.2010, 19:14 Uhr

Ralf27
Posts: 2779
Nutzer 		Der Unterschied ist folgender:

DEFINT a-z bedeutet das alle Variablen als WORD behandelt werden, also alle Variablen ohne Anhang. Eine Variable mit & wird als LONG behandelt.
Soweit sogut. Ich hab aber bei 16Bit aber 65536 Möglichkeiten, die aber mit einem WORD nicht speicherbar sind, in einem UWORD aber schon. Deswegen hatte ich ein LONG (f&) benutzt. Eine Zahl über 32767 würde ja ein Überlauf bedeuten. In diesem Fall ist es aber eigentlich egal, da ich ja mit der logischen Operation AND ja direkt an die Bits geh und diese dann auch gleich shifte. Da ist es wohl egal wie der Compiler die Daten in der Variable behandeln würde, also mit Vorzeichen oder nicht.

Lange Texte kurzer Sinn: Mich wundert es dennoch das es ein Unterschied macht...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
25.08.2010, 20:26 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Der Unterschied ist folgender:

DEFINT a-z bedeutet das alle Variablen als WORD behandelt werden, also alle Variablen ohne Anhang. Eine Variable mit & wird als LONG behandelt.
Dachte ich mir schon ;)
Zitat:
In diesem Fall ist es aber eigentlich egal, da ich ja mit der logischen Operation AND ja direkt an die Bits geh und diese dann auch gleich shifte.
Nicht unbedingt egal, ...
Zitat:
Da ist es wohl egal wie der Compiler die Daten in der Variable behandeln würde, also mit Vorzeichen oder nicht.
Das Vorzeichen ist eben nicht egal:

code:
f&=PEEKW(SADD(t$)+x+x)
r=(f& AND &hF800)>>11

Wenn die Basic-Arithmetik vorzeichenbehaftet ist, dann erweitert die Zuweisung des Ergebnisses von PEEKW (also WORD) nach f& (also LONG) den Wert um ein etwaiges Vorzeichen.

Liefert PEEKW also beispielsweise 0xABCD zurück, wird f& den Inhalt 0xFFFFABCD haben.

Wenn Du dann diesen Wert mit &hF800 via AND verknüpfst, und ich nehme mal an, &hF800 ist auch ein WORD, sonst müsstest Du &hF800& schreiben, wenn ich mich richtig entsinne, dann wird auch &hF800 vorzeichengerecht erweitert, also zu 0xFFFFF800.

Dann ist das Ergebnis der AND-Verknüpfung 0xFFFFA800, und nach dem Shiften entweder 0x001FFFF5 oder 0xFFFFFFF5, je nachdem, ob beim Shiften das Vorzeichen ebenfalls berücksichtigt wird oder nicht, ist aber auch egal, denn nach dem Abschneiden bei der Zuweisung zu r, enthält dann r auf jeden Fall den Wert 0xFFF5 und nicht, wie von Dir gewünscht, 0x15.

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

[ - Antworten - Zitieren - Direktlink - ]
25.08.2010, 20:40 Uhr

Ralf27
Posts: 2779
Nutzer 		Heureka, jetzt wird da ein Schuh draus! :)

Hab es eben getestet:

wenn ich

r=(f& AND &hF800)>>11
oder
r=(f AND &hF800&)>>11
mach, dann liefert es Käse.
Wenn ich aber
r=(f AND &hF800)>>11
oder
r=(f& AND &hF800&)>>11
tippe, dann stimmts!

Also liegt der Hund in der internen Konvertierung begraben.


Teilweise wird es wirklich sehr spitzfindig... so ist eben das Programmieren. Es kommt auf jede Kleinigkeit an.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
25.08.2010, 21:54 Uhr

Ralf27
Posts: 2779
Nutzer 		Hab eben etwas Speedup gemacht und komme jetzt auf 3,5 Sekunden für ein 800*600*16 Bild auf HAM8 konvertieren und anzeigen auf einen 800*600*Ham8-Screen mit AGA auf einem echten Amiga mit 060er. Kann man eigentlich lassen, oder? I-)

EDIT: 2,5 Sekunden. Es könnte noch schneller gehn, aber das wird dann in MaxonBasic zu aufwendig.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 26.08.2010 um 00:01 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
26.08.2010, 02:18 Uhr

whose
Posts: 2156
Nutzer 		@Ralf27:

Interpretiert wärs eine gute Zeit I-)
--
---

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

[ - Antworten - Zitieren - Direktlink - ]
27.08.2010, 13:21 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Es könnte noch schneller gehn, aber das wird dann in MaxonBasic zu aufwendig.
Kommt drauf an, was Du schon alles gemacht hast.

Wenn Du das hier:
Zitat:
Original von thomas:
r = (r * 5) 31
g = (g * 6) 63
b = (b * 5) 31
PSET(x,y),r+g*6+b*42

pro Punkt berechnest (dass Du nicht mehr PSET benutzt, ist schon klar), dann kannst Du einiges rausholen, in dem Du die Divisionen los wirst.

code:
r = (r*21)>>7
g = (g*49)>>9
b = (b*21)>>7
PSET(x,y),r+g*6+b*42
Natürlich wird es noch besser, wenn man noch MaxonBasic dazu bringt, Shifts effizient umzusetzen. Wenn ich mich recht entsinne, war das eine Art Glücksspiel.

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

[ - Antworten - Zitieren - Direktlink - ]
27.08.2010, 13:24 Uhr

Holger
Posts: 8116
Nutzer 		Mir ist gerade aufgefallen, dass Du ja jetzt nach HAM konvertierst, also sieht dann Code inzwischen wohl anders aus, als am Anfang geschrieben. Musst Du mal posten, um herauszufinden, wie man diesen noch optimieren kann.

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

[ - Antworten - Zitieren - Direktlink - ]
27.08.2010, 20:18 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Mir ist gerade aufgefallen, dass Du ja jetzt nach HAM konvertierst, also sieht dann Code inzwischen wohl anders aus, als am Anfang geschrieben. Musst Du mal posten, um herauszufinden, wie man diesen noch optimieren kann.

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

Zur Zeit sieht es so aus:

code:
LIBRARY"dos"
DECLARE FUNCTION xOpen&LIBRARY
LIBRARY"exec"
DECLARE FUNCTION AllocVec&LIBRARY
LIBRARY"graphics"
SCREEN 1,800,600,8,1,&H59824:REM 2048
WINDOW 2,,,128,1
 
 REM rgb, 5,6,5, max 32,64,32
 h&=xOpen&(SADD("cache:rgb16.test"+CHR$(0)),1005):IF h&=0 THEN Ende
 l&=800&*600&*2&
 mem&=AllocVec&(l&,0):IF mem&=0 THEN Ende
 xRead h&,mem&,l&
 xClose h&:h&=0
 rp&=WINDOW(8)
 CONST memsp&=800:REM memsp&=((800+15)16)*16
 t#=TIMER
 p&=0
 FOR y=0 TO 599
  ar=200:ag=200:ab=200
  FOR x=0 TO 799
   f=PEEKW(mem&+p&+p&)
   r=f>>11:REM r=(f AND &hF800)>>11
   g=(f AND &h7E0)>>5
   b=f AND 31
   u=ABS(ar-r)*2:m=1
   ug=ABS(ag-g)
   IF ug>u THEN u=ug:m=2
   IF ABS(ab-b)*2>u
    ab=b:f=64+b+b
   ELSE 
    IF m=1 THEN ar=r:f=128+r+r ELSE ag=g:f=192+g
   END IF
   POKE mem&+p&,f
   INCR p&
  NEXT
 NEXT 
 WriteChunkyPixels rp&,0,0,799,599,mem&,memsp&
Ende:
 IF h& THEN xClose h&
 IF mem& THEN FreeVec mem&
 PRINT TIMER-t#

Z.b. bei der Rot-Berechung, da kann man sich ja was sparen. :)
Bei Rot und Grün mußte ich bei der Unterschiedsberechnung noch beide Werte verdoppen, da der Grün-Wert doppelt so groß werden kann.

Mann kann aber noch was rausnehmen, aber dann wird MBasic interesanterweise langsamer(!). Schaut euch mal die Variable m an. Die Schreit förmlich nach Streichung. Aber, mit dieser Vereinfachung wird MaxonBasic langsamer?!?
Mal folgender Codeauschnitt:
code:
...
   u=ABS(ar-r)*2
   ug=ABS(ag-g)
   IF ug>u THEN u=ug
   IF ABS(ab-b)*2>u
    ab=b:f=64+b+b
   ELSE 
    IF u=ug THEN ag=g:f=192+g ELSE ar=r:f=128+r+r
   END IF
 ...
Ist seltsamerweise langsamer. Ist auch in C die Abfrage von einer Variablen zu einer Konstanten wesentlich schneller als zwischen zwei Variablen?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
27.08.2010, 21:26 Uhr

Ralf27
Posts: 2779
Nutzer 		Hachja, bei HAM8 hab ich ja quasi 18Bit. Ich benutze aber die ersten festen Farben nicht für das Bild. Gibt es eigentlich irgendwo Beispiele für HAM-Berechnungen die die ersten festen Farben mit einbeziehen? Oder ist der Overkill zu viel, bzw. bringt es überhaupt etwas?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
27.08.2010, 22:53 Uhr

Thore
Posts: 2266
Nutzer 		Die Berechnungsschemen sind recht einfach (hier der müdigkeithalber aus Wikipedia kopiert...)

HAM6
543210
00wxyz - Farbindex wxyz in eine 16 Einträge lange Basisfarbenpalette
01wxyz - Behalte den Farbwert des vorherigen Pixels, aber setze die (obersten) vier Bit von Blau auf wxyz
10wxyz - Behalte den Farbwert des vorherigen Pixels, aber setze die (obersten) vier Bit von Rot auf wxyz
11wxyz - Behalte den Farbwert des vorherigen Pixels, aber setze die (obersten) vier Bit von Grün auf wxyz

HAM8
76543210
00uvwxyz - Farbindex uvwxyz in eine 64 Einträge lange Basisfarbenpalette
01uvwxyz - Behalte den Farbwert des vorherigen Pixels, aber setze die obersten sechs Bit von Blau auf uvwxyz
10uvwxyz - Behalte den Farbwert des vorherigen Pixels, aber setze die obersten sechs Bit von Rot auf uvwxyz
11uvwxyz - Behalte den Farbwert des vorherigen Pixels, aber setze die obersten sechs Bit von Grün auf uvwxyz

[ - Antworten - Zitieren - Direktlink - ]
27.08.2010, 23:01 Uhr

Ralf27
Posts: 2779
Nutzer 		Genau das macht ja auch das Programm da oben. Ich meinte mehr auch die 64 Grundfarben bei HAM8 mit zu benutzen. Denn diese kann man mit jeweils 8Bit-Tiefe einstellen, die "erweiterten" Farben nur mit jeweils 6Bit. Also, ich benutze oben die Grundfarben nicht. Gibt es da Ideen, Tips, etc. dazu?

EDIT: Bin gerade bei Wikipedia und lese mir gerade die passenden Infos dazu durch wie man am besten ein Bild mit den Grundfarben optimiert darstellt.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 27.08.2010 um 23:04 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
28.08.2010, 12:40 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Ist seltsamerweise langsamer. Ist auch in C die Abfrage von einer Variablen zu einer Konstanten wesentlich schneller als zwischen zwei Variablen?
Kann man so nicht pauschalisieren. Die CPU unterscheidet ja nicht einfach zwischen Variable und Konstanten, sondern zwischen Registern, quick Konstanten, immediate Konstanten und Speicherzugriffen. Und man kann nicht sagen, dass Variablen oder Konstanten grundsätzlich auf eine bestimmte Art umgesetzt werden. Das hängt sowohl von den Fähigkeiten des Optimierers, als auch dem konkreten Code ab.

Der Vergleich mit 1 oder 2 lässt sich jedenfalls ziemlich effizient umsetzen, noch leichter lässt sich allerdings bei zwei möglichen Zuständen der Vergleich mit 0 und nicht 0 umsetzen. Ob es dann wirklich effizient umgesetzt wird, ist die andere Frage.

Zitat:
Original von Ralf27:
Gibt es eigentlich irgendwo Beispiele für HAM-Berechnungen die die ersten festen Farben mit einbeziehen? Oder ist der Overkill zu viel, bzw. bringt es überhaupt etwas?
Beispiele kenn ich jetzt keine. Und ob das mit den unteren zwei Bits was bringt, weiß ich nicht. Allerdings dürfte die Tatsache, dass man mit den Grundfarben mehr als einen Farbkanal pro Pixel setzen kann, die Qualität durchaus verbessern.

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

[ - Antworten - Zitieren - Direktlink - ]
28.08.2010, 13:05 Uhr

Holger
Posts: 8116
Nutzer 		Du kannst den bedingten Code auch komplett ersetzen, wenn Du geringügige Code-Doppelung in Kauf nimmst:
BASIC code:
LIBRARY"dos"
DECLARE FUNCTION xOpen&LIBRARY
LIBRARY"exec"
DECLARE FUNCTION AllocVec&LIBRARY
LIBRARY"graphics"
SCREEN 1,800,600,8,1,&H59824:REM 2048
WINDOW 2,,,128,1

 REM rgb, 5,6,5, max 32,64,32
 h&=xOpen&(SADD("cache:rgb16.test"+CHR$(0)),1005):IF h&=0 THEN Ende
 l&=800&*600&*2&
 mem&=AllocVec&(l&,0):IF mem&=0 THEN Ende
 xRead h&,mem&,l&
 xClose h&:h&=0
 rp&=WINDOW(8)
 CONST memsp&=800:REM memsp&=((800+15)16)*16
 t#=TIMER
 p&=0
 FOR y=0 TO 599
  ar=200:ag=200:ab=200
  FOR x=0 TO 799
   f=PEEKW(mem&+p&+p&)
   r=f>>11:REM r=(f AND &hF800)>>11
   g=(f>>5) AND 63
   b=f AND 31
   u=ABS(ar-r)*2
   ug=ABS(ag-g)
   IF ug>u THEN
    IF ABS(ab-b)*2>ug
     ab=b:f=64+b+b
    ELSE
     ag=g:f=192+g
    END IF
   ELSE
    IF ABS(ab-b)*2>u
     ab=b:f=64+b+b
    ELSE
     ar=r:f=128+r+r
    END IF
   END IF
   POKE mem&+p&,f
   INCR p&
  NEXT
 NEXT 
 WriteChunkyPixels rp&,0,0,799,599,mem&,memsp&
Ende:
 IF h& THEN xClose h&
 IF mem& THEN FreeVec mem&
 PRINT TIMER-t#

Ob das schneller ist, hängt von verschiedenen Bedingungen ab. Neben der Art und Weise, wie der Compiler das umsetzt, auch von der jeweiligen CPU. Kann also z.B. sein, dass diese Variante auf einem 68060 schneller ist, auf einem 68020 dagegen langsamer...

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

[ - Antworten - Zitieren - Direktlink - ]
28.08.2010, 22:24 Uhr

Ralf27
Posts: 2779
Nutzer 		Von der Geschwindigkeit sind beide absolut gleich, bzw. kann da keinen Unterschied feststellen. MBasic ist da halt eine Welt für sich und mit Logik kommt man da wohl teilweise nicht weiter. Da hilft wirklich nur testen, testen und wieder testen.


Ok, aber jetzt zu dem anderen Thema mit denn 64 Grundfarben, der Erkennung der wichtigsten Farben im Farbraum, etc. Das liest sich via Wiki recht komplex. Ok, das ganze wäre bestimmt ganz interesant, aber ich vermute mal das die meisten Programme das nicht machen, da es einfach zu viel Rechenleistung kostet und HAM ist nicht gerade schnell...
Aber, es wäre schon recht interesant. :)

EDIT: Was ich vergessen habe zu tippen: In der einen Zeile hat am Schluss ein Buchstabe gefehlt. Beim zweiten "IF ABS(ab-b)*2>ug" hat am Schluss das g gefehlt. Das hatte ich beim testen schon berücksichtigt.

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 28.08.2010 um 22:26 Uhr geändert. ]

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

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
EDIT: Was ich vergessen habe zu tippen: In der einen Zeile hat am Schluss ein Buchstabe gefehlt. Beim zweiten "IF ABS(ab-b)*2>ug" hat am Schluss das g gefehlt.
Hä? Wieso gefehlt? Das ist doch exakt der Unterschied zwischen den beiden Zeilen, dass, wenn ug>u mit ug, ansonsten aber mit u verglichen wird. Du machst es doch in Deinem ursprünglichen Code genauso. Nur dass Du mit immer mit u vergleichst, aber wenn ug>u ist, dann weist Du u den Wert von ug zu. Kurz gesagt, Du vergleichst immer mit dem größeren der beiden. Hast Du Deinen eigenen Code nicht verstanden? ;)

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

[ - Antworten - Zitieren - Direktlink - ]
29.08.2010, 12:20 Uhr

Ralf27
Posts: 2779
Nutzer 		Uf, ja ich glaub du hast recht. War wohl schon zu spät für mich. :)
Denn eigentlich HAM-Code hab ich damals für BMPReader geschrieben. Es sucht eigentlich nur die größten Unterschiede zwisch gesetze und zu setzendem Wert und das bei R,G,B und denn Wert mit dem größten Unterschied wird gesetzt.
Der Code sah ursprünglich optisch einfacher aus, ich hab da aber Schritt für Schritt versucht da zu optimieren um die Zeiten wenigstens auch mit MBasic einigermaßen human zu halten.

Aber, wie macht man das eigentlich richtig mit dem ominösen 3D-Farbraumberechnungen? So einfach wie ich das da oben gemacht habe? Wohl kaum... :)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]
29.08.2010, 12:21 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Ok, aber jetzt zu dem anderen Thema mit denn 64 Grundfarben, der Erkennung der wichtigsten Farben im Farbraum, etc. Das liest sich via Wiki recht komplex. Ok, das ganze wäre bestimmt ganz interesant, aber ich vermute mal das die meisten Programme das nicht machen, da es einfach zu viel Rechenleistung kostet und HAM ist nicht gerade schnell...
Na ja, Du musst Dich schon entscheiden, ob es eher um perfektes Ergebnis geht, wie bei einem Bildkonvertierer, oder um ein halbwegs schnelles Ergebnis, wie bei einer Vorschau oder in einem Spiel.

Wenn Du bei der schnellen Variante bleiben willst, kannst Du ja trotzdem die Grundfarben mit einer fixen Palette verwenden. Du erweiterst Deinen schon vorhanden Algorithmus dahingehend, dass Du beim Vergleichen der Abweichungen zu den drei Farbkanälen noch einen Vergleich mit der Palettenfarbe, die der gewünschten Farbe am nächsten kommt, dazunimmst und dann eben entweder einen Farbkanal oder die Palettenfarbe setzt.

Möglicherweise rentiert es sich qualitativ, wenn man der Abweichung von der gewünschten Helligkeit eine höhere Priorität gibt, als der Abweichung im Farbton. Und dann ist natürlich noch die Frage, welche fixe Grundpalette man verwendet. Neben der Variante, Grundfarben wie bei einer normalen 2^n Farbpalette zu setzen wie in Deinem ersten Beispiel zu setzen, könnte man auch 64 gleichverteilte Grautöne verwenden und Farbtöne ausschließlich über HAM verändern.

Und wenn es nicht um das Speichern als IFF, sondern lediglich um das Anzeigen auf dem Bildschirm geht, kann man natürlich noch den Copper verwenden, und u.U. Geschwindigkeit und Qualität gleichzeitig verbessern.

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

[ - Antworten - Zitieren - Direktlink - ]
29.08.2010, 12:22 Uhr

Thore
Posts: 2266
Nutzer 		Zur Geschwindigkeit:
Du könntest eine Library in Assembler oder C++ schreiben, die Deine Convertierungen vornimmt, und im BASIC Code dann einbinden.
Das könnte einen zusätzlichen Boost bringen.

[ - Antworten - Zitieren - Direktlink - ]
29.08.2010, 12:26 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Aber, wie macht man das eigentlich richtig mit dem ominösen 3D-Farbraumberechnungen? So einfach wie ich das da oben gemacht habe? Wohl kaum... :)
Nee, das Problem mit den Farbraumberechnungen ist, dass sie das Bild als Ganzes betrachten, der HAM-Modus aber Pixel-lokale Eigenarten aufweist. Und bezüglich der Konvertierung von TrueColor nach beispielsweise 256 Farben haben sich etliche kluge Leute hingesetzt und Algorithmen entwickelt, aber die wenigsten diese Leute haben sich mit dem HAM-Modus beschäftigt ;)

Du hast also die Wahl zwischen schon bestehenden, ausgereiften Algorithmen ohne HAM, oder eigenen Algorithmen mit HAM.

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

[ - Antworten - Zitieren - Direktlink - ]

-1- [ - Beitrag schreiben - ]


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


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