Das deutsche Python-Forum

Hallo,
Ich habe mich nach einer erfolglosen Suche danach entschlossen hier einfachmal die Frage zu stellen . Ich möchte mit PIL ein Bild von z.B. 8 Bit auf 4 Bit oder so etwas in der Art konvertieren. Sollte das nicht so einfach gehen, wäre meine Frage, wie es möglich ist C# Codes als import für python codes zu verwenden. Dort ist das nämlich ganz einfach.

Mfg
Christian

Die Frage ist sehr ungenau. Wenn es dir nur um eine simple Quantisierung geht, dann ist der >>–Operator dein Freund.

Naja, ich möchte einfach nur ein Bild welches 8 Bit hat, in ein Bild mit 16 Bit konvertieren... Wegen C#, da habe ich schon auf dem C# Forum nachgefragt.

Was HEISST denn das? Und wieso sind das plötzlich 16 statt 4? Was sind diese Bit? Ich kenne diverse Bits bei Bildern, aber du sagst nicht, was genau du meinst.

Und nein, C# kann man nicht so ohne weiteres einbinden. Andere Programme aufrufen geht natürlich.

Achso, tut mir leid, ich habe mir angewöhnt das "tiefe" bei Bit-tiefe wegzulassen... Tschuldige. Damit ist jedenfalls die Farbtiefe gemeint. Siehe hier: https://helpx.adobe.com/de/photoshop/us ... depth.html
Mfg
Christian

Laut https://pillow.readthedocs.io/en/5.1.x/ ... cepts.html gibts das nicht für Pillow.

Aber wohl hiermit: https://pypi.org/project/imageio/

Kann man aber auch googeln. Nichts anderes mache ich auch.

Wobei immer noch die Frage ist was die Konvertierung genau bewirken soll, denn man kann natürlich auch mit PIL auf 16 Farben quantisieren oder die RGB-Daten von 0 bis 255 auf 16er-Schritte einschränken. Also geht es da um diese Reduzierung des Informationsgehalts oder tatsächlich darum am Ende irgendwie Bitpacking zu betreiben bei der Repräsentation der Daten. Wobei das nicht jedes Dateiformat macht/kann.

Da ist vielleicht doch interessant *warum* diese Aktion passieren soll. Was ist das Ziel, der Hintergrund dieses Wunsches.

Ich habe eine Software, die kommt am besten mit 16-Bit tiff Bildern zurecht, da habe ich mir gedacht, dass ich das doch programmieren könnte

Was heisst denn "am besten"? Wenn man 8 Bit Bilder hat, kann man die natuerlich auf 16 Bit erweitern. Bessere Daten hat man deswegen aber natuerlich nicht. Ein schwarz-weisses Bild ist auch in 16 Millionen Farben schwarz-weiss.

Die Software funktioniert am besten mit 16 Bit.... Wenn ich jetzt ein Bild mit 1 Bit habe, dann kann das genau 2 Farben anzeigen: Schwarz und Weiß. Wenn ich aber ein Bild mit 8 Bit habe, kann das sogar schon Bilder mit 256 Milllionen verschiedenen Farben anzeigen.

Ein schwarz-weisses Bild ist auch in 16 Millionen Farben schwarz-weiss.

Ja aber es gibt graustufen...

Versteh ich nicht, wenn es S/W ist kann ich diese Information auch als Triple-Byte speichern, es sind doch nachwievor nur 2 Farben?

rennmaus hat geschrieben: Dienstag 9. Februar 2021, 20:04 Die Software funktioniert am besten mit 16 Bit.... Wenn ich jetzt ein Bild mit 1 Bit habe, dann kann das genau 2 Farben anzeigen: Schwarz und Weiß. Wenn ich aber ein Bild mit 8 Bit habe, kann das sogar schon Bilder mit 256 Milllionen verschiedenen Farben anzeigen.

Ein schwarz-weisses Bild ist auch in 16 Millionen Farben schwarz-weiss.

Ja aber es gibt graustufen...

Es geht nicht darum, wieviele Farben du darstellen *kannst*. Du redest davon, ein Bild mit 8 Bit Farbtiefe auf 16 Bit Farbtiefe zu erweitern. Das hat immer noch nur 256 verschiedene Farbwerte. Du erfindest ja keine hinzu. Darum das Beispiel mit schwarz-weiss. Bleibt auch bei 30 Bit schwarz-weiss.

Meine Kamera macht aber 32 Bit

Ich rede hier nur von Beispielen, was die Bit-tiefe angeht. Wenn es mit einer auf die andere geht, muss es ja auch mit nochmal einer anderen Farbtiefe gehen, oder? Meine Kamera macht sogar 48 Bit (kein Beispiel)

@rennmaus: Du hast jetzt immer noch nicht verraten was der Zweck von dem ganzen sein soll. Und Du gehst IMHO auch ziemlich locker mit dem Begriff Bittiefe um, denn ich glaube nicht das Deine Kamera 48 Bit pro Kanal macht, auf der anderen Seite sprichst Du aber von 16-Bit Tiff, was aber dort nur per Kanal geht, und AFAIK nicht per Pixel. Das wäre etwas was beispielsweise BMP können müsste, was aber heutzutage eher ”exotisch” ist, weil das aus Zeiten stammt in denen die Hardware zwar mehr als 256 Farben gleichzeitig können sollte, aber noch mit 16 Bit pro Pixel auskommen sollte, damit ein Bild nicht so viel Speicher belegt. Die Zeiten sind ja fast vorbei, denn Bitpacking von RGB-Werten in 16 Bit findet man heute noch im Bereich kleine Displays für Mikrocontroller & Co, aber soweit ich weiss nicht mehr beim PC.

Ok, ich habe mich geirrrt, meine Kamera macht 24 Bit. Ich hatte mir ein bearbeitetes Bild von früher angesehen, wahrscheinlich hatte ich es da geändert...

StarNet++ v1.1

This is a compiled C++ ported version of StarNet:

https://github.com/nekitmm/starnet


-> Only TIF files with 16bit ber channel are supported. <-

@rennmaus: Das steht da aber nirgends auf der Seite. Im Abschnitt zum Arbeitsablauf steht als Punkt 1 „Start from stretched LRGB image. Save as 8 bits/channel tif file.“ und an anderer Stelle „Throughout the code all input and output images I use are 8 bits per channel tif images.“

Also gehen auch ganz ”normale” 8 Bit pro Kanal. Keine Notwendigkeit die selber vorher künstlich auf 16 Bit pro Kanal aufzublasen.

Aber eine Kamera macht 24 Bit, da muss ich die dann ja ein bisschen runterrechnen... mein ausschnitt kommt aus dem README file wenn man sich das Ding über sourceforge runterlädt

24 Bit? Pro Kanal? Glaube ich nicht. Sind das nicht eher RGB8? 3 mal 8 ist 24....