[gelöst] Kommandozeilenprogramm zur Reduzierung der Farbtiefe bei Windows-Bitmaps

[kirchfritz]

Das Beispiel funktioniert, produziert allerdings "Run Length Encoding" - Komprimierung
Ich bin mir noch nicht sicher, ob diese Komprimierung von SAP-Importing-Routinen akzeptiert wird.

Ansonsten habe ich nicht verstanden, wozu OPBitmaps gut sind, und wenn ich mir den OPBitmap Quellcode anschaue, verstehe ich erst recht Bahnhof.
Das Beispielprogramm ist natürlich sehr einfach verständlich gehalten, das ist nicht das Problem.
Aber, wenn ich zum Beispiel die Komprimierung abschalten möchte, sehe ich keine Möglichkeit, dies selbst zu bewerkstelligen.

Kurz gesagt: OPBitmaps scheinen die Aufgabe "Reduzierte Farbtiefe bei Windows-Bitmaps" zu lösen, ist aber irgendwie mit Kanonen nach Spatzen geschossen.
Als Freund einfacher Lösungen bin ich noch nicht endgültig überzeugt.

[theo]

Aber, wenn ich zum Beispiel die Komprimierung abschalten möchte, sehe ich keine Möglichkeit, dies selbst zu bewerkstelligen.

Steht doch in dem Code in Button1Click:

Code: Alles auswählen

  Enc.RLECompress:=true;   

Dann mach's halt false.
Wirklich so schwierig?

[kirchfritz]

Ups, das habe ich wohl übersehen. Danke für den Hinweis.

[Winni]

Hi!

RLE = Run Length Encoding ist doch Informatik für Anfänger. Das dürfte doch selbst SAP schaffen.

Betr. der BMP mit Palette und 256 Farben via BGRAbitmap hab ich ne Anfrage im Internationalen Forum laufen. Vielleicht gibt's von da ne Antwort.

Winni

[theo]

Betr. der BMP mit Palette und 256 Farben via BGRAbitmap hab ich ne Anfrage im Internationalen Forum laufen. Vielleicht gibt's von da ne Antwort.

Könntest du den Link hier posten?

Ich verstehe allerdings nicht, wozu das noch gut sein soll.
Kirchfritz wollte bei "Windows-Bitmapdateien die Farbtiefe von 24 Bit auf 8 Bit zu reduzieren" in einem Kommandozeilenprogramm.
Dafür habe ich ihm einen fertigen Pascal-Code geliefert, welcher ohne spezielle Abhängigkeiten auskommt.
Es sind 3 Units. Wer das "mit Kanonen nach Spatzen geschossen" findet, hat die Problematik nicht verstanden.

Wenn Kirchfritz noch andere Pläne hat, soll er sie mitteilen, aber dieses "Ticket" ist eigentlich geschlossen.

[Winni]

Hi!

Hier ist der Link im Internationalen Forum betr. BGRAbitmap. Der enthält auch gleich die Lösung

https://forum.lazarus.freepascal.org/in ... 252.0.html

Jetzt kam auch die Erinnerumng zurück:

Man muss die Bitmap erstmal über den Dither-Algoritmus quantisieren.
Umständlich, aber trotzdem kurzer Code.

Winni


PS.: Nun kann der Thread als zweimal beantwortet geschlossen werden.

[theo]

Man muss die Bitmap erstmal über den Dither-Algoritmus quantisieren.
Umständlich, aber trotzdem kurzer Code.

Ja, geht auch. Das wusste ich nicht.
Einfacher ist es aber mMn nicht.
Ausserdem dauert die Umwandlung mehr doppelt so lange wie die OpBitmap Variante und hat leicht Artefakte in meinem Testbild (gelbe Striche in den Wolken: Zweites Bild).
Ist aber wohl am Ende Geschmackssache.

[Winni]

und hat leicht Artefakte in meinem Testbild (gelbe Striche in den Wolken: Zweites Bild).
Ist aber wohl am Ende Geschmackssache.

Hi!

Und nun liebe Kinder kommen wir zu der Debatte von Anfang der 90er:

"Was ist der beste Algorithmus eine Palette für eine 256-Color-Bitmap zu erstellen"

Theo, lass uns unsere Zeit mit was Sinnvollem verbringen.
Außer Kirchfritz und SAP braucht das sowieso keiner mehr.
Das kommt aus einer Zeit in der Festplattenplatz und RAM rar und teuer waren.

Grüße
Winni

[circular]

Hallo,

Ja es gibt ein leicht Artefakt. Ich habe dieses Problem schon gesehen aber bin ich nicht sicher wie es zu vermeiden. Wie ich verstehe es, ist daß die Farbeunterschied summiert sich weil die Palette ist nicht regelmäßig.

Grüße

[kirchfritz]

Danke an alle.
Für mich ist die Fragestellung ausreichend beantwortet.
Für weiteren Diskussionsbedarf solltet ihr [Winni, circular und theo] einen eigenen Beitrag benutzen.
Danke nochmal für alles.
Ich bin dann mal raus.....

Fritz Kirch