Moin, Plopp,TheBubble hat geschrieben:Ich habe zwar weder das genannte Display noch das genannte Kalibiergerät, versuche aber trotzdem zu antworten:
Zu 1: Ich nehme an, dass vor dem Vermessen bereits der gewünschte Farbraum ausgewählt wird, um die korrekturdaten berechnen zu können. Dieser wird es dann hoffentlich sein, der mit den Korrekturwerten in der genannten Einstellung hinterlegt wurde.
Zu 2: Kann leider nicht helfen.
Zu 3: Je nach Farbraum ist eine bestimmte Beleuchtung mit bestimmter Lichtquelle vorgesehen (bei sRGB z.B. D50 mit 200 lux, nicht zu verwechseln mit dem sRGB Weißpunkt D65). Streng genommen müsstest Du für optimale Ergebnisse die festgelegten Bedingungen bezüglich des Umgebungslichts einhalten - was ich in den meisten Fällen jedoch für eher praxisfern halte.
warum verwendest nicht einfach dispcalGUI, dann erübrigt sich dieses ständige ärgern und umlernen.klusterdegenerierung hat geschrieben:..., aber vielleicht liegt dies ja auch nur an der echt Unterirdischen Software.
Die Spyder, zumindest bis V4 haben noch nirgends gute Rezensionen gekriegt. Hatte selbst nen 4er und der ist subjektiv klar schlechter als der x-rite! Der 5er soll immer noch schlechter als nen i1 DP Pro sein, habe aber selbst keinen getestet.klusterdegenerierung hat geschrieben: Ist der Spyder echt so übel oder ist es nur die Software?
Heißt jetzt DisplayCal und ist auch gut, macht bei nem HW kalibrierbaren Monitor wie im Topic aber keinen Sinn!!mash_gh4 hat geschrieben: warum verwendest nicht einfach dispcalGUI, dann erübrigt sich dieses ständige ärgern und umlernen.
hast schon recht, ich hab nur das gefühl gehabt, dass es dem kluster um software[-kalibrierung] gegangen ist.Roland Schulz hat geschrieben:Heißt jetzt DisplayCal und ist auch gut, macht bei nem HW kalibrierbaren Monitor wie im Topic aber keinen Sinn!!mash_gh4 hat geschrieben: warum verwendest nicht einfach dispcalGUI, dann erübrigt sich dieses ständige ärgern und umlernen.
aber geh! -- eine lut-box macht überhaupt nichts besser als die selbe operation direkt in software davor!Roland Schulz hat geschrieben:DisplayCal kann nur SW Kalibrierung (schlag mich wenn´s mittlerweile anders ist). ]Mit ner Ausgabekarte bleibt dann nur noch der Weißpunkt übrig, Farbraumskalierung, Gamma usw. gehen verloren - hatten wir hier schon mehrfach.
Ne LUT-Box kann ggf. noch helfen, macht "die Sache" aber weder einfacher, besser noch günstiger.
ja -- das ist natürlich wirklich eine andere geschichte...Roland Schulz hat geschrieben:Ne, für den TO sollte das alles mit dem vorhandenen Zeugs so gut über die Bühne zu bringen sein!
Das Ding war aber sehr elementar, da es zum einen mit wenig Patchfeldern auskommen musste und der Kalibrierprozess iterativ war, d.h. Drucken, messen, nochmal drucken, nochmal messen -> Kappes!!klusterdegenerierung hat geschrieben:Ohje, sowas habe ich befürchtet.
Sagt mal wie ist denn eigentlich dieser Colomonkey den es mal gab, der konnte doch schon für ein schmales Geld auch über Ausdrucke den Drucker kalibrieren oder?
Schon, wenn der Input nur 8bit ist und der Ausgang sowie Monitor dahinter 10bit ist geht da schon was. Bei nem DICKEN EIZO kann ich eine (Video-)LUT aber auch direkt (zusätzlich) in den Monitor laden (s.u.)...mash_gh4 hat geschrieben: aber geh! -- eine lut-box macht überhaupt nichts besser als die selbe operation direkt in software davor!
Der Vorteil ist, dass die Quantisierung bei den hier besprochenen Geräten eine höhere ist, damit Quantisierungsfehler kleiner werden und z.B. eine Grauachse auch nach Gammakorrektur neutrale Werte mit weniger Abweichungen trifft als wenn man das in der Grafikkarte mit 8, max. 10 bit schon vorher verdreht.mash_gh4 hat geschrieben: hardware kalibrierung im ziel-device ist dem gegenüber ja nur deshalb überlegen, weil dabei alle werte im übertragungskanal genutzt werden können und die korrekturen mit höherer genauigkeit erfolgen können. aber das ist leider auch mehr theorie, weil die betreffenden lösungen in den geräten bekanntlich auch nicht immer ganz so perfekt funktionieren und einem leider ausgesprochen wenig kontrolle und eingriffsmöglichkeiten jenseits der vorgegebenen bahnen erlauben.
das ist natürlich wirklich eine sehr phantasievolle lösung :)Roland Schulz hat geschrieben:Schon, wenn der Input nur 8bit ist und der Ausgang sowie Monitor dahinter 10bit ist geht da schon was.mash_gh4 hat geschrieben: aber geh! -- eine lut-box macht überhaupt nichts besser als die selbe operation direkt in software davor!
ja -- und genau die könnte dir das dispacalGUI bzw. argyll dahinter zu errechnen helfen -- würden dem nicht all die firmenspezifischen stolpersteine im weg stehen, die das dann in praxis doch wieder fast verunmöglichen bzw. nur mit proprietärer software des jeweiligen herstellers erlauben.Roland Schulz hat geschrieben:Bei nem DICKEN EIZO kann ich eine (Video-)LUT aber auch direkt (zusätzlich) in den Monitor laden (s.u.)...
hast du das gefühl, dass damit wirklich mehr zum ausdruck gebracht wird als in meinem: "weil dabei ... korrekturen mit höherer genauigkeit [im ziel-device] erfolgen können" ?Roland Schulz hat geschrieben:Der Vorteil ist, dass die Quantisierung bei den hier besprochenen Geräten eine höhere ist, damit Quantisierungsfehler kleiner werden und z.B. eine Grauachse auch nach Gammakorrektur neutrale Werte mit weniger Abweichungen trifft als wenn man das in der Grafikkarte mit 8, max. 10 bit schon vorher verdreht.
Frag´mich gerade was daran phantasievoll, lustig oder sonstwas sein soll?!?!mash_gh4 hat geschrieben:das ist natürlich wirklich eine sehr phantasievolle lösung :)Roland Schulz hat geschrieben:Schon, wenn der Input nur 8bit ist und der Ausgang sowie Monitor dahinter 10bit ist geht da schon was.mash_gh4 hat geschrieben: aber geh! -- eine lut-box macht überhaupt nichts besser als die selbe operation direkt in software davor!
Jo, hab ich durch den technischen Hintergrund der Quantisierung, zumal Deine Ausführung eher in eine unbelegte Abwertung dieser Methode abdriftet.mash_gh4 hat geschrieben:hast du das gefühl, dass damit wirklich mehr zum ausdruck gebracht wird als in meinem: "weil dabei ... korrekturen mit höherer genauigkeit [im ziel-device] erfolgen können" ?Roland Schulz hat geschrieben:Der Vorteil ist, dass die Quantisierung bei den hier besprochenen Geräten eine höhere ist, damit Quantisierungsfehler kleiner werden und z.B. eine Grauachse auch nach Gammakorrektur neutrale Werte mit weniger Abweichungen trifft als wenn man das in der Grafikkarte mit 8, max. 10 bit schon vorher verdreht.
Schade, ich empfand Deine Beiträge nämlich als sehr erkenntniserweiternd –Roland Schulz hat geschrieben: Bin raus jetzt hier...
Wieso sollte der Quantisierungsfehler kleiner werden?Der Vorteil ist, dass die Quantisierung bei den hier besprochenen Geräten eine höhere ist, damit Quantisierungsfehler kleiner werden und z.B. eine Grauachse auch nach Gammakorrektur neutrale Werte mit weniger Abweichungen trifft als wenn man das in der Grafikkarte mit 8, max. 10 bit schon vorher verdreht.
Beim reinen Transformieren von 8-bit auf 10/n-bit verändert sich erstmal gar nichts in Bezug auf die Quantisierung-/sfehler.WoWu hat geschrieben:@Roland
Kurze Verständnisnachfrage:Wieso sollte der Quantisierungsfehler kleiner werden?Der Vorteil ist, dass die Quantisierung bei den hier besprochenen Geräten eine höhere ist, damit Quantisierungsfehler kleiner werden und z.B. eine Grauachse auch nach Gammakorrektur neutrale Werte mit weniger Abweichungen trifft als wenn man das in der Grafikkarte mit 8, max. 10 bit schon vorher verdreht.
Wenn Du aus 8Bit mit (meinetwegen) einer Störspannung von 0,15 mV ankommst und das Signal in 10Bit mappst, dann wird der Quantisierungsfehler nicht kleiner sondern bleibt bei dem Wert, auch wenn ein Signal, direkt nach 10Bit quantisiert, eigentlich nur (meinetwegen) 73µV betragen hätte, also beträchtlich kleiner ist.
Nun hab ich das so verstanden, dass aus den 0,15 mV nach 10Bit gemapped,
73µV werden ?
Oder wie war das gemeint ?
@Wolfgang,WoWu hat geschrieben:@ Roland
Danke für die Erläuterung.
Sie geht aber leider am Kern meiner Frage vorbei.
Meine konkrete Frage war, wie sich der sichtbare Rauschanteil eines 8Bit Bildes von (Beispiel 0,15 mV durch Remappig auf 10 Bit) auf 73µV verändern, denn diese Störspannung wäre lediglich entstanden, hätte man das Bild statt auf 8 Bit, gleich auf 10 Bit quantisiert.
Ich würde auch gern bei den absoluten Werten bleiben, weil nur so eine direkte Reproduzierbarkeit gewährleistet ist und die Störspannung ja integraler Bestandteil des Bildes geworden ist ... ich kann mit analogen Werten auch noch umgehen, da mach Dir mal keine Sorgen. ;-)
Also ... wie soll das funktionieren, denn das war ja die Aussage, so, wie ich sie beratenden habe. ... oder habe ich da etwas falsch verstanden.
Und das trifft eben nicht auf ein 8Bit Signal zu, denn dabei wird das ursprüngliche Quantisierungsrauschen nicht verändert.Der Vorteil ist, dass die Quantisierung bei den hier besprochenen Geräten eine höhere ist, damit Quantisierungsfehler kleiner werden und z.B. eine Grauachse auch nach Gammakorrektur neutrale Werte mit weniger Abweichungen trifft als wenn man das in der Grafikkarte mit 8, max. 10 bit schon vorher verdreh
...nix ist anscheinend geklärt, das wird hier langsam wunderlich:WoWu hat geschrieben:Und das trifft eben nicht auf ein 8Bit Signal zu, denn dabei wird das ursprüngliche Quantisierungsrauschen nicht verändert.Der Vorteil ist, dass die Quantisierung bei den hier besprochenen Geräten eine höhere ist, damit Quantisierungsfehler kleiner werden und z.B. eine Grauachse auch nach Gammakorrektur neutrale Werte mit weniger Abweichungen trifft als wenn man das in der Grafikkarte mit 8, max. 10 bit schon vorher verdreh
Aber Du sagst ja selbst, Dein Beispiel trifft nur auf "Rechengenauigkeiten" zu.
Klar, da sind die Fragen nach der Relevanz störend, aber was glaubst Du, was der TS vor hat ?
Ich hatte das so verstanden, dass er einen Bildschirm kalibrieren will, auf dem er hinterher seine Videobilder beurteilen möchte und in dem Kontext führt deine Aussage einwenig in die Irre.
Bei Rechengenauigkeiten hast Du ja völlig recht, hat hier nur keine Relevanz, solange der TS keine 10Bit Signale benutzt.
Aber dann haben wir das ja geklärt.
Ach so, ja klar!! Also VORSICHT mit Zahlen und Werten ;-)!!! Bezogen auf was überhaupt?!?! Wenn wir uns auf 1V einigen sind´s 39mV, nicht 3,9mV!! So einfach ist das so nicht wenn hier und da Zehnerpotenzen unterschlagen werden!WoWu hat geschrieben:Das ist doch sehr einfach ...
Bei 8Bit hast Du ein Inkremental von 0,0039062 Volt.
...um den geht´s hier doch ÜBERHAUPT nicht!! Es geht darum was mit den Werten passiert die schon erfasst sind, nicht mit dem was bei der Erfassung schief ging. Das ist hier völlig irrelevant und wird nirgends referenziert!!WoWu hat geschrieben: Bei einem angenommenen Übertragungswerte von, meinetwegen 0,489844 Volt wäre das der Überagungswert von 125,400...
Also würde der Wert 125 benutzt werden ... der aber hätte dann den Wert 0,48828125
Das entspricht aber einer Fehlerdifferenz von 1,56275 mV
Das kann doch nicht so schwer sein.
Im ersten Teil nur halb falsch weil ich meine Argumentation zur Erklärung immer an einer statischen Quelle aufgezogen habe, der Graukeil rauscht nicht!! Ich habe keine zeitliche Veränderung - es rauscht nichts!!! Ansonsten wär´s bis dahin korrekt.WoWu hat geschrieben: Und Quantisierungsfehler. werden auch gern mal Quantisierungsrauschen genannt ... und da kommt der Signalstärabstand ins Spiel ... bei Dir vermutlich aber nicht.
WIR HABEN KEINE KAMERA!!!!! WIR HABEN ZUR ERKLÄRUNG MAX. EINEN GRAUKEIL IN PHOTOSHOP!!! NIEMAND HAT BEHAUPTET DASS 125,4 AUS DER GRAFIKKARTE KOMMT!!! Ein ursprünglich erfasster Wert ist IRRELEVANT!! Es geht einzig und allein darum was mit den Werten passiert, die schon im Rechner sind!WoWu hat geschrieben: Dieses Rauschen ist aber bereits Bestandteil des 8 Bit Signals, das Du auf den Monitor gibst... denn der Grauwert weicht schon bei der Aufnahme in der Kamera ab und ist fester Bildbestandteil.
Du kommst nämlich erst gar nicht mit dem Wert 125,4 xx an ... denn das ist schon auf 125 in der Kamera festgeklemmt.
...und ob!!! Lies alles noch mal in Ruhe, pack´ die Kamera weg und/oder lass Dir das mal bei Calumet vorführen und/oder kauf´ so´n Ding!!!WoWu hat geschrieben: Insofern nützt Dir die verbesserte 10Bit Handhabung im Monitor gar nichts.
WoWu hat geschrieben:Dann würde ich dem TS auch vorschlagen, nur computergenerierte Graukeile mit dem Monitor zu sehen und die Finger von 8Bit Videos zu lassen.
Zum Andern rede ich an keiner Stelle von Fehleraddition. Du versucht hier etwas zu komplizieren, um Mitleser in die Irre zu führen.
Ab wenn wir nicht über Video auf dem Monitor sprechen, hat sich das ja sowieso erledigt, dann muss der TS ja auch nicht kalibrieren.
Bei mir sind immernoch 1V ./. 256 = 0,0039062 Volt ... nicht anderes steht da. Und wenn Du irgendwo ein falsch gesetztes Komma gefunden hast, schenk ich es Dir, weil die Rechnung eindeutig ist.
Jeder, der es verstehen möchte, versteht es.
Aber Du ruderst ja langsam zurück ... zumindest sind wir schon mal bei Graukeil.
Wo das neunte Bit aus dem 8Bit Signal herkommen soll ist zwar immer noch nicht geklärt, aber das schenk ich Dir jetzt auch.
Aber gut zu erfahren, dass Deine Methoden nichts mit Kamerasignalen zu tun hat ... hätte ja sein können.
Vom TS hatte ich das so angenommen, aber da mag ich ja nun falsch liegen.
Aber ich hatte Angenommen, der TS wollte, dass der Wert 125 auch wie 125 aussieht und der Monitor nicht 124 darstellt. Irgendwas muss das also doch mit dem externen Signal zu tun haben.
Aber vielleicht will er das ja gar nicht.
Aber schön, dass wir mal drüber gesprochen haben.