Exportierte jpg Darstellung in anderen Programmen Schachbrettmuster

[SeiMic]

Werbung (verschwindet nach Registrierung)

Guten Morgen,

egal was ich exportiere jpg, tiff... alles mit einem solchen Ergebnis:

Ideen was ich falsch mache?

Capture one Express (Sony) 20.0.3

Hallo Gast!
Einfach registrieren oder anmelden, um alles zu sehen.

[Anzeige]

Guck dir auch mal die SanDisk Extreme Pro SDXC 128 GB oder 64 GB an

[user87170]

vor 18 Minuten schrieb SeiMic:

Ideen was ich falsch mache?

Du kannst ja mal ein Bild unbearbeitet hier hochladen: https://www.file-upload.net/

Dann könnte man testen ob es an der Kamera, der Datei oder der Software liegt.

[micharl]

vor einer Stunde schrieb SeiMic:

egal was ich exportiere jpg, tiff... alles mit einem solchen Ergebnis:

Solche Muster kenne ich von Fehlfunktionen der Grafikkarte. Schau mal, ob die Treiber aktuell sind und mache ggf. ein update. Damit kann (nicht: muß) sich so etwas vielleicht wieder einrenken.

[user87170]

vor einer Stunde schrieb micharl:

Solche Muster kenne ich von Fehlfunktionen der Grafikkarte.

Und dann tritt der Fehler nur bei exportierten Bildern auf. 🤔

[prsmex]

Windows oder Mac?

Beim Mac treten solche ähnliche Effekte auch manchmal auf. Schalte mal versuchsweise die Hardwarebeschleunigung für den Export in den Einstellungen ab und schaue ob es dann weg ist. 

[SeiMic]

vor 36 Minuten schrieb prsmex:

Windows oder Mac?

Beim Mac treten solche ähnliche Effekte auch manchmal auf. Schalte mal versuchsweise die Hardwarebeschleunigung für den Export in den Einstellungen ab und schaue ob es dann weg ist. 

Windows...

Ausgeschaltet und jetzt funktionierts... Bild kommt perfekt als jpg... Vielen Dank prsmex!

Habe bei [Bearbeiten - Voreinstellungen - Hardwarebeschleinigung ] Beide Optionen auf Nie gesetzt. Jetzt funktioniert es.

Kann es dann sein dass an der Kiste HW mäßig was im Argen liegt?

 

[user87170]

Werbung (verschwindet nach Registrierung)

vor 1 Stunde schrieb prsmex:

Beim Mac treten solche ähnliche Effekte auch manchmal auf.

Meinst Du unter Capture One oder allgemein, allgemein habe ich so ein Bild seit 15 Jahren nicht am Mac gesehen.

[Anzeige]

Ich würde dir das Adobe Creative Cloud Foto-Abo mit Photoshop und Lightroom empfehlen

[beerwish]

vor 2 Stunden schrieb SeiMic:

Kann es dann sein dass an der Kiste HW mäßig was im Argen liegt?

Ich würde mal zu 95% annehmen dass Capture One die Grafikkarte nicht richtig ansteuert. Das Bild wird ja als unkomprimierte Pixelgrafik an die Grafikkarte übergeben, dort dann in ein komprimiertes Format umgerechnet und dann zurück übertragen. Da das Problem bei JPEG und TIFF auftritt, vermute ich, auf dem Hinweg überträgt die Software die Daten nicht korrekt zur Grafikkarte. Das Bild kommt da kaputt an und alles weiter ist dann irrelevant. Es gibt unendlich viele verschiedene Grafikkarten. Da wird man bei der Softwareentwicklung sicherlich nur mit einigen Karten exemplarisch testen und hoffen dass sich alle anderen ähnlich verhalten. Es könnte sich lohnen den Fehler zu melden.

[RoDo]

vor 55 Minuten schrieb beerwish:

Das Bild wird ja als unkomprimierte Pixelgrafik an die Grafikkarte übergeben, dort dann in ein komprimiertes Format umgerechnet und dann zurück übertragen.

Die Grafikkarte erzeugt eigenmächtig JPEG oder TIFF? Glaube ich nicht.

[beerwish]

vor 1 Stunde schrieb RoDo:

Die Grafikkarte erzeugt eigenmächtig JPEG oder TIFF? Glaube ich nicht.

Was Capture One genau macht habe ich aber nicht gefunden. Es gibt aber Möglichkeiten um JPEG-compression über CUDA bzw. OpenCL per GPU zu machen.

Der ganze Vorgang besteht ja darin, dass zunächst aus dem Raw eine 12 oder 16bit RGB-Bitmap gemacht wird. Dabei findet die Umrechnung des Bayer-Pattern in RGB-Werte pro Pixel statt. Das erscheint mir eher unwahrscheinlich, dass das auf der Karte passiert. Dann wird die Bitmap entsprechend der gewünschten Anpassungen bei Weißabgleich, Helligkeit und allem möglichen anderen Einstellungen bearbeitet und am Ende auf Bildschirmgröße bzw. Zielformat umgerechnet. Sobald man eine RGB-Bitmap hat, kann man die Bilder von sämtlichen Kameras gleich behandeln und da lohnt es sich dann die Algorithmen auf die Grafikkarte zu übertragen. Die Bitmap muss sowieso auf die Karte geladen werden, weil sie ja auf dem Bildschirm angezeigt wird. Ohne GPU-Unterstützung wird das Bild vorher auf die Bildschirmgröße umgerechnet. Mit GPU kann es komplett auf der Karte liegen und die GPU kann dann die Rechnungen für die RAW-Konvertierung (Farben, Helligkeit, Gamma u.s.w.) machen. Das geht aber vermutlich nicht komplett weil einige Filter sehr komplex sind. Das fertige Bild liegt dann aber auf der Karte und dann ist die JPEG-Kompression eine der typischen Aufgaben, die eine Grafikkarte sehr gut erledigen kann.

Edited March 12, 2020 by beerwish

[prsmex]

vor 11 Stunden schrieb Maxi:

Meinst Du unter Capture One oder allgemein, allgemein habe ich so ein Bild seit 15 Jahren nicht am Mac gesehen.

Unter Capture One. Da gibts, anscheinend seit V20, einen Knoten wo von komischen Bildern bis Absturz alles möglich ist. Ich wusste nicht, dass das Problem auch unter Windows besteht und dachte das wäre nur beim Mac. Manchmal scheint auch zu helfen wenn diese Parameterdatei die C1 erzeugt gelöscht und wieder neu aufgebaut wird. Müsste ich aber selbst wieder nachgucken wie das geht. Bei mir aufm Mac ist das auch auf NIE. Bei einzelnen BIldern nicht so tragisch aber bei vielen dauerts da die GPU Unterstützung nicht mehr da ist.

Edited March 13, 2020 by prsmex

[RoDo]

vor 14 Stunden schrieb beerwish:

Der ganze Vorgang besteht ja darin, dass zunächst aus dem Raw eine 12 oder 16bit RGB-Bitmap gemacht wird

Na ja, das ist sehr verkürzt dargestellt. Oder old-school.

Moderne Programme wandeln die einzelnen Helligkeitswerte der RAW-Daten, die je nach verwendetem ADC in 10, 12, oder 14 bit aufgelöst sind sofort in floating-point (FP) Zahlen um, ob 32 oder 64 bit, sei mal dahingestellt. Auf Basis dieser FP-Werte werden die durch das Bayer-CFA gelassenen "Löcher" in den Farbkanälen durch Ausgleichsrechnungen gefüllt. Dafür gibt es eine Vielzahl verschiedener Algorithmen, die zu leicht unterschiedlichen Ergebnissen führen. In RT kann man einige ausprobieren. Ergebnis dieses Demosaicing sind drei Riesenfelder (3 x die Pixelanzahl des Sensors), für jeden Farbkanal eines. Das reicht für RAW-auflösende Bildverarbeitungsprogramme. Für Bildbearbeitungsprogramme kommt noch ein Feld für den Alphakanal (A, Transparenz) dazu. Im Speicher liegen dann diese Bilddaten, die bei jeder Veränderung, einfach wie Kontrast oder Helligkeit (nur ein Pixel betreffend), oder komplex wie Schärfen, Entzerren, Drehen, Skalieren (wofür immer benachbarte Pixel mit berücksichtigt werden müssen) verändert werden.

Grund für die Nutzung der FP ist die wesentlich höhere Rechengenauigkeit als bei 16 bit Ganzzahlen, bei denen zwar Strichrechnungen genau, Punktrechnungen aber immer ungenau erfolgen, es sei denn, man hat einen Faktor aus der 2^^n Reihe im Spiel.

Aus diesen FP-Zahlen wird dann die Pixmap errechnet, mit ARGB-Anteilen pro Pixel. Die Pixmap wird an die Grafikkarte gegeben, die das an den Monitor ausgibt. Nur Operationen wie Zoomen und Verschieben des Bild sollten dann von der Grafikkarte direkt ausgeführt werden, im Auftrag des Bildverarbeitungsprogramms, denn das nimmt die Mausaktionen entgegen.

Erst wenn eine Speicherung eingeleitet wird, läuft die Umrechnung des FP-Felds in das Ausgabeformat (JPEG, TIFF, PNG, ...) an. Das läuft auf den modernen Prozessoren so schnell, dass ein Einsatz der GPU dafür keinen großen Zeitgewinn darstellt.

Schaut man sich mal an, wie die Kommunikation Programm => GPU erfolgt, dann sieht man, dass die GPU-Produzenten (nVidia, AMD, Intel) im Kern eigene Befehle und Schnittstellen zur Verfügung stellen, um die Leistung der GPUs optimal ausnutzen zu können. Nur führt die Nutzung dieser z. T. ausgefuchsten Funktionen schnell zu einer 1:1 Abhängigkeit des Programms zur Grafikkarte bzw. GPU. Das war vor 10 - 15 Jahren im CAD-Bereich so, wo Programmhersteller genau eine (oder zumindest eine aus einer ganz bestimmten Modellreihe) Grafikkarte vorschrieben, was bei Benutzern häufig zu Problemen führte, weil es dann zu Kollisionen mit anderen Programmen auf demselben PC kam.

Das hat man dann versucht, abzustellen durch Interfaces wie OpenGL und DirectX , weil dann mit (weitgehend) einheitlichen Aufrufen im Programm gearbeitet werden konnte. Der Treiber entschied dann, was direkt an die Grafikkarte weitergegen werden kann oder softwareseitig emuliert werden muss. Für die Arbeitsteilung CPU ==> GPU wird heute OpenCL benutzt. Da man aber eine 100%ige Übereinstimmung des Verhaltens nie erreicht (Programme sind Menschenwerk und Menschen machen Fehler, dazu gehört auch ein unterschiedliches Verständniss von niedergeschriebenen Funktionsvorgaben) wird beim Programmieren oft nur eine Untermenge der verfügbaren Funktionen benutzt und andere Funktionen werden durch eigene Programmierung abgewickelt. Das ist Usus seit es grafische Anwengungen auf Computern gibt, also seit dem Beginn der 1980er Jahre (vorher war das alles ganz anders). Sprich: Die immense Leistungsfähigkeit teurer Grafikkarten wird von den EBV-Programmen kaum benutzt, weil die Programmentwicklung immens aufwändig wäre. Und letztlich wegen des marginalen Zeitgewinns ohne signifikanten Vorteil.

Das oben gezeigte Bild ist ein schönes Beispiel für eine fehlerhafte Entropiekompression des JPG-Files. Die Entropie in der Informatik ist ein Maß für den Kehrwert des Informationsgehalts. Liegen Bereiche mit wenigen Details vor, dann werden größere Bereiche zusammengefasst (s. die großen Kacheln in ruhigen Bildzonen), während in Bereichen hoher Information (s. den Tellerrand in der Mitte) die Bereiche kleiner werden. Der Grund für solche Probleme ist im vorhergehenden Absatz erläutert.

 

[max65]

vor 11 Minuten schrieb RoDo:

Liegen Bereiche mit wenigen Details vor, dann werden größere Bereiche zusammengefasst (s. die großen Kacheln in ruhigen Bildzonen), während in Bereichen hoher Information (s. den Tellerrand in der Mitte) die Bereiche kleiner werden. Der Grund für solche Probleme ist im vorhergehenden Absatz erläutert.

Wenn ich vom PS-Raw kommend, an PS übergebe und dann ein sehr kleines jpg  zum Speichern erhalte -

heisst das, dass mein Photo weniger Infos hatte, sprich mein Foto "schlecht" gemacht war?

[RoDo]

vor 17 Minuten schrieb max65:

... mein Photo weniger Infos hatte, sprich mein Foto "schlecht" gemacht war?

Nö, es hängt eben vom Informationsgehalt ab. Extremes Beispiel: Ein weißes Blatt formatfüllend fotografiert sollte zu einem kleineren JPG führen als z. B. ein Teleschuss in ein reifes Weizenfeld, weil im letzteren wesentlich mehr Information steckt. Das Ganze geschieht nur, wenn das JPEG-erzeugende Programm die Entropiekompression überhaupt anwendet, den die ist optional und kostet Rechenzeit.

Edited March 13, 2020 by RoDo

[beerwish]

vor 33 Minuten schrieb RoDo:

Na ja, das ist sehr verkürzt dargestellt. Oder old-school.

In so ein Forum ist man bei komplexen Themen schnell zu lang und gleichzeitig zu verkürzt. Außerdem kenne ich das Umfeld eher aus dem Bereich Messdatenverarbeitung und Video. Die Spezialitäten bei Fotos und JPEG habe ich gegoogelt.

Ich kenne das ganze mehr von der Video-Seite her und da ist das Rendern bei mir etwa drei mal so schnell, wenn ich eine relativ flotte Grafikkarten (GTX 1070 ti) einsetze. Ich habe einen Vergleichstest gefunden, da hat jemand eine große Zahl von RAW-Bildern zu JPEG verarbeitet und auf dem Mac ging das etwa vier mal so schnell. Eine große Frage ist bei diesen Berechnungen immer wie unterschiedlich die Ergebnisse sind, wenn man statt Float mit Integer rechnet, ob das unangenehm auffällt und ob eventuelle Nachteil akzeptabel sind.

Klar ist in diesem konkreten Fall, dass Capture One die Option anbietet, dass OpenCL zum Einsatz kommt. Es gibt eine Option, bei der das Bild in voller Auflösung auf der Karte liegt und dort für den Bildschirm skaliert wird und es gibt eine Option, bei der die Grafikkarte das Rendern ins Zielformat beschleunigt wobei da unklar ist was die Karte macht und was der Prozessor.

Meine Erfahrung mit Integer-Arithmetik ist, dass man da ziemlich genau und deutlich schneller rechnen kann, wenn man die Bereiche und Skalierungen beachtet. Man kann natürlich auch ganz schnell Auflösung vernichten, wenn man da nicht aufpasst. Bildverarbeitung ist aber ein Bereich, der ziemlich gut dafür geeignet ist. Bis vor nicht allzu langer Zeit war es was besonderes, wenn Bildverarbeitungsprogramm mit mehr als 8bit gearbeitet haben.