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.