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: 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: Mir ist da jetzt auf Anhieb keine bekannt, aber der Trend scheint zu 16Bit/Gun zu gehen... Grüße -- --- µA1 PPC 750GX-800 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:Ja, das geht. Zitat: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: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:Nein, das tun Compiler in den seltensten Fällen. Zitat:Es gibt tausende Möglichkeiten, Speed zu verschenken... Zitat: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: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: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: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: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: 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. |