Hallo Klaus, Herr Spangenberg, et. al.,
habt ihr bei euren Untersuchungen berücksichtigt, dass die Programme
intern möglicherweise mit Daten unterschiedlichen Typs (float, double
oder long double) arbeiten?
Weiterhin können die Compiler diesen Datentypen bei der Übersetzung
unterschiedliche Größen zuweisen. Wennalso auf verschiedenen
Betriebssystemen (16 Bit, 32 Bit, 64 Bit) unterschiedliche Compiler
und Compilereinstellungen verwendet werden, wäre das eine mögliche
Ursache.
Ihr geht außerdem (stillschweigend) davon aus, dass die Werte mit 8
Bit/Kanal berechnet wurden. Vielleicht wurden aber auch 16 Bit/Kanal
oder gar 32 Bit/Kanal verwendet und am Ende wird noch einmal auf 8 Bit
heruntergerechnet.
Es existiert übrigens ein ANSI/IEEE Standard 754 zur Umrechnung von
Dezimalzahlen in Gleitkommazahlen (inklusive Rundungsvorschirifen).
Vielleicht lohnt sich ein Blick in dieses Dokument zu werfen. Ein
Auszug, dessen Richtigkeit ich nicht zu beurteilen vermag, findet sich
in Wikipedia:
<http://de.wikipedia.org/wiki/IEEE_754>
Auf Lange Sicht wird man als Anwender mit diesem Problem leben müssen,
zumindest, wenn man unterschiedliche Betriebssysteme, Software oder
sogar verschiedene Versionen derselben Software verwendet. Zumal von
einer Vielzahl an existierenden Daten nicht mehr unbedingt gesagt
werden kann mit welchem Programm und auf welchem System sie erzeugt
wurden. Wenn es aber neue Erkenntnisse gibt, so haltet uns bitte auf
dem Laufenden.
Viele Grüße aus Wuppertal
Claudio Wilmanns
Am 17.07.2008 um 10:10 schrieb Klaus Karcher:
Frank Spangenberg schrieb:
Hallo Herr Karcher,
die Werte haben sich etwas verändert. Die digitale Speicherung der
Tonwerte
erfolgt ja umgekehrt proportional. D.h. 0% entspricht dem Index
255, 100%
dem Index 0.
Hmmm... Mag sei, dass Photoshop das intern so handhabt -- im CMYK-TIFF
ist aber 0% = 00h und 100% = FFh
Das ergibt ein anderes Rundungsverhalten: wird
der Index bei ,5
aufgerundet, ergibt sich ein niedrigerer Tonwert.
http://spreadsheets.google.com/ccc?key=pdbV5FYYycngGI-oeBuGcKw
Beispiel:
70% => Index 76,5 => Index 77 => 69,80%
Die ECI2002-Charts der ECI wurden wahrscheinlich mit Photoshop, die
mit
ProfileMaker gelieferten ECI2002-Charts mit ImageMagick erzeugt/
bearbeitet.
Es könnte also sein, dass es sich nicht um ein allgemeines
Rundungsproblem
handelt, sondern schlicht und einfach um einen Bug in Photoshop.
Schließlich
erzeugen dort die Füll-Funktionen unterschiedliche Index-Werte und
dementsprechend
unterschiedliche Tonwerte.
Mit freundlichem Gruß
Frank Spangenberg
ich kann mir 2 "sinnvolle" Rundungsverfahren vorstellen: to even (aus
statistischen Überlegungen vorzuziehen) oder kaufmännisch. Wenn wir
jetzt noch die normale und umgekehrte Tonwertreihenfolge in die
überlegung mit einbeziehen, ergeben sich 4 Varianten.
Wie Sie an der Tabelle unter sehen, entspricht das im ECI-Visual-TIFF
angewandte Verfahren und das Verhalten von CS3 Mac keiner der 4
Varianten, CS3 Win (ich habe die Werte dafür Ihrer Tabelle entnommen)
sieht nach kaufmännisch mit umgekehrten Tonwerten aus.
% 10 30 50 70 90
------------------------------------------------------
kaufm. 10.20 30.20 50.20 70.20 90.20
kaufm. rev. 9.80 29.80 49.80 69.80 89.80
to even 10.20 29.80 50.20 69.80 90.20
to even rev. 9.80 30.20 49.80 70.20 89.80
------------------------------------------------------
eci 10.20 30.20 49.80 70.20 89.80
CS3 mac 9.80 29.80 49.80 69.41 89.41
CS3 win 9.80 29.80 49.80 69.80 89.80
nochmal zu Erinnerung: wir reden hier von Delta Es bis ca. 1 -- noch
/bevor/ eine Profilierungssoftware oder CMM ihre Finger im Spiel hatte
;-) -- ich sehe da Handlungsbedarf.
Grüße,
Klaus Karcher
_______________________________________________
ECI mailing list
ECI(a)lists.callassoftware.com
http://lists.callassoftware.com/mailman/listinfo/eci