TCanvas::Pixels-Resultate variieren bei Standalone/Runtimepackages-Kompilat (war: Standalone EXE Tipp aus FAQ Problem)

Hi !

Ich habe wie in der FAQ beschrieben den BCB eingestellt um eine Standalone EXE zu erzeugen, also eine die auch auf anderen Systemen läuft die nicht BCB inst. haben. Soweit ist das auch kein Problem ABER: Mein Programm macht folgendes es läd ein bmp Bild berechnet einen Filter darauf und zeigt das ganze wieder an. Wenn ich das Programm nun so kompiliere das es nur auf BCB Systemen läuft funktioniert alles 1A aber wenn ich es so comp. das es auf anderen Systemen läuft wird das Ergebnis ganz komisch Grün/Gelb ????? Irgendwelche Ideen ? Danke !

Edit:
Bitte aussagekräftige Überschriften wählen. Danke!

Wenn du einen Filter von Borland verwendest, must du sicher irgend eine Komponente mit dazu geben. FiktiverFilter.bpl oder so.
Wenn du selber einen Filter schreibst, also jedes einzelne Pixel ausließt, deine Berechnungen machst und den Pixel dann wieder ausgiebst, muss es eigentlich funktionieren.
Du benutzt ein einzelnes Image? Kein ImageList.
Bitmaps sind gratis. Um in BCB Gif's zu laden, braucht man teure Lizenzen. Und um JPG's anzuzeigen UND zu bearbeiten, muss man viele viele Codezeilen schreiben.

Also ich benutze kein Filter von Borland sondern lese das Bitmap (nur Bitmap) immer in Pixel Blöcken Pixel für Pixel aus berechne den Block neu und scheibe wieder Pixel für Pixel. Dazu benutze ich diese "Canvas->Pixels[x][y]" Funktion.
Was müsste ich denn da mit einbinden damit es geht ?

Windoof

Nichts.

EDIT:

The OS schrieb:

Um in BCB Gif's zu laden, braucht man teure Lizenzen

Plemm Plemm?

...also nichts habe ich schon versucht aber das geht eben nicht...

Grossmeister

@windoof:

Wer ist hier 'Plemm Plemm'? AFAIK liegt ein Patent auf dem GIF-Algorithmus. Um GIFs zu verwenden benötigt man also auch die entsprechende Lizenz.

Ähhh.. weiss villeicht jemand doch was zum Thema ??

Jansen

Die GIF-Patente laufen in Kürze (Mai oder Juni) aus, sind also kein grosses Problem mehr. Allerdings gibt es ja auch einen Patentstreit um JPEG, so dass in Zukunft möglicherweise auch dort Lizenzgebühren anfallen.
Zum Anzeigen und Bearbeiten von JPEGs sind aber keineswegs keineswegs besonders viele Zeilen Code erforderlich (jpeg.hpp).

ZeroooO:
Ohne mehr Informationen über das Entwicklungssystem und über den/die Testrechner und ggf. Details der Implementierung bzw. Anwendung deines Filters wird dir kaum jemand helfen können.

ohne weitere Info kann man Dir nicht helfen...

Spontan fallen mir als potentielle Fehlerquellen ein:
Andere Farbtiefe auf dem zweiten Rechner.
Falsches Pixelformat in TBitmap angegeben.
Rechenfehler in Routine.
Probleme mit Grafikkartentreiber.

Übrigens ist die Verwendung von Scanline um ein vielfaches schneller als Canvas[x,y].

Schau mal in die Onlinehilfe (aber Vorsicht, im Beispiel dort wird mit Byte* für den Zugriff auf Scanline gearbeitet. Das funktioniert aber nur bei Pixelformat pf8Bit. Für 16 bit mußt Du Word* nehmen, für 24 bit RGB*).

Es ist mit Sicherheit kein Einstellungsproblem für Stand-Alone-Exes! Das Problem ist in der Verwendung von TBitamp, respektive dem Canvas zu suchen.

Ich hab das Projekt mal unter www.vdecine.net/filter.zip hochgeladen villeicht kann man da jemand sagen wo der Fehler liegt.. ich bekomme es nicht hin... Danke !

Jansen

Du hast vergessen, Unit1.h mitzuliefern.

Auch ohne die Unit.h kann ich erkennen, dass an keiner stelle des Codes auf die Farbtiefe des Bitmaps, oder die des Screens eingegangen wird... Wie in meinem vorherigen Posting schon vermutet.

Jansen

Die Problembeschreibung legt allerdings nahe, dass das Phänomen auch auf dem Entwicklungsrechner, also mit identischem Test-Bitmap und bei identischer Farbtiefe auftritt.

@Jansen:
hm, wenn dem tatsächlich so ist, dass es auf ein und demselben Rechner, abhängig von der Kompilierungsart, unterschiedliche Ergebnisse gbt, bleiben nicht viele Möglichkeiten. Es müßte schon irgenwie einen Unterschied in den Bibliotheken geben.

Zero.. kann man die Header Datei nachliefern, dann können wir es ausprobieren.

@Zero..:
In der Zwischenzeit kannst Du versuchsweise immer nur Einstellung ändern, um festzustellen, ob sich das an einer einzelnen Einstellung fest machen läßt.

Sorry wegen der fehlenden Datei.. sollte jetzt dabei sein (gleicher Link). Also das Problem tritt bei ein und demselbem rechner auf je nachdem wie ich kompiliere.

hm, ich hab' mir das mal angesehen. Der Effekt ist reproduzierbar und abhänging von mit oder ohne Laufzeitpackages compilieren. Dennoch fürchte ich fast es ist ein Fehler in der Routine. Da wird so viel hin- und herkonvertiert, dass ich dabei einen Fehler vermute. Ich denke es ist mehr oder weniger Zufall, dass es mit Laufzeitpackages funtktioniert.

Wenn man sich mal ansieht was in den Canvas reingeschrieben wird:
mit ohne Laufzeitpackeges
0x00736E6F 0x00067463 Wert an identischer Canvasposition!
0x003A3939 0x00033A3F

interessant ist:
0x00000100 0x00000100 Werte identisch!!
0x00000600 0x00000600
Offensichtlich werden alle Werte unter 0x600 mit und ohne LZP identisch berechnet.

Geo

1. hast du schon mal vas von Code-Einrückung gehört?

2. Das kann ja nicht gutgehen:

int Matrix[10];

...

    for (int k=0;k<pBitmap->Height;k++) {
...
      for (int n=0;n<pBitmap->Width;n++) {
...
        for (int y=NowY;y<k+3;y++) {
          for (int x=NowX;x<n+3;x++) {

            Matrix[j]=Canvas->Pixels[x][y];                                                 // Get 3x3 Pixels

            j=j+1;
          }
        }
      }
    }

wie groß ist Matrix und wie groß wird j?

zu 1. ja sorry ist recht hingesaut.

zu 2. Matrix sollte 9 (3*3) Werte beinhalten, dementsprechend sollte (da es funktuioniert geh ich schon davon aus das dem so ist) j auch max 9 werden.
Es geht darum bei jedem Schleifen Durchlauf einen die RGB Werte von 9 Pixeln in einem 3x3 Block auszulesen dafür wird mit den schleifen k + n das bild von links nach rechts und oben nach unten in 3 Pixel breiten Zeilen ausgelesen und die Werte von einem Block (3x3) werden in Matrix abgelegt und nachdem sie bearbeitet und ausgegeben wurden wird ihr Inhalt mit dem nächsten Block überschrieben.

Geo

Das du das so gemeint hast ist schon klar, aber das hast du nicht so programmiert. Was passiert denn mit dem Index j? Du setzt ihn nicht zurück, er wird immer nur inkrementiert.

Ok mag sein aber wie kommen dadurch die unterschiedlichen Ergebnisse zustande ?