Bitmaps vergleichen

[Rollo62]

Sehr schön, dankesehr

Zwei Fragen:
Du schreibst dass Du Alles in 24-Bit wandelst, auch 32-Bit Bilder.
Warum nimmst Du nicht gleich 32-Bit, so wie Graphics32 ?
Hat der 24-Bit Raum irgendwelche Vorteile für Dich ?

Mit den RAL-Farben verstehe ich nicht ganz.
Das sind Printfarben, die kann man doch eigentlich nicht am Bildschirm darstellen.
Ist das die nächstbeste Farbe die der RAL entspricht, oder
gibt es einen "offiziellen" Algorithmus der irgendeine Farbe zu RAL umwandeln kann ?

[Amateurprofi]

Zitat von Rollo62:

Sehr schön, dankesehr

Zwei Fragen:
Du schreibst dass Du Alles in 24-Bit wandelst, auch 32-Bit Bilder.
Warum nimmst Du nicht gleich 32-Bit, so wie Graphics32 ?
Hat der 24-Bit Raum irgendwelche Vorteile für Dich ?

Mit den RAL-Farben verstehe ich nicht ganz.
Das sind Printfarben, die kann man doch eigentlich nicht am Bildschirm darstellen.
Ist das die nächstbeste Farbe die der RAL entspricht, oder
gibt es einen "offiziellen" Algorithmus der irgendeine Farbe zu RAL umwandeln kann ?

Zitat:

Du schreibst dass Du Alles in 24-Bit wandelst, auch 32-Bit Bilder

Ich schrieb "Bei Formaten <> *.Bmp werden die Bilder in 24Bit-Bitmaps umgewandelt.", also:
Nur wenn zum Beispiel ein .jpg geladen wird, wird die in eine 24Bit Bitmap umgewandelt.
Wenn eine .bmp Datei geladen wird, bleibt die im Original-Format.
Ausnahme:
Wenn bei einer .bmp Datei das Pixelformat=pfCustom und biBitCount=16 ist, wird das so gehandhabt:
A) Die Datei enthält Masken für Rot, Grün, Blau.
Dann wird aus den Masken entweder pf15bit oder pf16bit abgeleitet.
B) Die Datei enthält keine Farbmasken.
Dann werden die Farbmasken RMask:=$7C00; GMask:=$03E0; BMask:=$001F; benutzt und als PixelFormat pf15bit.
Da habe ich unsauber gearbeitet.
Korrekterweise sollte ich in diesem Fall alle 16Bit-Farbwerte der Bitmap prüfen.
Wenn zumindest bei einem Pixel das höchste Bit gesetzt ist sollte ich die Standardmasken für pf16Bit verwenden und als Pixelformat pf16bit.
Das werde ich in den nächsten Tagen ändern.
Danke für die Rückfrage - erst dadurch habe ich registriert, dass ich das Pixelformat aus den Farbdaten ableiten kann.

Zitat:

Warum nimmst Du nicht gleich 32-Bit, so wie Graphics32 ?
Hat der 24-Bit Raum irgendwelche Vorteile für Dich ?

Aus Gewohnheit und aus Speicherplatz-Gründen.
Die Umwandlung in 24Bit Bitmaps erfolgt ja nur bei Dateiformaten <> .bmp und z.B. JPEG kann nur pf8bit und pf24bit, zumindest die mir vorliegende Version.

Zitat:

Mit den RAL-Farben verstehe ich nicht ganz.
Das sind Printfarben, die kann man doch eigentlich nicht am Bildschirm darstellen.
Ist das die nächstbeste Farbe die der RAL entspricht, oder
gibt es einen "offiziellen" Algorithmus der irgendeine Farbe zu RAL umwandeln kann ?

Ich ordne einem RGB-Wert die RAL-Farbe zu, bei der die maximale Abweichung der Rot-, Grün-, Blauwerte am kleinsten ist.
Ein "offizieller" Algorithmus ist mir nicht bekannt.
Bei der Tabelle der RAL-Farben handelt es sich um die RAL-Classic-Farben.
Die hab ich vor ein paar Jahren auf http://www.ral-farben.de gefunden.

Delphi-Quellcode:

FUNCTION NearestRalColorIndex(CL:TColor):Integer;
var I,D,MinD:Integer;
begin
   MinD:=MaxInt;
   Result:=0;
   for I:=0 to High(RalColors) do
      with RalColors[I], TRgb(CL) do begin
         D:=Max(Max(Abs(Red-R),Abs(Green-G)),Abs(Blue-B));
         if D<MinD then begin
            MinD:=D;
            Result:=I;
         end;
      end;
end

;

[Sinspin]

Hallo. Sehr interessantes Projekt.
Dann sollte ich mit dem Programm auch in der Laage sein Bilder zu finden die zweimal mit unterschiedlicher Kompression gespeichert wurden sind oder an deren einer Version ein Stück abgeschnitten wurde.

Was ich aber nicht verstehe warum Du mit einer Farbtabelle arbeitest? Oder dient die nur der Umrechnung zwischen den Farbräumen?

Ich schreibe an einem Programm zum automatischen farblichen Angleichung von Bildern. Da hat sich RGB als eher ungeeignet herausgestellt.
Durch die Verwendung von HSV als Farbraum kann ich Farbe, Sättigung und Helligkeit einzeln betrachten und vergleichen. Verschiedene Formen und Objekte sind oft erstaunlich genau differenzierbar. Ich denke mal das läuft bei deinem Tool ähnlich.

Lohnt sich an irgend einer Stelle eine Farbtiefe höher als 24 Bit (8 Bit je Kanal)? 32 Bit verwendet man doch eigentlich nur wenn man Transparenz (via 8 Bit Alpha kanal) im Bild verwenden will oder den Zugriff auf Speed optimieren möchte.

[Amateurprofi]

Zitat von Sinspin:

Hallo. Sehr interessantes Projekt.
Dann sollte ich mit dem Programm auch in der Laage sein Bilder zu finden die zweimal mit unterschiedlicher Kompression gespeichert wurden sind oder an deren einer Version ein Stück abgeschnitten wurde.

Was ich aber nicht verstehe warum Du mit einer Farbtabelle arbeitest? Oder dient die nur der Umrechnung zwischen den Farbräumen?

Ich schreibe an einem Programm zum automatischen farblichen Angleichung von Bildern. Da hat sich RGB als eher ungeeignet herausgestellt.
Durch die Verwendung von HSV als Farbraum kann ich Farbe, Sättigung und Helligkeit einzeln betrachten und vergleichen. Verschiedene Formen und Objekte sind oft erstaunlich genau differenzierbar. Ich denke mal das läuft bei deinem Tool ähnlich.

Lohnt sich an irgend einer Stelle eine Farbtiefe höher als 24 Bit (8 Bit je Kanal)? 32 Bit verwendet man doch eigentlich nur wenn man Transparenz (via 8 Bit Alpha kanal) im Bild verwenden will oder den Zugriff auf Speed optimieren möchte.

Zitat:

Dann sollte ich mit dem Programm auch in der Laage sein Bilder zu finden die zweimal mit unterschiedlicher Kompression gespeichert wurden sind oder an deren einer Version ein Stück abgeschnitten wurde.

Ich denke Ja.

Zitat:

Was ich aber nicht verstehe warum Du mit einer Farbtabelle arbeitest? Oder dient die nur der Umrechnung zwischen den Farbräumen?

Die Farbtabelle enthält für jede der 256^3 RGB-Farben:
Für das HSB-Modell die Werte für Hue, Saturation, Brightness.
Für das HSL-Modell die Luminanz (Hue und Saturation sind wie bei HSB).
Für das XYZ-Model die X-, Y-, Z-Werte.
Welchem Farbbereich die Farbe zugeordnet ist.
Welche RAL-Farbe der RGB-Farbe zugeordnet ist.
Als Farbbereiche habe ich vorgesehen

Delphi-Quellcode:

   ColorRangeText:Array[TColorRange] of String=
      ('Rot','Orange','Gelb','Gelbgrün','Hellgrün','Grün','Dunkelgrün',
       'Seegrün','Cyan','Blau','Violett','Magenta','Pink','Rosa','Braun','Oliv',
       'Weiß','Grau','Schwarz');

Im Prinzip könnte man die Daten immer dann, wenn sie benötigt werden, errechnen.
Wenn es aber ums Sortieren zum Beispiel der Liste mit den Anzahlen der verschiedenen Farben geht, macht es sich schon bemerkbar, wenn ich die Daten bei jedem Vergleich berechne.
Lade einfach mal ein schönes großes Landschaftsbild mit 15MPixeln.
Dann klicke im HeaderControl der untersten Liste die Sektion "H" und dann mit gedrückter Ctrl-Taste "S" und "B".
Danach ist die Liste nach Hue, Sat, Bright sortiert.
Und dann klicke Menu > Info > "Sortieren der Farbanzahlen".
Unter anderem siehst du da, wie oft beim Sortiervorgang zwei Records verglichen wurden.
Wenn man nun bei jedem Vergleich die Werte neu errechnen würde ...
Die Prozedur, die die Liste sortiert PROCEDURE TMain.SortCountsList; findest du in der Unit DR_Main, irgendwo bei Zeile 4800 oder so.

Zitat:

Durch die Verwendung von HSV als Farbraum kann ich Farbe, Sättigung und Helligkeit einzeln betrachten und vergleichen. Verschiedene Formen und Objekte sind oft erstaunlich genau differenzierbar. Ich denke mal das läuft bei deinem Tool ähnlich.

Nein. Es werden nur RGB-Werte verglichen.

Zitat:

Lohnt sich an irgend einer Stelle eine Farbtiefe höher als 24 Bit (8 Bit je Kanal)? 32 Bit verwendet man doch eigentlich nur wenn man Transparenz (via 8 Bit Alpha kanal) im Bild verwenden will oder den Zugriff auf Speed optimieren möchte.

Wenn man dem https://de.wikipedia.org/wiki/Windows_Bitmap vertrauen möchte, ist das, was man landläufig als Alphakanal bezeichnet, nicht wirklich fest definiert.
M.E. bringt es (bei diesem Projekt) keine Zeitvorteile mit 32Bit-Bitmaps zu arbeiten.
Vor allem ist das Programm ja gerade darauf ausgerichtet, auch Bitmaps mit unterschiedlichen Formaten zu vergleichen.
Na klar könnte man bei Laden eines Bildes dieses in pf32bit umwandeln. Das würde die Vergleichsroutine vereinfachen und sicherlich auch etwas schneller machen. Allerdings gehen dabei auch Informationen verloren zum Beispiel bei pf1bit..pf8bit die Indizes in die Palette und bei pf15bit und pf16bit die Originalwerte aus der Bitmap.

[Sinspin]

Danke für die ausführliche Erklärung.