Ich würde trotzdem, fast wetten, das hat damit zu tun denn das ist genau der Effekt, der auch auftritt, wenn man ein Fixpoint Projekt auf Floting Point umstellt.
Dann schiessen auch erstmal alle Werte nach oben und man muss sie "von Hand" wieder "einfangen"
Woher weisst Du, wie gemapped wird und woher, dass das Material transparent importiert wird ?
Der Waveform Monitor spricht da eine ganz andere Sprache.
So wie ich das bisher verfolgt (und verstanden) habe, ist das Material doch gleich nach dem Import schon so verschoben.
Morgen Olja, ich habe mir den Belle Nuit in FCPX und Davici angesehen, da ist kein Unterschied.. die Skalierung geht in beiden Anwendungen 0-100%.
In davinci ist es klar die 10bit Skalierung von 0-1023 und in Fcpx von 0-255 aka 0-100 konform in V.. auch die 0 und 255 Werte werden korrekt ausgewiesen..
Da sind ja 10 Seiten an Information zusammengekommen. :-)
Ich schreibe hier abends um 2300.
***** OT *******
Kurz vorweg, Weissabgleich X909: Man muss beim automatischen Abgleich wissen, was man tut. Grundsätzlich bei Tageslicht und Mischlicht mit Tageslichteinfall (blau) kein Problem. Bei Kunstlicht (Mischlicht) wird von mir manuell abgeglichen (und bleibt so). Bei Tageslicht würde ich höchstens im Innenraum bei kleinem Tageslichtfenster und Gold gelber Glühlampenbeleuchtung aus Stimmungsgrūnden eine Entscheidung mit manuellem WB treffen.
Bezüglich Detaildarstellung ausserhalb von dunklen Garagen. Ab 150 Lux Helligkeit kann man "echt" FullHD aufgelöste Bilddetails erwarten.
Fast alle meine veröffentlichten Video-Standbilder entsprechen in Gamma und Farbsättigung dem normalen Videoumfang. Bei der SD909 satt und der X909 mehr neutral weiss).
Und real im FlatTV darstellbar in den Spitzen ist noch Zeichnung, wie auch in dunkel schwarzen Kirchenszenen noch Zeichnung ist.
Mit 8 Bit muss man in jedem Fall korrekt belichten ;-)
Bei einem Consumercamcorder kann ich auch ohne NLE Korrektur ein gutes Ergebnis erwarten.
(Bei 10 Bit und mehr muss man auch noch das Rauschen berücksichtigen, was ein 8 Bit Consumercamcorder in jedem Fall ganz gut in der Bildverarbeitung erledigt.)
***** OT Ende *******
Klar kann man im NLE "normieren", man verändert so oder so Bilddetails und Farbstufungen (und verliert schlimmstenfalls 2/3 der Farbnuancen beim einlesen in einen professionellen MPEG2 Codec ;-)
- Weil man Werte komprimiert um Videonormgerecht zu sein (inkl. Gamma der Darstellungskette)
- Oder extreme Werte geclippt werden.
Dessweiteren sind aus AVCHD diverse Bildsignalisierungen nach einem neu Encoding nicht mehr vorhanden und somit für immer verloren.
Für mich privat erhalte ich "geschnitten" die umfängliche "native" Kamera-Bildqualität (für den Consumer nicht relevant oder nicht "einfach" nachvollziehbar. D.h. Die komplette Darstellungskette muss einstellbar, oder die Signalisierung stimmen. Moderne FlatTV können RGB 0..255, aber nicht unbedingt Zeichnung in superweiss darstellen.)
Es ist für mich klar, dass eine 3-Chip RGB Sensorquelle eine "saubere" Basis bildet als ein single Sensor mit Bayer-Filter.
Insofern das auch die Zusammensetzung der RGB Sensorempfindlichkeit verändert werden könnte (einzel Sensor Clipping).
Hier haben wir ja nur ein NLE Clipping- und nicht ein 8 bit Kameraproblem, da der Sensor in der hochwertigen Consumer Cam weit mehr kann als in "echt" heute dargestellt wird.
Denn die dargestellte absolute Helligkeit ist nicht abhängig von 8, 10 oder mehr Bit (Banding).
Ich sage es immer gerne 3x 8 Bit ist True Color mit über 16 Mio Farben.
8 Bit in 16-235 ist nicht schlecht, ist aber bereits eine Qualitätsreduktion im Helligkeitsumfang und den Farbstufungen.
In einem hochwertigen gerenderten Workflow (upgrade) erhalte ich bestenfalls normgerecht die Qualität, bis zum erneuten Rendern für das Zielsystem. Was im Normallfall immer noch gut aussieht (in jedem Fall ist jede Normwandlung verlustbehaftet).
Darum ist ein Consumercamcorder auch wenn er die detaillierteren besseren Bilder machen würde, keine Broadcastcamera mit entsprechendem professionellen Codec (Eingangsqualität nach Norm).
Gruss Tiefflieger
Zuletzt geändert von Tiefflieger am Fr 28 Jun, 2013 06:07, insgesamt 1-mal geändert.
Sind unterscheidbare und quantitativ aufsummierte Farbnuancen (Tieffliegerspezialität) eigentlich identisch mit dem Tonwertumfang?
Wie ermittelt man die Menge der unterscheidbaren Farbnuancen eigentlich?
Hat ein flacheres Profil, also ohne starke Kontraste weniger oder gleich viel Farbnuancen zu bieten als ein kontrastreicheres?
Unabhängig von dem eigentlichen Thema des Threads habe ich mir heute Abend mal mit dem hier schon öfter beschriebenen "Türkis anstelle von Hellblau"-Problem befasst, dass scheinbar nicht für jeden ein Problem ist.
Eine erste Analyse deutet darauf hin, dass tatsächlich Y Werte in den reservierten Bereichen (0-15, 236-255) aus dem H.264 Decoder herauskommen. Mangels Tageslicht, dafür aber auch noch mit Bewölkung, kann ich derzeit leider keine geeigneten Testaufnahmen für weitere Versuche erzeugen. Auch konnte ich noch nicht völlig ausschließen, dass der von mir verwendete H.264 Decoder keine Werte spreizt (ich gehe allerdings nach Betrachten der Y-Werte eher nicht davon aus).
Bei Interesse kann ich das Thema noch einmal aufgreifen.
domain hat geschrieben:Sind unterscheidbare und quantitativ aufsummierte Farbnuancen (Tieffliegerspezialität) eigentlich identisch mit dem Tonwertumfang?
Wie ermittelt man die Menge der unterscheidbaren Farbnuancen eigentlich?
Hat ein flacheres Profil, also ohne starke Kontraste weniger oder gleich viel Farbnuancen zu bieten als ein kontrastreicheres?
Mit Farbnuancen meine ich unique colors
Ab einem Standbild (Frame) mit wenig motion blur zählt man bsp. weise die unique colors (Bildbearbeitungsprogramm) und kann auch mit Histogrammen die Tonwertverteilung sehen (inkl. Tonwertspreizung bei Nachbearbeitung).
Mit Upscaling oder Bildbearbeitung kann ich mehr Farbnuancen erhalten (Interpolation).
Bei einem natūrlichen Bild ab Kamera haben 3-4 Pixel die gleiche Farbnuance.
In Stadtszenen können es 10 - 20 Pixel sein die die gleiche Farbnuance haben.
Im schlimmsten Fall ist der Farbumfang in 3x16 Bit enthalten, was zu 8 Bit limitiert zu weniger Farbnuancen fūhrt.
So erkläre ich mir den teilweise eingeschränkten Filmcontent den ich habe, da ist in 4K Bildauflösung und 14 Bit weniger im Farbumfang enthalten als bei meiner 3-Chip in 8 Bit (Farbnuancen als 48 bit TIFF absolut gezählt)
Grundsätzlich empfinde ich auch ein Bild mit wenigen Farbtonwerten gut, da es den Lichteinfall und Farbverlauf zeigt.
Aber es ist eine eingeschränkte Farbpalette, da "echte" gemessene Farbnuancen aus der Kamera fehlen (in 3-Chip aus deckungsgleichen RGB Werten und nicht interpoliert).
So sind normalerweise auch die farbigen Bilddetails höher aufgelöst als bei einer single Chip mit Interpolation.
Sony z.B. erkennt bei neueren Consumer Cams (Smartphones) inhaltliche Bildteile (Objekte) und versucht die farbliche Detailauflösung zu erhöhen (gilt auch für Upscaling von Blurays zu ~4K, wo sogar zusätzliche echte 4K Pattern/Objekte im Datenstrom sind.)
Mir kommt vor, dass die Anzahl der Unique Colors an sich kein Qualitätskriterium für ein gutes Bild sein kann, eher sollte das ganze Bild eine einzigartige Farbe aufweisen.
Wie behandelt Magix eigentlich die Werte über 100% ?
Ich meine, selbst beim Smartrendern gibt es nach einem Schnitt in der Timeline ja zumindest eine GOP, die neu gerechnet werden muss. Sieht man in den ersten Bildern dieser GOP einen Sprung z.B. in den Lichtern?
Motion, danke. Seite 7 dürfte für den BellNuit der Fall sein.
Der liegt bei mir in FCPX innerhalb von BroadcastSave (700mV, 8Bit), bei DaVinci außerhalb (Spitze bei 1023,10 bit). Und wenn 2 Programme auf den ersten Blick unterschiedliche Interpretationen zulassen, wird es schwierig.
Davon abgesehen, das ich mich gar nicht so weit reinhängen wollte, aber für mich jetzt mitgenommen habe (was WoWu eigentlich auch meinte), dieser ganze Quatsch in diesen Bereichen rumzufummeln bringt nichts. Es wär besser, wenn solche Werte erst gar nicht zustande kommen. Was nützt mir ein Camcorder, dessen Bild ich nur am TV nativ sehe, aber die Bearbeitung im NLE komische Ergebnisse bringt, weil er halt über der Norm liegt. Und das machen die. Zumal das Rückholen der "scheinbar" ausgebrannten Lichter auch nicht die Qualität mehr bringt (Pixelwolken, Banding)
Weder die GH2 läßt sich in die Wertebereiche bewegen um solchen Mist zu erzeugen, die GoPro staucht das im Protune sogar zusammen (Log) und man erhält wesentlich bessere Ergebnisse für die Post, als irgendwie in Lichtern rumzufummeln.
Wenn die Pana da generell irgendwie ein Problem hat, was nutzt das ? Ich muß das Material vernünfig in allen NLE's bearbeiten können und das muß auch vernünftig gemappt werden. Wenn man sich im BroadcastSave-Bereich bewegt, sollte es bei allen keine Probleme geben.
Von daher macht es schon Sinn (im Moment jedenfalls noch), einfach sich auch nur darin zu bewegen.
Motion, danke. Seite 7 dürfte für den BellNuit der Fall sein.
Olja, Olja. Was hat denn nun YPbPr mit deinem Chart zu tun?!
Du hast immer noch nicht verstranden, dass die Problematik an einer ganz anderen Stelle liegt: Wie und wo wird ein standardkonformes Signal, dass mit 16-235 in der Rec 709 beschrieben ist, für ein Ausgabegerät, wie es der Computermonitor ist, auf dessen Farbraum, der nun mal 0-255 hat, umgemapped, konvertiert oder was weiss ich. Genau deshalb nämlich zeigt dir FCP 100% für Weiss an, was laut Spezifikation 235 ist, auf deinem Vorschaubild aber 255.
Und Davinci zeigt wiederum die 255 (in 10bit 1023) an.
Darüber wunderst du dich nun die ganze Zeit.
Motiongroup brauchst du dazu nicht zu befragen, weil ihm das alles LOGISCH ist. Ist es auch, aber als Erklärung taugt logisch ja nun wenig (und das von ihm verlinkte Dokumente auch nicht) bis gar nichts.
Man muss das auch alles nicht verstehen, arbeiten kann man (weitestgehend) auch ohne dieses Wissen. Wenn man aber nach mehrtägigem Exkurs zu einem Fazit wie diesem von dir oben kommt, kann man nur sagen: FALSCH.
Aber egal, ich wunder mich nun gar nicht mehr und du hast recht, man kann auch ohne damit arbeiten.
Mein Fazit bleibt aber trotzdem, ich arbeite dann lieber im "BraodcastSave". Denn wegen dem "außerhalb" ist eigentlich dieser ganze Zauber hier erst enstanden. Und auch bei Adobe
Olja hat geschrieben:Nö, da ging es um RGB Mapping, wie bei dem Chart.
RGB to YPbPr Format Conversion. Steht da als Überschrift. Oder meintest du was anderes?
Ich will nicht Krümelkacken..
YPbPr ist die ursprüngliche analoge Version des digitalen YCbCr, mit dem u. a. die auf der DVD gespeicherten sowie die bei DVB per Sat, Kabel oder Antenne übertragenen Videodaten farbkodiert sind.
War einfach nur meine generelle Beobachtung eines mappings aus RGB, vor allem, wie sich das auf die Anzeige auswirkt. Mehr eigentlich nicht. Aber auch wurscht.
Ich filter eben den Thread jetzt ganz grob und sage mir, bleib einfach in dem Raum und schneide endlich deine Filme weiter. Ich hab wirklich 2 Tage mit Testgeflime verplemert ;-). Ich wolle nur die Anzeige einigermaßen deuten können. Es muß und darf nicht meine Baustelle sein. Vermutungen helfen auch nicht weiter (könnte gemappt sein ,evtl. )
Genau so wenig, wie ein Koch Thermodynamik beherschen muß, wenn er nur den Kühlschrank bedient.
Evtl. steig ich wieder ein, wenn Cameras über Turbinen betrieben werden und man über h-ds diagramme diskutiert. Oder Statik, technische Mechnik, oder Hydraulik.
Jeder Vollhorst sollte eigentlich wissen, welche Kräfte beim Stativ wirken und die auch kennen. Ansonsten wird er nie einen Film machen können. Logisch, oder ?
Aber manche klemmen einfach nur ihre Kamera rauf und machen ihren Film. Einfach unglaublich...
dienstag_01 hat geschrieben:@Olja
Du sagst es, die analoge Version. Aber bei dir sind scheinbar analoge Signale auf der digitalen DVD gespeihert ;)
Oder anderes ausgedrückt, man muss schon auch im richtigen Wikipedia-Eintrag stöbern (oder ihn richtig interpretieren).
Aber egal.
Wenn du mich fragst, Thermodynamik ist wirklich gerade voll Out, für dich wäre eher die Heisenbergsche Unschärferelation was ;)
Es ging ja nur um den Effekt eines Mappings.
Out ist Vieles. Wird man aber bitter bereuen, wenn es nur noch IMM oder BWL geben wird ;-). Aber die Leute sind wenigstens weg von der Straße bzw. Harz4 und machen keinen Blödsinn. Über den Nutzen braucht man nicht zu diskutieren, dann müßten wir alle Bauern sein.
domain hat geschrieben:Mir kommt vor, dass die Anzahl der Unique Colors an sich kein Qualitätskriterium für ein gutes Bild sein kann, eher sollte das ganze Bild eine einzigartige Farbe aufweisen.
Wie behandelt Magix eigentlich die Werte über 100% ?
Ich meine, selbst beim Smartrendern gibt es nach einem Schnitt in der Timeline ja zumindest eine GOP, die neu gerechnet werden muss. Sieht man in den ersten Bildern dieser GOP einen Sprung z.B. in den Lichtern?
Mit unique colors habe ich einfach die unveränderten "originalen" Farbwerte ab Kamera (Farbwerte kann man auch relativ zueinander betrachten).
Klar kann man ein grünes Baumblatt in 5 grüntönen (Farbnuancen) darstellen ;-)
Der Vorteil von Magix wäre noch, dass nur veränderte Bildfolgen neu gerendert werden (Inhaltlich verändert mit z.B. einem Titeltext oder an hübschen Szenübergängen). Der Rest ist Smart und somit unverändert.
Um 100% Farbpegel muss ich mich nicht kümmern, da ich auch in der Darstellungskette möglichst native bleibe.
Keine Motion Kompensation (Doppelkonturen), keine automatische Kontrast- oder Farbanpassung sowie Nachchschärfung während der Wiedergabe.
Grundsätzlich kann man GOP oder Framegenau schneiden, technisch bleiben wie bei Aufnahme die Zwischenbildinformationen erhalten. Es gibt keine "unruhigen" Szenenübergänge, wie "steppende Fussgänger" bei hartem Schnitt (Für Farben mit WB ist man bei Aufnahme selbst verantwortlich).
Bei Magix hatte ich schon einmal einen "grauen" Szenenübergang nach einer 20 Minütigen Szene, dafür keinen Ton Gap (AVCMerge macht keinerlei Effekte, es ist auch kein Szenen kürzen möglich).
Gruss Tiefflieger
Zuletzt geändert von Tiefflieger am Mo 01 Jul, 2013 04:36, insgesamt 3-mal geändert.
@All
Auf Broadcast save brauche ich für mich keine Rücksicht nehmen.
Ich nehme einfach für mich privat die volle Qualität aus der Kamera mit (und nicht die Politur ;-).
Und Pixelwolken sind das bei der X909 nicht, es ist ggf. eine helle Tönung die sonst im Bild ausgebrannt fehlt (z.B. auf weissem Flugzeug im gleissenden Sonnenlicht sind kleinste Türbeschriftungen in rot erkennbar).
Schlimmstenfalls werden mit herunterziehen lineare (Schwarzwerte, Stauchung) oder nichtlineare (Gamma) Effekte zum tragen kommen.
In ein paar Jahren ist das kein Thema mehr, da werden haufenweise neue "Directors Cut" in vollem 10 oder 12 Bit erscheinen.
D.h. alle Bildanpassungen entsprechen dem heutigen Stand und Qualitätsanspruch mit der Option Retro.
(Bis dahin habe ich meine 20m VR Brillen Leinwand oder Kontaktlinse)
TheBubble hat geschrieben:Unabhängig von dem eigentlichen Thema des Threads habe ich mir heute Abend mal mit dem hier schon öfter beschriebenen "Türkis anstelle von Hellblau"-Problem befasst, dass scheinbar nicht für jeden ein Problem ist.
Eine erste Analyse deutet darauf hin, dass tatsächlich Y Werte in den reservierten Bereichen (0-15, 236-255) aus dem H.264 Decoder herauskommen. Mangels Tageslicht, dafür aber auch noch mit Bewölkung, kann ich derzeit leider keine geeigneten Testaufnahmen für weitere Versuche erzeugen. Auch konnte ich noch nicht völlig ausschließen, dass der von mir verwendete H.264 Decoder keine Werte spreizt (ich gehe allerdings nach Betrachten der Y-Werte eher nicht davon aus).
Bei Interesse kann ich das Thema noch einmal aufgreifen.
Also, ich hab mir jetzt auch mal das Premiere Pro runter geladen und es scheint in der Tat so zu sein, dass das 7,5 IRE Offset (in den USA nach wie vor noch gültig) nicht abgestreift wird.
Das erledigt man manuell mit einem Proc-Amp, der in der deutschen Version von PP: StabVerst. heisst und in den "YUV/32" Effekten liegt.
Also: YUV oder 32 => Videoeffekte => Anpassen => StabVerst => Helligkeit => -7,5
und alles ist in Butter ... kein Stauchen, kein Clipper, kein Banding und kein Dither.
(Sowas machen andere Programme eben automatisch).
Mein Vorschlag ist nach wie vor, in Y'CbCr (bei Adobe: YUV) zu arbeiten, dann klappt das auch mit den guten Qualitäten, weil es keine Wandelverluste mehr gibt.
WoWu hat geschrieben:Also, ich hab mir jetzt auch mal das Premiere Pro runter geladen und es scheint in der Tat so zu sein, dass das 7,5 IRE Offset (in den USA nach wie vor noch gültig) nicht abgestreift wird.
1. Was hat das 7,5 IRE Offset in einem PAL-Land zu suchen?
2. Warum benutzt du nicht einfach den Schalter in der YC-Waveform für dieses Offset?
Du kannst dir nochmal die Vergleichsbilder von Avid und Premiere hier im Thread auf Seite 1 und 2 anschauen, du wirst keinen Unterschied feststellen.
1)
Es ist immer eine Frage, für welchen Markt das Produkt gemacht ist. Immerhin ist das Offset noch ATC Vorschrift in Nordamerika.
Einige Kameras machen das daher nur bei 30/60; 29,97/59,94 und 23,976 und nicht bei 25/50/24.
Aber die Kamera entspricht damit dem ATSC Standard.
Vielleicht kann man den Standard in der Kamera ja sogar anwählen und er steht nur Default-mässig falsch.
Warum benutzt du nicht einfach den Schalter in der YC-Waveform für dieses Offset?
2)
Ich tippe mal drauf, dass so ein "Schalter" im WFM nur was an der Anzeige macht, aber nichts am Signal.
Es geht aber nicht darum, die Anzeige umzuschalten sondern das Signal korrekt zu mappen, ohne die ganzen internen Verhältnisse im Signal zueinander zu verkurbeln.
Ich hab das Programm auch nur angeworfen und ein paar Minuten damit probiert, um zu sehen, was der Unterschied ist und warum alle das "buggige"- Color Clip Curves brauchen.
Vielleicht gibt's ja so eine, für das Offset vorgesehene Methode.
@WoWu
Ich wollte eigentlich nur zum Ausdruck bringen, dass das 7,5 IRE Setup nur im NTSC Raum eine Rolle spielt, und da auch nur in einem Teil.
Eventuelle Fehler im Mapping von PAL-Material - die es meiner Meinzúng nach gar nicht gibt - wird man damit nicht erklären können.
Übrigens, meine Vergleichsbilder auf den Seiten 1 und 2 sind NTSC. Da sieht man auch, dass sie korrekt erkannt werden (YC-Waveform aus Avid und Premiere).
Aber die Vergleichsbilder waren ja nicht von der Panasonic 9xx ?
Denn hier ging es ja auch darum, dass die Kamera den 'Türkisstich' haben sollte, der dann nur mit dem "Color Curves-Tool" zu beseitigen wäre, das ja nun clipped und daher als verbugged gilt.
Mal ganz abgesehen davon, dass das ohnehin das ungeeignete Tool gewesen wäre.
Was das Off-set betrifft, so ist es leider noch sehr "lebendig" und im ATSC Raum nicht nur -nach wie vor- Teil der Spezifikation, sondern auch tatsächlich 'gelebte Gegenwart".
Ergo: Beseitigt man mit dem Proc-Amp das Offset, hat man ein ganz normales Signal (ohne Türkisstich).
Ach so, du bist in der türkisen Bilderwelt mit Milliarden JUNIC KOLORS von Tiefflieger. Vergebene Liebesmüh, der WILL das so. Ausserdem war doch weiter vorn schon ein Weg beschrieben, der Fehler der clippenden Curves tritt doch nur bei ein oder zwei Tools der CC auf.
Aber auch hier sollte ganz allgemein gelten: Tieffliegers bewunderte Cam sollte kein dem NTSC-Format geschuldetes Offset liefern.
Edit: Mit Tieffliegers Cam meine ich einfach nur die PAL-Version.
Nun ja, das kann gut sein, dass er eine "PAL" Version hat, die das richtig mapped.
Ansonsten bin ich ziemlich weit bei ihm, dass Bilder nicht erst durch möglichst kräftiges Nachbearbeiten "gut" werden.
Die besten Bilder kommen nach wie vor aus der Kamera und mit solche Tools, wie "Color Curves" werden sie sowieso nicht unbedingt besser.
Jedenfalls hat das Tool, indem es Clipper, keinen Bug.
(War das nicht irgendwie der Kern des Threads) ?
WoWu hat geschrieben:Jedenfalls hat das Tool, indem es Clipper, keinen Bug.
(War das nicht irgendwie der Kern des Threads) ?
Ob Bug oder nicht Bug, darüber kann man wirklich geteilter Meinung sein. Für alle, die in ihren bisherigen Projekten mit den Curves gearbeitet haben, und zwar nach der Methode, die Werte oben etwas abzusenken, für die könnte es die VOLL-Katastrophe sein. Wenn sie viel abgesenkt haben, fehlt ihnen jetzt das richtige Weiss im Bild.
Muss man aber nicht unbedingt Bug nennen ... ;)
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
