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

amiga-news.de Forum > Programmierung > ARGB Pixel oder Type kopieren in C [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

18.05.2007, 17:12 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Hallo !

Ich schreibe gerade einige Bildverarbeitungs Alogrithmen in C.

Wie stellt ihr da einen RGB oder ARGB Pixel dar ?

Ich habe folgendes gemacht (nehmen wir mal ARGB)

code:
struct ARGBPixel {
  unsigend char A,R,G,B;
};


Spaeter mache ich:

code:
struct ARGBPixel* MySourcePixel = (struct ARGBPixel*)SourcePixelArrayPtr;
struct ARGBPixel* MyDestPixel   = (struct ARGBPixel*)DestPixelArrayPtr;

MyDestPixel[n] = MySourcePixel[n];
oder
*MyDestPixel++ = *MySourcePixel++;


Geht sowas ueberhaupt ? Kann es gerade nicht testen und muss das blind implementieren.
Was waere die eleganteste Method, wenn man bedenkt dass ich auch auf die RGB Komponenten drauf zugreifen muss, also nicht nur kopieren so wie oben.

--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

19.05.2007, 12:41 Uhr

Holger
Posts: 8116
Nutzer
@Der_Wanderer:
Zum Kopieren solltest Du vorzugsweise die Kopierroutine des Betriebssystems benutzen. Abgesehen davon funktioniert der Ansatz durchaus, ist aber nicht als portables C zu bezeichnen, da er Annahmen über das Alignment innerhalb von C-Strukturen enthält. Es ist dann doch sauberer, die Pixel als Array von bytes zu betrachten.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

19.05.2007, 12:57 Uhr

Der_Wanderer
Posts: 1229
Nutzer
@Holger

Ja, danke. Ich kopiere ja nicht das gesamte Array linear, sondern immer nur Pixelweise, da meine Routine im Source Pixel durchaus Spruenge macht, z.B. beim Scalieren, oder ich zwischendurch an den R G B Komponenten rumschrauben will.

Meine Frage war hauptsaechlich, ob

MyDestPixel[n] = MySourcePixel[n];

ok ist, da es kein Primitiver Typ ist, sondern "ARGBPixel".
In Blitzbasic z.B. muss man dafuer einen extra Befehl nehmen,
"CopyType" wenn man einen komplexen Datentyp kopieren will.

Ja, ich mache dadurch eine Annahme ueber das alignment, aber
gibt es denn ueberhaupt eine realistische Platform, wo die Bytes
nicht direkt hintereinander stehen wuerden ?

--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

19.05.2007, 13:08 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Der_Wanderer:
@Holger

Ja, danke. Ich kopiere ja nicht das gesamte Array linear, sondern immer nur Pixelweise, da meine Routine im Source Pixel durchaus Spruenge macht, z.B. beim Scalieren, oder ich zwischendurch an den R G B Komponenten rumschrauben will.


Ich denke, Holger meinte hier schon das Kopieren der einzelnen Struktur... ok, ältere Compiler, die Struktur-Kopien nicht unterstützen, sollte man eigentlich nicht mehr einsetzen, aber der eine oder andere benutzt evtl. noch einen solchen Compiler, spätestens da gibt es dann Probleme, die es bei Einsatz von z.B. CopyMem() nicht gibt (ich hatte eine ähnliche Frage mal vor einiger Zeit gestellt).

Zitat:
Ja, ich mache dadurch eine Annahme ueber das alignment, aber
gibt es denn ueberhaupt eine realistische Platform, wo die Bytes
nicht direkt hintereinander stehen wuerden ?


Mir ist da jetzt auf Anhieb keine bekannt, aber der Trend scheint zu 16Bit/Gun zu gehen...

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 19.05.2007 um 13:09 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

19.05.2007, 13:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Meine Frage war hauptsaechlich, ob

MyDestPixel[n] = MySourcePixel[n];

ok ist, da es kein Primitiver Typ ist, sondern "ARGBPixel".

Ja, das geht.
Zitat:
Ja, ich mache dadurch eine Annahme ueber das alignment, aber
gibt es denn ueberhaupt eine realistische Platform, wo die Bytes
nicht direkt hintereinander stehen wuerden ?

Kann ich so jetzt nicht sagen. Dass gehört ja zu den Dingen, über die ich normalerweise nicht nachdenken will...

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

19.05.2007, 13:41 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Ich denke, Holger meinte hier schon das Kopieren der einzelnen Struktur...

Nicht ganz. Eher, dass bereits beim Kopieren von zwei hintereinander liegenden Pixeln das Kopieren über die entsprechende OS-Routine effizienter sein kann. Compiler, die das Kopieren einer Struktur nicht unterstützten, berücksichtige ich im Allgemeinen nicht.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

19.05.2007, 18:22 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Ja wuerde dann der Compiler nicht auch zur OS routine greifen ?
Ansonsten waere jas ja Speed verschenkt.

Aber lohnt es sich, bei vier Bytes ein CopyMem zu bemuehen ?
Bisher caste ich einen long* drueber und mache eine einfache Zuweisung. Schaetze aber mal ein Type Copy einez Types von 4Byte wuerde in vergleichbarem Code enden.
--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

20.05.2007, 14:46 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Ja wuerde dann der Compiler nicht auch zur OS routine greifen?

Nein, das tun Compiler in den seltensten Fällen.
Zitat:
Ansonsten waere jas ja Speed verschenkt.
Es gibt tausende Möglichkeiten, Speed zu verschenken...
Zitat:
Aber lohnt es sich, bei vier Bytes ein CopyMem zu bemuehen ?
Nein, deshalb sprach ich ja von mehr als einem Pixel. Man sollte auch prüfen, ob für den jeweiligen Fall CopyMemQuick anwendbar wäre.
Zitat:
Bisher caste ich einen long* drueber und mache eine einfache Zuweisung. Schaetze aber mal ein Type Copy einez Types von 4Byte wuerde in vergleichbarem Code enden.
Das wäre der Idealfall, muss aber nicht sein. Formal bedeutet eine Zuweisung einer Struktur ein Zuweisen alle enthaltenen Elemente. Da es auch keine Alignment-Regel gibt, dass diese Struktur immer an durch 4 teilbare Adressen liegen muss, kann der Compiler die optimale Form nur dann wählen, wenn er zur compile-Zeit voraussagen kann, ob der verwendete pointer diese Bedingung erfüllt.

Die Variante mit dem expliziten long* cast ist die effizienteste, wenn es um genau ein Pixel geht. Die Copy-Routinen des OS sind effizienter für mehrere LONGs, sie benutzen halt mehr Prozessor-Register und mehr oder weniger Loop-Unrolling. Ersteres kann man in C kaum genauso implementieren, letzteres will man nicht.

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

[ - Antworten - Zitieren - Direktlink - ]

21.05.2007, 08:22 Uhr

akl
Posts: 265
Nutzer
Man kann eigentlich davon ausgehen - auch wenn das vielleicht nicht auf alle hypothetisch möglichen Compiler zutrifft - dass Byte-Elemente in Strukturen nur dann (2,4,8,16,...)-aligned werden, wenn sich davor/dahinter Elemente befinden, für die das Sinn macht. Wenn eine Struktur nur Bytes enthält, dann also gar nicht. Falls doch, bleiben noch Compiler-Switches um das abzuschalten. -- Nun mag man argumentieren, dass das nicht standard-konform sei. Das sind viele AmigaOS-Strukturen aber auch nicht (die enthalten z.B. Pad-Bytes) und nicht jeder Quellcode hat Anspruch auf universelle Portabilität. -- Was Portabilität angeht, würde das Beispiel jedoch übrigens schon an der Endianess-Problematik scheitern.

[ - Antworten - Zitieren - Direktlink - ]

21.05.2007, 11:17 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von akl:
Nun mag man argumentieren, dass das nicht standard-konform sei. Das sind viele AmigaOS-Strukturen aber auch nicht (die enthalten z.B. Pad-Bytes)

Das AmigaOS ist ja auch durch und durch unportabel. Mal abgesehen davon, dass Alignment, Padding und Reihenfolge der Struktureinträge oft willkürlich und ineffizient gewählt wurden. Einfachstes Beispiel: List-Node, Grundlage der meisten anderen OS-Strukturen: der häufig verwendete Name-Pointer liegt nicht auf einer durch vier teilbaren Adresse, weil die deutlich seltener benutzten bytes für Typ und Priorität davor liegen => grundlos verschwendete Performance. Oftmal hätte man sich auch sämtliche padding-bytes mit einer geringfügig anderen Reihenfolge der Struktureinträge sparen können.
Zitat:
... und nicht jeder Quellcode hat Anspruch auf universelle Portabilität.
Richtig, deshalb steht ja oben auch nur, dass es nicht portabel wäre, nicht, dass es grundsätzlich unbrauchbar oder nicht empfehlenswert wäre.
Zitat:
-- Was Portabilität angeht, würde das Beispiel jedoch übrigens schon an der Endianess-Problematik scheitern.
Nö, ARGB sind nunmal vier bytes in der namensgebenden Reihenfolge, so wie BGRA auch vier bytes, nur in umgekehrter Reihenfolge, sind. Wenn man auf bytes byteweise zugreift, kann es gar keine Endianess-Probleme geben. Solange man die long-Zugriffe nur zum Kopieren der Struktur benutzt und nicht irgendwelche Annahmen darüber macht, wie die bytes in dem long liegen, hat man da auch keine Endianess-Probleme.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

21.05.2007, 12:03 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Wenn ich mehrere Pixel kopiere, verwende ich natürlich CopyMem.
Aber meistens muss man die jeweiligen Pixel manipulieren oder individuall selektieren, d.h. ich muss auf jeden Pixel einzeln eingehen.

Danke für den Hinweis mit der Endianess Problemeatik. Da der Code in AROS einfliessen soll, muss ich darauf natürlich achten.



--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

21.05.2007, 12:42 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von Der_Wanderer:
Ja wuerde dann der Compiler nicht auch zur OS routine greifen ?
Ansonsten waere jas ja Speed verschenkt.


Im Gegenteil! In der Regel verwenden die Compiler interne, entsprechend optimierte Methoden für Speicherkopien. Im Gegensatz zur generischen OS-Routine kann der Compiler z.B. Annahmen über Alignment etc. treffen. Dazu kommt oft noch der eingesparte Funktionsaufruf...

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > ARGB Pixel oder Type kopieren in C [ - Suche - Neue Beiträge - Registrieren - Login - ]


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