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

Grossmeister

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 ?

Joe_M. schrieb:

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

Hast Du denn mittlerweile mal versucht nachzuvollziehen, wie diese Unteschiedlichen Werte zustande kommen? Ein möglicher Weg wäre sich mal alle wichtigen Werte in eine StringList zu schreiben (jeweils mit und ohne Laufzeitpackes), auf Festplatte zu speichern und zu vergleichen. Dann hättest Du zumindest einen Anhaltspunkt, wo im Source zu suchen ist. Ach ja, ein bißchen Ordnung (Einrücken) könnte der Source wirklich vertragen, dass ist so absolut unleserlich.

Außerdem müchte ich noch mal auf Graphics::TBitmap->Scanline hinweisen. Auch hiermit kannst Du die einzelnen Pixel auslesen und schreiben. Das ist ca. 10 mal schneller als über Canvas[x][y].

Hmm wie kann ich denn mir Scanline die einzelnen Pixel auslesen ? Ich dachte damit könnte man immer nur ganze Zeilen auslesen ?

Als Anregung:
Untere Funktion verwendet Scanline um eine um 0, 90, 180 oder 270 Grad zu gedrehte Bitmap aus einem Bytearray zu erstellen. Ist aber nur nur für 8 Bit Farbtiefe geeignet (Byte*, Such mal nach RGBTRIPLE in der Hilfe). Da die Dateien, die ich einlesen muß, alle DIN A4, 600 dpi-JPEGs sind, sind sie recht groß (im Arbeitsspeicher). Deswegen waren Canvas-Zugriffe viel zu langsam und ich mußte Scanline verwenden. Die Bitmap wird dazu beim Laden erst in BitmapShow gelesen und dann in ein Bytearray im Arbeitsspeicher gelegt (ausgelesen über Scanline).

globale Variablen:
ymaxorg und xmaxorg sind int und geben die Größe des Originalbitmaps an
Imagedata ist ein Array aus Byte, in der Größe des Bitmaps. Dieses Array wird, beim Öffnen der Datei, mit den Original-Bitmappixeldaten gefüllt.
BitmapShow (Graphics::TBitmap) nimmt das auszugebende Bild auf
bmp_rotate gibt nur an, um wieviel Grad das Bild gedreht wird.

void __fastcall TFormJPEGViewer::RotateBitmap(void)
{

	int ymaxrot;
	int xmaxrot;

	if (bmp_rotate == 2 || bmp_rotate == 0)
	{
		ymaxrot = ymaxorg;
		xmaxrot = xmaxorg;
	}
	else
	{
		ymaxrot = xmaxorg;
		xmaxrot = ymaxorg;
	}

	BitmapShow->Width = xmaxrot;
	BitmapShow->Height = ymaxrot;

	Byte* slRotated;
	pImagedata = Imagedata;

	if (bmp_rotate == 0) // 0° gedreht
	{
		for (int y = ymaxrot - 1; y >= 0; y--)
		{
			slRotated = (Byte*) BitmapShow->ScanLine[y];
			for (int x = xmaxrot - 1; x >= 0; x--)
			{
				*slRotated = *pImagedata;
				slRotated++;
				pImagedata++;
			}
		}
	}

	if (bmp_rotate == 2) // 180° gedreht
	{

		for (int y = 0; y < ymaxrot; y++)
		{
			slRotated = (Byte*) BitmapShow->ScanLine[y];
			slRotated += xmaxrot - 1;
			for (int x = 0; x < xmaxrot; x++)
			{
				*slRotated = *pImagedata;
				slRotated--;
				pImagedata++;
			}
		}
	}

if (bmp_rotate == 3) // 270° gedreht
 {
  for (int y = ymaxrot - 1; y >= 0; y--)
  {
   slRotated = (Byte*) BitmapShow->ScanLine[y];
   slRotated += xmaxrot - 1;
   for (int x = 0; x < xmaxrot; x++)
   {
    *slRotated = Imagedata[ymaxrot - 1 - y + (x * xmaxorg)];
    slRotated--;
   }
  }
 }

 if (bmp_rotate == 1) // 90° gedreht
 {
  for (int y = 0; y < ymaxrot; y++)
  {
   slRotated = (Byte*) BitmapShow->ScanLine[y];
   for (int x = 0; x < xmaxrot; x++)
   {
    *slRotated = Imagedata[y + (x * xmaxorg)];
    slRotated++;
   }
  }
 }
	bmp_rotate_old = bmp_rotate;
}

Schau Dir mal den Abschnitt um 0° drehen an. Dort wird aus dem im Arbeitsspeicher hinterlegten Daten das Bitmap unverändert wieder hergestellt.

*slRotated = *pImagedata

Hiermit wird ein Byte aus dem Array in die Scanline geschrieben. Kannst also den Werte aus *pImagedata einlesen (ersetzt das Lesen von Canvas->Pixel[x][y]) umrechnen und ín *slRotated reischreiben (ersetzt das Schreiben von Canvas->Pixel[x][y]).

Ich kann Dir das Testprojekt, aus dem diese Funktion stammt am Montag mal zum Download bereitstellen, oder zumailen.