Hallo Herr Schober!
Danke für die Hinweise! Ich würde die LAB-Werte bb auch für den
25%, 40% und 80% Tonwert benötigen. Wenn Sie mir die von
PSO_SNP_Paper_eci.icc zukommen lassen könnten, wäre ich Ihnen dankbar!
Die anderen werde ich wohl nach Ihrem Vorschlag selber ermitteln.
Vielleicht könnte man in Zukunft diese Werte auch veröffentlichen.
Wundert mich eigentlich, daß die scheinbar sonst niemand benötigt!
Mit freundlichen Grüßen
Walter Hasslinger
Prepress
Niederösterreichisches Pressehaus
Druck- und Verlagsgesellschaft m.b.H.
Gutenbergstraße 12, 3100 St.Pölten
Tel: ++43 (2742) 802-1205 DW
ISDN: ++43 (2742) 7120
E-Mail: w.hasslinger(a)np-druck.at
Homepage:
www.np-druck.at
-----Ursprüngliche Nachricht-----
Von: eci-bounces(a)lists.callassoftware.com [mailto:eci-bounces@lists.callassoftware.com] Im
Auftrag von eci-request(a)lists.callassoftware.com
Gesendet: Samstag, 19. Juli 2008 12:00
An: eci(a)lists.callassoftware.com
Betreff: ECI Nachrichtensammlung, Band 30, Eintrag 13
Um e-Mails an die Liste ECI zu schicken, nutzen Sie bitte die Adresse
eci(a)lists.callassoftware.com
Um sich via Web von der Liste zu entfernen oder draufzusetzen:
http://lists.callassoftware.com/mailman/listinfo/eci
oder, via Email, schicken Sie eine Email mit dem Wort 'help' in Subject/Betreff
oder im Text an
eci-request(a)lists.callassoftware.com
Sie koennen den Listenverwalter dieser Liste unter der Adresse
eci-owner(a)lists.callassoftware.com
erreichen
Wenn Sie antworten, bitte editieren Sie die Subject/Betreff auf einen sinnvollen Inhalt
der spezifischer ist als "Re: Contents of ECI digest..."
Meldungen des Tages:
1. Re: Rundungsfehler in Testcharts (Frank Spangenberg)
2. Re: Charakterisierungsdaten neue Offsetprofile (Joerg Schober)
3. Re: Rundungsfehler in Testcharts (Frank Spangenberg)
4. Re: Rundungsfehler in Testcharts (Claudio Wilmanns)
5. Re: Rundungsfehler in Testcharts (Klaus Karcher)
6. Re: Rundungsfehler in Testcharts (Klaus Karcher)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Jul 2008 12:17:20 +0200
From: "Frank Spangenberg" <frank.spangenberg(a)gmail.com>
Subject: Re: [ECI] Rundungsfehler in Testcharts
To: <eci(a)lists.callassoftware.com>
Message-ID: <48806dbc.09cc660a.14d6.ffffde00(a)mx.google.com>
Content-Type: text/plain; charset="utf-8"
Klaus Karcher schrieb:
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.
Hallo Herr Karcher,
ich hatte das Problem schon an Adobe gesendet (leider noch keine Antwort), aber es wäre
sicherlich hilfreich, wenn Adobe die Infos von mehreren Personen erhält...
Mit freundlichem Gruß
Frank Spangenberg
--
Student ?Druck- und Medientechnologie?
Hochschule der Medien Stuttgart
http://www.frank-spangenberg.de
------------------------------
Message: 2
Date: Fri, 18 Jul 2008 13:46:01 +0200
From: Joerg Schober <j.schober(a)redblue.de>
Subject: Re: [ECI] Charakterisierungsdaten neue Offsetprofile
To: eci(a)lists.callassoftware.com
Message-ID: <48808279.8040901(a)redblue.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hallo Herr Hasslinger,
benötigen Sie nur die LAB-Werte für die Volltöne der Primärfarben oder
mehr? Falls nur Primärfarben:
Für die Papierklassen 1 bis 5 finden Sie im Medienstandard Druck Angaben
für bb, wb und Differenzwerte, für das neu veröffentlichte
PSO_SNP_Paper_eci.icc kann ich Ihnen weiterhelfen (im Rahmen der
Erstellung dieses Profils/der Char-daten habe ich eine umfangreiche
Sammlung mit wb/bb-Werten zusammenbekommen).
Dann würden Ihnen also noch die Werte für MFC und SC fehlen. Messen Sie
doch einfach Drucke aus Ihrem Haus, die auf den entsprechenden Papieren
gedruckt worden aus (wb u. bb), ermitteln Sie die Differenzen und
errechnen Sie damit die bb-Werte für Fogra40 (SC) und Fogra41 (MFC).
Gruß,
Jörg Schober
On 17.07.2008 10:43 Uhr, Hasslinger Walter wrote:
Hallo Liste!
Die Charakterisierungsdaten werden mit white backing angegeben.
Ich würde sie aber für inline Farbmessung mit black backing benötigen.
Sind diese Werte irgendwo zu bekommen oder besteht die Möglichkeit zur Umrechnung?
Mit freundlichen Grüßen
Walter Hasslinger
Prepress
Niederösterreichisches Pressehaus
Druck- und Verlagsgesellschaft m.b.H.
Gutenbergstraße 12, 3100 St.Pölten
Tel: ++43 (2742) 802-1205 DW
ISDN: ++43 (2742) 7120
E-Mail: w.hasslinger(a)np-druck.at
Homepage:
www.np-druck.at
--
Jörg Schober
______________________________
r e d b l u e Marketing GmbH
Qualitätsmanagement
Helene-Wessel-Bogen 3
D-80939 Muenchen
fon +49 89 316 92-625
fax +49 89 316 92-779
http://www.redblue.de
Geschäftsführung:
Manfred Bosch, Karsten Kühn, Ulrich Schmitz
Eingetragen beim Amtsgericht München unter HRB 113 873
______________________________
------------------------------
Message: 3
Date: Fri, 18 Jul 2008 14:24:56 +0200
From: "Frank Spangenberg" <frank.spangenberg(a)gmail.com>
Subject: Re: [ECI] Rundungsfehler in Testcharts
To: <eci(a)lists.callassoftware.com>
Message-ID: <48808ba2.1ade660a.18ee.fffff70f(a)mx.google.com>
Content-Type: text/plain; charset="utf-8"
Claudio Wilmanns schrieb:
habt ihr bei euren Untersuchungen berücksichtigt, dass
die Programme
intern möglicherweise mit Daten unterschiedlichen Typs (float, double
oder long double) arbeiten?
Hallo Herr Wilmanns,
im Moment tanzt ja nur Photoshop aus der Reihe. Da sollte man davon
ausgehen können, dass die ?unterschiedlichen? Füll-Funktionen intern
mit gleichen Datentypen/Genauigkeit arbeiten oder wenigstens die
gleiche Funktion zum Erstellen der Füllung verwenden. Auch sollte
Adobe sicherstellen können, dass unterschiedliche Compiler/-Einstellungen
nicht solche Unterschiede generieren... sonst hat einer beim
Requirements Management geschlafen!
Theoretisch besteht bei den verwendeten Operationen und Zahlenwerten
kein signifikanter Unterschied zwischen verschiedenen Datentypen
(Gleitkommazahl) bezüglich der Änderung der Rundungsrichtung.
http://www.h-schmidt.net/FloatApplet/IEEE754de.html
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.
Ähm, wozu gibt es Standards? :-)
Mit freundlichem Gruß
Frank Spangenberg
--
Student ?Druck- und Medientechnologie?
Hochschule der Medien Stuttgart
http://www.frank-spangenberg.de
------------------------------
Message: 4
Date: Fri, 18 Jul 2008 14:36:17 +0200
From: Claudio Wilmanns <wilmanns(a)uni-wuppertal.de>
Subject: Re: [ECI] Rundungsfehler in Testcharts
To: eci(a)lists.callassoftware.com
Message-ID: <1AA3C6A6-5C04-4BF9-87BB-E10C2B2BCB93(a)uni-wuppertal.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Am Jul 18, 2008 um 2:24 PM schrieb Frank Spangenberg:
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.
Ähm, wozu gibt es Standards? :-)
Sicher, sicher. Aber das Kind ist doch bereits in den Brunnen
gefallen, oder?
Angenommen in der aktuellen PS-Version ist wirklich etwas nicht in
Ordnung (sieht jedenfalls so aus, oder?), dann bedeutet das doch, dass
sich mit der nächsten Version wieder etwas ändert. Man kann nur
hoffen, dass diese Version und zukünftige versionen dann dem Standard
entsprechen. Alle alten Versionen, die in der Praxis sicher noch
einige Jahre eingesetzt werden, leiden aber unter dem Fehler und
sorgen auch weiterhin für Kummer.
Viele Grüße
CW
------------------------------
Message: 5
Date: Fri, 18 Jul 2008 15:37:30 +0200
From: Klaus Karcher <karcher(a)digitalproof.info>
Subject: Re: [ECI] Rundungsfehler in Testcharts
To: eci(a)lists.callassoftware.com
Message-ID: <48809C9A.5010706(a)digitalproof.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Claudio,
Claudio Wilmanns schrieb:
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?
Ich bin einfach von den DataSets (in denen ganzzahlige, dezimale
Prozentwerte definiert sind) und den zugehörigen TIFs (8Bit)
ausgegangen. Interne Repräsentationen interessieren mich dabei zunächst
nicht -- mir ist nur wichtig zu wissen, was am Ende herauskommt bzw.
herauskommen sollte. Und das ist offensichtlich nicht ganz eindeutig.
[...]
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.
Schon klar, dass bei Mehrfach-Rundung bzw. -Konvertierung selbst mit
Fließkommazahlen Abweichungen auftreten können. Gerade deshalb ist es
wichtig,
a) das Ziel eindeutig zu definieren
b) dafür zu sorgen, dass diese Definition praxisgerecht ist und im
Alltag zumindest keine /systematischen/ Fehler produziert.
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>
Danke für den Hinweis.
Interessant finde ich vor allem den Satz zu binären Rundungen:
"Bei binären Rundungen muss zur nächstgelegenen darstellbaren Zahl
gerundet werden. Wenn diese nicht eindeutig definiert ist (genau in der
Mitte zwischen zwei darstellbaren Zahlen) muss gemäß dem Vorschlag von
Carl Friedrich Gauß in Richtung zur nächstgelegenen geraden Zahl
gerundet werden."
Diese Situation kann in unserem Fall genau 4 mal auftreten. Wenn wir
davon ausgehen, dass sich alle beteiligten Fließkommazahlen in der
FP-Repräsentation exakt codieren lassen, ist das Ergebnis eindeutig:
% Stufe toEven Ergebnis
---------------------------------
10 25,5 26 10,20
30 76,5 76 29,80
50 127,5 128 50,20
70 178,5 178 69,80
90 229,5 230 90,20
Der Faktor 2,55 lässt sich aber nicht exakt als Float darstellen -- die
Konsequenzen sieht man z.B. schön in R:
round(c(10,30,50,70,90)*255/100)
[1] 26 76 128
178 230
round(c(10,30,50,70,90)*2.55)
[1] 26 76 127
178 229
90*2.55 - 90*255/100
[1] -2.842171e-14
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.
... solange es aber keine unmissverständliche Regelung gibt, wird sich
an der Situation auch in Zukunft nichts ändern :-(
Das ganze Problem ließe sich sehr einfach umgehen, indem bereits in den
Tabellen auf 8 bit gerundete Werte mit ein oder zwei Nachkommastellen
angegeben würden (also z.B. 69,80 statt 70%)
Klaus Karcher
------------------------------
Message: 6
Date: Sat, 19 Jul 2008 07:09:47 +0200
From: Klaus Karcher <karcher(a)digitalproof.info>
Subject: Re: [ECI] Rundungsfehler in Testcharts
To: eci(a)lists.callassoftware.com
Message-ID: <4881771B.7090409(a)digitalproof.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Claudio, ...
Claudio Wilmanns schrieb:
Wenn es aber neue Erkenntnisse gibt, so haltet uns
bitte auf
dem Laufenden.
... vielleicht könnte dieser Thread über australische Heinzelmännchen
ganz interessant sein ;-)
<http://www.freelists.org/archives/argyllcms/07-2008/msg00094.html>
Klaus
------------------------------
_______________________________________________
ECI mailing list
ECI(a)lists.callassoftware.com
http://lists.callassoftware.com/mailman/listinfo/eci
Ende ECI Nachrichtensammlung, Band 30, Eintrag 13
*************************************************