Array too large

Hallo!
Ich bastle momentan an einem Programm, womit ich Regionen in einem Schwarz/Weiss Bild erstellen und auflisten kann (verwende OpenCv zum einlesen und Bilder anzeigen).

Ich verwende selbstgeschriebene Klassen zum Speichern:
Die einfachste Klasse: Point2D(), die 3 Integer Werte für die X und Y Koordinate sowie den zugehörigen Grauwert.
Zudem gibt es eine Klasse Area, die ein Array von Point2D enthält. Diese Punkte sind somit in dieser „Area“ = Region enthalten.
Nun wollte ich von 256 Bildern alle Regionen (bis 100 Rgionen maximal) speichern, und habe ein Array

Area[256][100]

erstellt. Jedoch meint der Compiler (Dev-C++ 4.9.9.2), das Array sei zu groß.

Liegt dies eventuell an den Deklarationen?
Points2D.h

class Point2D {
 public:
 int x, y, gray;
 Point2D(int,int);
 Point2D();
 Point2D(int,int,int);
 int equal(Point2D\*);
 void dump();
};

Area.h

#define MAX\_IMG\_WIDTH 640
#define MAX\_IMG\_HEIGHT 480
#define GRAY\_VALUES 256
class Area {
 public:
 /\*constructors\*/
 Area(); //tested
 Area(Point2D\*); //tested 

 /\*methods\*/ 
 //is a Point inside the area?
 int isInArea(Point2D\*); //tested
 //is a Point neighbor to a Point inside the area?
 int neighbor(Point2D\*); //tested
 //add a Point to the area
 int add(Point2D\*); //tested
 //add multiple Points to the area
 int add(Point2D\*[],int); //tested
 //merging two areas
 int merge(Area\*); //tested
 //deleting a Point of the area 
 int del(Point2D\*); //necessary??

 //returns a Point at given index \> 0
 Point2D\* point(int); //tested
 //returns the total number of points stored inside the area
 int total(); //tested
 //display all points within this area
 void dump(); //tested
 //display the area as an IplImage
 void displayAsIplImg(CvSize,int);

 //variables, how big the image is - makes it easier to search for specific Points
 int img\_width;
 int img\_height;

 private:
 /\*intern variables\*/
 Point2D \*area[MAX\_IMG\_WIDTH][MAX\_IMG\_HEIGHT];
 //how many points are inside the area?
 int totalPoints;
 /\*for faster indexing and retrieving points
 stores how many points on a given x coordinate are stored in the area\*/
 int pOnX[MAX\_IMG\_WIDTH];
 //need to initialise the pOnX
 void init();
};

Noch ein Wort zur Area-Klasse:
Meine Idee fürs schnellere durchsuchen der Area war, daß der erste Index einfach die x-Koordinate des Punktes ist und der nächste Punkt einfach dann weiter hintereinander gespeichert wird.
Um zu verfolgen, wieviele Punkte insgesammt bei einer bestimmten x-Koordinate gespeichert sind, existiert das pOnX Array (sizeof(area[x]) liefert leider nicht das zurück, was ich hoffte… :frowning: ). Somit kann z.B. für den Test, ob ein Punkt (Point2D) in der Area liegt, mir relativ kleinem, linearem Aufwand durchgeführt werden.

Ich könnte mir vorstellen, daß ich den Arrays zu viel Speicher zugewiesen habe.
Aber ich weiss leider auch keine Abhilfe, denn man kann (soweit ich weiß), kein Array erstellen ohne ihm eine Größe zuzuweisen.

Ich hoffe, ich habe mich nicht zu konfus ausgedrückt und man kann mir folgen + helfen.

Grüße

Björn

Nun wollte ich von 256 Bildern alle Regionen (bis 100 Rgionen
maximal) speichern, und habe ein Array

Area[256][100]

erstellt. Jedoch meint der Compiler (Dev-C++ 4.9.9.2), das
Array sei zu groß.

Äääääh… hast du da mal in irgendeiner Form drüber nachgedacht? Jede Instanz von Area verbrät in Area::area mal locker über 1MiB Speicher. Du versuchst mit dem Array dann, 25600 mal sowas auf den Stack zu packen. Das sind über 29GiB Speicher. Auf dem Stack!

Eigentlich hatte ich es erst einmal „nur so“ heruntergeschrieben, und mir bei der ersten Fehlermeldung dazu Gedanken gemacht.

Nur kann ich mir leider nicht recht vorstellen, was ich nun machen kann um diess Problem zu lösen.
Wie soll ich sonst die Daten speichern können?
Da bin ich momentan seeehr ratlos :frowning:

Grüße

Björn

Hallo,

Eigentlich hatte ich es erst einmal „nur so“
heruntergeschrieben, und mir bei der ersten Fehlermeldung dazu
Gedanken gemacht.

Vielleicht doch lieber erstmal Gedanken machen und dann runterschreiben?

Nur kann ich mir leider nicht recht vorstellen, was ich nun
machen kann um diess Problem zu lösen.

Erstens lies die manpages zum Befehl „new“ bzw. „delete“, um den heap und nicht den stack zu nutzen. Zweitens, überlege Dir, ob Du wirklich solche Datenmengen im Speicher halten willst, oder ob Du nicht doch auf (schnelle) Festplatten ausweichen willst.

Gruß

Fritze

Hi!

Vielleicht doch lieber erstmal Gedanken machen und dann
runterschreiben?

Zu den Algorithmen habe ich mir ja Gedanken gemacht. Speichermanagement habe ich leider nie gelernt, da Java bei uns bisher vorherschend war und man sich dort nicht sooo viele Gedanken zu machen mußte.

Erstens lies die manpages zum Befehl „new“ bzw. „delete“, um
den heap und nicht den stack zu nutzen. Zweitens, überlege
Dir, ob Du wirklich solche Datenmengen im Speicher halten
willst, oder ob Du nicht doch auf (schnelle) Festplatten
ausweichen willst.

Werde ich einmal machen.
Hoffentlich kriege ich den Mist dann unter :wink:

Grüße

Björn

Hallo!
Ich bastle momentan an einem Programm, womit ich Regionen in
einem Schwarz/Weiss Bild erstellen und auflisten kann
(verwende OpenCv zum einlesen und Bilder anzeigen).

Ich verwende selbstgeschriebene Klassen zum Speichern:
Die einfachste Klasse: Point2D(), die 3 Integer Werte für die
X und Y Koordinate sowie den zugehörigen Grauwert.

Hallo,

etwas speichern ohne Nachdenken geht NIE. Nur mal so als Anfangsschritt: deine erste Klasse enthält 2 Koordinaten und einen Grauwert. Für das Speichern in einem Bildarray sind die Koordinaten aber vollkommen überflüssig, weil die sich ja aus den Indexen des Arrays ergeben - für ein VGA-Bild nimmt man eben ein Array von 640 x 480 Grauwerten. Du würdest da schon 614400 Integer zusätzlich und völlig sinnlos abspeichern: in deinem Array steht dann an Stelle [300,200] drin X=300, Y=200 - das wusste ich vorher schon.

Gruss Reinhard

Hi!

Hallo,

etwas speichern ohne Nachdenken geht NIE. Nur mal so als
Anfangsschritt: deine erste Klasse enthält 2 Koordinaten und
einen Grauwert. Für das Speichern in einem Bildarray sind die
Koordinaten aber vollkommen überflüssig, weil die sich ja aus
den Indexen des Arrays ergeben - für ein VGA-Bild nimmt man
eben ein Array von 640 x 480 Grauwerten. Du würdest da schon
614400 Integer zusätzlich und völlig sinnlos abspeichern: in
deinem Array steht dann an Stelle [300,200] drin X=300, Y=200

  • das wusste ich vorher schon.

Gruss Reinhard

Nicht wirklich, Ich möchte ja nicht jedes Bild sammt Koordinaten speichern - da würde ein Array wirklich reichen.
Es geht immer um Regionen, d.h. zusammenhänge Pixel aus dem Bild.
Und da würde ich mehr Speicher verschwenden, wenn ich dort die zur Region gehörenden Pixel in einem so großen Array speichern würde.
Da ist ein Array von Punkten effektiver und schneller drauf zuzugreifen. Zudem würde für Vergleiche, ob ein Pixel zu einer Region gehört oder ob ein Pixel Nachbar zu einer Region ist (und somit eventuell zur Region dann auch dazugehört) viel umständlicher Ausfallen.

Grüße

Björn

Hallo Björn,

etwas speichern ohne Nachdenken geht NIE.

Nicht wirklich, Ich möchte ja nicht jedes Bild sammt
Koordinaten speichern - da würde ein Array wirklich reichen.
Es geht immer um Regionen, d.h. zusammenhänge Pixel aus dem
Bild.
Und da würde ich mehr Speicher verschwenden, wenn ich dort die
zur Region gehörenden Pixel in einem so großen Array speichern
würde.
Da ist ein Array von Punkten effektiver und schneller drauf
zuzugreifen. Zudem würde für Vergleiche, ob ein Pixel zu einer
Region gehört oder ob ein Pixel Nachbar zu einer Region ist
(und somit eventuell zur Region dann auch dazugehört) viel
umständlicher Ausfallen.

Das ist halt das Problem, welches zuerst durch Nachdenken gelöst werden muss !!

Alles im Speicher behalten ist die schnellst Variante, aber wenn der Speicher nicht gross genug ist, geht es halt nicht.

Dann bleibt nichts anderes übrig, als alles auf der Festplatte in eine Datei zu packen und nur diejenigen Teile in den Speicher zu laden, welche gerade bearbeitet werden müssen. Dazu ist es dann aber oft notwendig, die Datenstrukturen so zu ändern, dass man die Daten mit möglichst wenig Laufwerkszugriffen erreichen kann.

Gerade Datenbanken sind schon oft daran gescheitert.
Mit 50 Records funktioniert alle wunderprächtig, wenn es dann dann 1’000 Records sind, kannst du dann essen gehen, bis die benötigten Informationen gefunden werden.

MfG Peter(TOO)

Hi!

Hallo,

etwas speichern ohne Nachdenken geht NIE. Nur mal so als
Anfangsschritt: deine erste Klasse enthält 2 Koordinaten und
einen Grauwert. Für das Speichern in einem Bildarray sind die
Koordinaten aber vollkommen überflüssig, weil die sich ja aus
den Indexen des Arrays ergeben - für ein VGA-Bild nimmt man
eben ein Array von 640 x 480 Grauwerten. Du würdest da schon
614400 Integer zusätzlich und völlig sinnlos abspeichern: in
deinem Array steht dann an Stelle [300,200] drin X=300, Y=200

  • das wusste ich vorher schon.

Gruss Reinhard

Nicht wirklich, Ich möchte ja nicht jedes Bild sammt
Koordinaten speichern - da würde ein Array wirklich reichen.
Es geht immer um Regionen, d.h. zusammenhänge Pixel aus dem
Bild.
Und da würde ich mehr Speicher verschwenden, wenn ich dort die
zur Region gehörenden Pixel in einem so großen Array speichern
würde.
Da ist ein Array von Punkten effektiver und schneller drauf
zuzugreifen. Zudem würde für Vergleiche, ob ein Pixel zu einer
Region gehört oder ob ein Pixel Nachbar zu einer Region ist
(und somit eventuell zur Region dann auch dazugehört) viel
umständlicher Ausfallen.

Wenn eine Region nur aus aus paar points bestehen soll, dann verstehe ich diese Zeile ueberhaupt nicht:

Point2D \*area[MAX\_IMG\_WIDTH][MAX\_IMG\_HEIGHT];

Ein paar Anregungen:

Wenn die (unsigned char regions[WIDTH][HEIGHT];
regions[4][4] = 5 wuerde bedeuten, dass Pixel (4,4) zu Region Nummer 5 gehoert.
Sollen es mehr Regionen als 256 werden, dann verwendest du statt ‚unsigned char‘ eben 2 byte.

Wenn die Regionen nicht disjunkt sind, wuerde ich Bitmasken vorschlagen. Folgende Variable koennte sizeof(unsigned)*8 Regionen speichern (also 32 Regionen auf üblichen Systemem):

unsigned bitmask[WIDTH][HEIGHT];

bitmask[4][4] = 0x01 wuerde bedeuten, dass Pixel (4,4) zu Region Nummer 1 gehoert (bit 1 gesetzt).
bitmask[4][4] = 0x02 wuerde bedeuten, dass Pixel (4,4) zu Region Nummer 2 gehoert (bit 2 gesetzt).
bitmask[4][4] = 0x03 wuerde bedeuten, dass Pixel (4,4) zu Region Nummer 1 und Nummer 2 gehoert (bit 1 und 2 gesetzt).

Bildinfo so zu speichern, wie du vorgeschlagen hast, ist unüblich.

  1. Es verschwendet Speicher (es sei denn, eine Region enthaelt nur eine Hand voll Punkte)
  2. Es ist langsam. In der Bildverarbeitung ein Pixel auf eine Klasse abzubilden ist absurd.

Hi!

Wenn eine Region nur aus aus paar points bestehen soll, dann
verstehe ich diese Zeile ueberhaupt nicht:

Point2D *area[MAX_IMG_WIDTH][MAX_IMG_HEIGHT];

Eigentlich sollte diese Zeile gerade einen effektiveren Zugriff auf die gespeicherten Punkte bewerkstelligen.
Es soll ein Nachbarschaftstest (4er-Nachbarschaft) für neue Punkte durchgeführt werden. Darum wäre es besser beispielsweise durch die X-Koordinate direkt das entsprechnde Array anzusprechen und dann nurnoch linear über die dort gespeicherten Punkte suchen muß - statt halt über alle.
Die Regionen sind alle unterschiedlich groß und können von ein paar wenigen Pixeln bis hin zu ein paar hundert bestehen.

Ein paar Anregungen:

Wenn die (unsigned char regions[WIDTH][HEIGHT];
regions[4][4] = 5 wuerde bedeuten, dass Pixel (4,4) zu Region
Nummer 5 gehoert.
Sollen es mehr Regionen als 256 werden, dann verwendest du
statt ‚unsigned char‘ eben 2 byte.

Die Idee an für sich ist gut.
Allerdings sind die Regionen für eine Stabilitätsanalyse erforderlich.
Das ganze läuft auf MSER hinaus (falls dies kein Begriff sein sollte: Ein Farbbild wird in ein Intensitätsbild gewandelt und per Grenzwert binarisiert - die dabei pro Grenzwert gefundenen Regionen werden analysiert und beobachtet, und wenn sie eine Menge von Grenzwerten gleich bleiben, so besitzen sie besondere Invarianzen).
Aus diesem Grund habe ich die Punkte auch einzeln gespeichert und in eine Area gesetzt. Disjunkt sind die Regionen pro binarisiertem Bild schon, aber man kann so nicht genug Informationenüber die Region unterbringen.

Grüße

Björn

Hi!

Wenn eine Region nur aus aus paar points bestehen soll, dann
verstehe ich diese Zeile ueberhaupt nicht:

Point2D *area[MAX_IMG_WIDTH][MAX_IMG_HEIGHT];

Eigentlich sollte diese Zeile gerade einen effektiveren
Zugriff auf die gespeicherten Punkte bewerkstelligen.
Es soll ein Nachbarschaftstest (4er-Nachbarschaft) für neue
Punkte durchgeführt werden. Darum wäre es besser
beispielsweise durch die X-Koordinate direkt das entsprechnde
Array anzusprechen und dann nurnoch linear über die dort
gespeicherten Punkte suchen muß - statt halt über alle.
Die Regionen sind alle unterschiedlich groß und können von ein
paar wenigen Pixeln bis hin zu ein paar hundert bestehen.

Ein paar Anregungen:

Wenn die (unsigned char regions[WIDTH][HEIGHT];
regions[4][4] = 5 wuerde bedeuten, dass Pixel (4,4) zu Region
Nummer 5 gehoert.
Sollen es mehr Regionen als 256 werden, dann verwendest du
statt ‚unsigned char‘ eben 2 byte.

Die Idee an für sich ist gut.
Allerdings sind die Regionen für eine Stabilitätsanalyse
erforderlich.
Das ganze läuft auf MSER hinaus (falls dies kein Begriff sein
sollte: Ein Farbbild wird in ein Intensitätsbild gewandelt und
per Grenzwert binarisiert - die dabei pro Grenzwert gefundenen
Regionen werden analysiert und beobachtet, und wenn sie eine
Menge von Grenzwerten gleich bleiben, so besitzen sie
besondere Invarianzen).
Aus diesem Grund habe ich die Punkte auch einzeln gespeichert
und in eine Area gesetzt. Disjunkt sind die Regionen pro
binarisiertem Bild schon, aber man kann so nicht genug
Informationenüber die Region unterbringen.

Dein Speicherverbrauch ungefaehr:
–> 100 mal 256 mal class Area
wobei Area hauptsaechlich das ist: Point3D* area[640][480];
Macht in der Summe:
–> 100 * 256 * sizeof(Point3D*) * 640 * 480 = 30000 MB !!!
(auf 64bit architektur ist es doppelt so viel)

Dazu kommen noch die Point2Ds, die hinzugefügt werden.

Ich schlage ungefähr folgendes vor:

class LabeledImage
{
 unsigned char labels[WIDTH][HEIGHT];
 [...]
};

class Area
{
 unsigned char label;
 LabeledImage\* reference;
 [...]
};

LabeledImage[256];
Area[256][100];

In LabeledImage wird in jedem Pixel abgepeichert, zu welcher Area es gehört. Darin kann man 256 verschiedene Regionen differenzieren.

Um in einer Area eine Vierernachbarschaft zu testen, schreibt man:

Area::addNewPoint(int x, int y)
{
 reference-\>labels[x][y] = this-\>label;

 // Test, ob Vierernachbarschaft vollständig zu Area gehört.
 if (reference-\>labels[x-1][y] == this-\>label &&
 reference-\>labels[x+1][y] == this-\>label &&
 reference-\>labels[x][y-1] == this-\>label &&
 reference-\>labels[x][y+1] == this-\>label)
 {
 [...]
 }
}

Zum Vergleich der Speicherverbrauch:
–> sizeof(LabeldImage[256]) + sizeof(Area[256][100])
–> 256 * sizeof(LabeledImage) + 256 * 100 * sizeof(Area)
–> 256 * 1 * 640 * 480 + 256 * 100 * 8 = 75,2 MB

Hi!
Das hilft mir sehr weiter. Besten Dank.
Aber hier entsteht direkt noch ein weiteres Problem:
Es wird sehr viel Rechenzeit und Speicherplatz zum speichern der binarisierten Bilder verschwendet.

Aus diesem Grund habe ich mir gedacht, ich sortiere die Pixel nach ihren Grauwerten vor und speichere die in einem array der Größe: [256][IMG_HEIGHT*IMG_WIDTH]

Jedoch habeich jetzt auch ausgerechnet, daß dort verdammt viel Speicher gebraucht wird. Und ich finde keine Möglichkeit, die Größe des Arrays während der Laufzeit zu ändern.
Eigentlich muß ja dafür Sorge getragen werden, daß wenn tatsächlich ein total schwarze Bild eingeladen wird, auch genug Platz im Array vorhanden ist.
Aber aus diesem Grund wird verdammt viel Speicher insgesammt verschwendet.
Ich habe schon an vector gedacht, aber wenn dort bei bereits bestehenden Daten im vector ein resize ausgeführt wird, kann nicht mehr auf die alten Daten referenziert werden.

Hast du vielleicht da noch einen Vorschlag?

Grüße

Björn

Hi!
Das hilft mir sehr weiter. Besten Dank.
Aber hier entsteht direkt noch ein weiteres Problem:
Es wird sehr viel Rechenzeit und Speicherplatz zum speichern
der binarisierten Bilder verschwendet.

Aus diesem Grund habe ich mir gedacht, ich sortiere die Pixel
nach ihren Grauwerten vor und speichere die in einem array der
Größe: [256][IMG_HEIGHT*IMG_WIDTH]

Jedoch habeich jetzt auch ausgerechnet, daß dort verdammt viel
Speicher gebraucht wird. Und ich finde keine Möglichkeit, die
Größe des Arrays während der Laufzeit zu ändern.
Eigentlich muß ja dafür Sorge getragen werden, daß wenn
tatsächlich ein total schwarze Bild eingeladen wird, auch
genug Platz im Array vorhanden ist.
Aber aus diesem Grund wird verdammt viel Speicher insgesammt
verschwendet.
Ich habe schon an vector gedacht, aber wenn dort bei bereits
bestehenden Daten im vector ein resize ausgeführt wird, kann
nicht mehr auf die alten Daten referenziert werden.

Hast du vielleicht da noch einen Vorschlag?

Ein paar Punkte:
1)
Wenn ich es richtig verstehe, dann legst du Variablen mit riesiger Grösse an, damit im worst-case der Speicher auch ausreicht?
Das ist nicht besonders schön, und im normal-case auch Speicherverschwendung.
Ein ernst gemeinter Vorschlag ist: übe dich ein wenig in manueller Speicherverwaltung, das ist für C++ und besonders für C unerlässlich, und in der Bildverarbeitung ist es ein Muss.
Bei C gibt es die Funktion realloc(), die verändert die Allokationsgrösse und kopiert automatisch den Speicher. Bei C++ mit der Funktion new() musst du den Speicher manuell kopieren.
std::vector resize sollte eigentlich auch alle Einträge kopieren (je nachdem, was enthalten ist: einfache Pointer oder komplizierte Copykonstruktoren).
Viele Speicher(re)allokationen sollten aber vermieden werden, weil sie relativ teuer (CPU) sind.
2)
Ich habe noch nie gesehen, dass in der Bildverarbeitung Pixel an sich verwaltet werden, also zB bestimmte Pixel in einem dynamischen Array. Das ist allermeistens viel zu ineffizient.
Normalerweise wird ein array fuer das ganze Bild angelegt, und dort die Information kodiert, die wichtig ist (LabeledImage zB kodiert zu welcher Area ein Pixel gehört).
3)
Funktionsaufrufe sind relativ teuer, deswegen ist es etwas ineffizient pro Pixel eine Funktion zu bemühen. Image->set(x, y, grayvalue); ist langsamer als Image->data[x][y] = grayvalue; (es sei denn, die Funktion wird ‚inline‘ übersetzt).
4)
Was du letztlich machst ist Segmentierung, vielleicht gibt wikipedia mit deren weblinks ein paar Anhaltspunkte, wie man da effizient vorgeht.

Markus.

Hm, eins würde mich noch interessieren:
Warum bearbeitest du nicht ein Bild nach dem anderen, sondern 256 auf einmal?

Hm, eins würde mich noch interessieren:
Warum bearbeitest du nicht ein Bild nach dem anderen, sondern
256 auf einmal?

Nun, das hat sich im Laufe der Programmierarbeit schon etwas abgewandelt.

Die Idee ist es, stabile Flächen im Bild zu finden.
Dafür wird ein Grenzwert über die Graustufen gelegt, d.h. ist der Grauwert des Pixels kleiner als der Grenzwert, so wird das Pixel schwarz dargestellt - sonst halt weiß. ALso binarisiert man das Bild und erhält so 256 Bilder - eines für jeden möglichen Grenzwert, wobei das erste total weiß und das letzte total schwarz ist.
Man fängt nun an Regionen (halt die Area) zu finden für jedes Bild und vergleicht die Regionen über mehrere Grenzwerte.
Sind diese Regionen über eine Menge von Grenzwerten stabil, so haben diese Regionen = Flächen ein paar besondere Eigenschaften bezüglich der Invarianzen und eigenen sich somit für die weitere Verarbeitung.
Die Region wird dann durch eine Ellipse approximiert, ein Deskriptor mit einer Orientierung (wie bei SIFT-Merkmalen) berechnet.

An für sich ein Effizientes verfahren, jedoch nicht so einfach umzusetzen.
Dies ist eben das Manko wenn einem ausschließlich Java beigebracht wird und man dann erwartet, effiezient C++ zu programmieren.

Grüße

Björn

Hi!

Wenn ich es richtig verstehe, dann legst du Variablen mit
riesiger Grösse an, damit im worst-case der Speicher auch
ausreicht?
Das ist nicht besonders schön, und im normal-case auch
Speicherverschwendung.

Genau das habe ich auch festgestellt.

Ein ernst gemeinter Vorschlag ist: übe dich ein wenig in
manueller Speicherverwaltung, das ist für C++ und besonders
für C unerlässlich, und in der Bildverarbeitung ist es ein
Muss.
Bei C gibt es die Funktion realloc(), die verändert die
Allokationsgrösse und kopiert automatisch den Speicher. Bei
C++ mit der Funktion new() musst du den Speicher manuell
kopieren.
std::vector resize sollte eigentlich auch alle Einträge
kopieren (je nachdem, was enthalten ist: einfache Pointer oder
komplizierte Copykonstruktoren).
Viele Speicher(re)allokationen sollten aber vermieden werden,
weil sie relativ teuer (CPU) sind.

Da werde ich einmal reinschauen. Es ist manchmal leider so, daß wenn einem keiner sagt worauf man zu achten hat, man wie die Kuh vor dem Auto steht und nicht weiter weiß. :smile:

Ich habe noch nie gesehen, dass in der Bildverarbeitung Pixel
an sich verwaltet werden, also zB bestimmte Pixel in einem
dynamischen Array. Das ist allermeistens viel zu ineffizient.
Normalerweise wird ein array fuer das ganze Bild angelegt, und
dort die Information kodiert, die wichtig ist (LabeledImage zB
kodiert zu welcher Area ein Pixel gehört).

Diesen Ansatz lasse ich mir gerade auch durch den Kopf gehen und habe mir auch ein paar Gedanken dazu gemacht.
Einzige was mich hierdran noch stört, ist wie effektiv dann ein Merge von Regionen durchgeführt werden kann.

Funktionsaufrufe sind relativ teuer, deswegen ist es etwas
ineffizient pro Pixel eine Funktion zu bemühen.
Image->set(x, y, grayvalue); ist langsamer als
Image->data[x][y] = grayvalue; (es sei denn, die Funktion
wird ‚inline‘ übersetzt).

Gut zu wissen. Jedes Quentchen Performance was ich herausholen kann ist gut. :smile:

Was du letztlich machst ist Segmentierung, vielleicht gibt
wikipedia mit deren weblinks ein paar Anhaltspunkte, wie man
da effizient vorgeht.

Ich habe einen neuen Ansatz bereits gewählt, bei dem die Pixel vorher nach ihren Grauwerten sortiert werden (siehe Erklärung im anderen Posting was genau gemacht werden soll).

Aber gerade dort habe ich auch die Probleme mit den zu groß definierten Arrays. Ergo erst einmal in die SPeicherverwaltung einarbeiten. :slight_smile:

Grüße

Björn