DV-Chris hat geschrieben:Wo sind jetzt die, die gemeint haben, dass man bei Adobe über Jahre hinweg alte Projekte ohne Probleme mit neuen Versionen öffnen kann?
Versteh ich nicht. Öffnen geht doch problemlos. Oder ;)
Der Bericht enthält nur die halbe Wahrheit, zumindest per Stand heute:
Ja, es handelt sich offensichtlich um einen Bug im Effekt "RGB-Kurven" (RGB Curves) in Pr CC.
1. Projekte, die diesen Effekt nicht benutzen, sind nicht betroffen!
Man darf davon ausgehen, dass der Fehler behoben wird.
Nein, anders, als im Artikel dargestellt: der Effekt "Luminanzkurve" (Luma curves) besitzt diesen Bug per heute nicht. Er funktioniert einwandfrei.
2. Projekte, die den Effekt Luminanzkurve verwenden, sind nicht betroffen!
BTW: Ich hatte in mehreren Threads hier im Forum Diskussionen darüber geführt, die den Sinn der Korrektur mittels Luminanzkurve verdeutlichen wollten. Genau darum geht es in diesem Warning-Artikel.
Gelernt hatte ich in diesen Diskussionen, dass etliche User hier im Forum das Vorhandensein von Bildinformationen im Videofile außerhalb des bildgebenden Bereichs gar nicht kannten, sowieso nicht nutzen und sogar vehement abgestritten haben.
3. Diese User sind nicht betroffen. ;)
Wer es trotzdem mal wagen will, das Optimum aus seinen Videos zu holen, dem empfehle ich nach wie vor "Luminanzkurve" - auch in Pr CC zum jetzigen Zeitpunkt.
NB: Die im Artikel angeratene Korrektur der "Super whites" und "sub blacks" mittels "Schneller Farbkorrektur" (Fast Color Correction) birgt die Gefahr der Farbverfälschung (Stichigkeit). Hier hat man schnell mehr Schaden angerichtet als man Nüztzliches gewinnt ... - Parametervielfalt verleitet ...
Und ein Hinweis zum Workflow am Rande (nur für die, die das Thema tatsächlich interessieren mag): Luminanzkorrektur gehört m. E. zu den vorbereitenden Reparatur-Aufgaben wie Stabilisieren, Denoisen oder Rolling-Shutter-Korrektur und sollte gesondert abgefackelt werden. Das eigentliche Projekt stützt sich auf im Grunde fehlerfreies Material.
Man kann natürlich auch alles in eine Kiste packen ... - jeder, wie er mag.
Ich vermute mal, dass das unterschiedliche Verhalten nur bei der Verwendung von Fließkomma-Bitmaps auftritt.
Reiner M hat geschrieben:
Ja, es handelt sich offensichtlich um einen Bug im Effekt "RGB-Kurven" (RGB Curves) in Pr CC.
Das ist die Frage. Man könnte auch argumentieren, dass es vorher ein Bug war, der nun beseitigt wurde. Denn immerhin gibt es kein schwärzer als Schwarz (Weiß analog) und das neue Verhalten sollte dem Verhalten bei der Verwendung von Integer-Bitmaps entsprechen.
Letztlich läft es darauf hinaus, dass man sich als Entwickler für ein Verhalten entscheiden muss und dieses auch dokumentieren sollte.
TheBubble hat geschrieben:
Letztlich läft es darauf hinaus, dass man sich als Entwickler für ein Verhalten entscheiden muss und dieses auch dokumentieren sollte.
Ja.
Aber genau dieses Feature war ein Plus seit CS3.
Und da alle anderen Effekte, die das bisher konnten, auch in der CC unverändert funktionieren und den Zugriff auf die Bilddaten außerhalb der bildgebenden Bereiche Dank 32bpc bis in die RGB-Umsetzung hinein erlauben (das können andere NLEs nicht unbedingt), und da RGB-Kurven immer noch ein "YUV"-markierter Effekt ist (also vor RGB wirkt), nehme ich wie die Autoren dieses Artikels an: Es ist es wohl ein Bug im Effekt RGB-Kurven.
Wir werden sehen.
Beste Grüße,
Reiner
Edit: Es macht eigentlich keinen Sinn, einen (für den User) teuren 32bpc-Modus mit Float zu implementieren, um ihn dann wie einen 8bpc-Integer arbeiten zu lassen. ;) Das könnte man für alle Beteiligten viel einfacher realisieren ...
Reiner M hat geschrieben:
Edit: Es macht eigentlich keinen Sinn, einen (für den User) teuren 32bpc-Modus mit Float zu implementieren, um ihn dann wie einen 8bpc-Integer arbeiten zu lassen. ;) Das könnte man für alle Beteiligten viel einfacher realisieren ...
Doch, das kann durchaus Sinn machen. Sowohl aus Nutzersicht (bekannte Erwatungen werden bedient), als auch aus technischer Sicht:
Diverse Effekte können schneller abgearbeitet werden, wenn man zuerst ein paar Tabellen berechnet und anschließend nur noch Zwischenwerte interpoliert. Allerdings müssen diese Tabellen auch ihre Grenzen haben, bei Werten auserhalb des abgedeckten Bereichs nimmt man dann z.B. den nächstliegenden Wert. Dies entspricht dem neuen Verhalten.
Problematisch ist es, das Verhalten einfach zu verändern. Der IMO bessere Weg wäre es den alten Effekt auslaufen zu lassen und einen neuen veränderten Effekt einzuführen.
TheBubble hat geschrieben:
Problematisch ist es, das Verhalten einfach zu verändern. Der IMO bessere Weg wäre es den alten Effekt auslaufen zu lassen und einen neuen veränderten Effekt einzuführen.
TheBubble hat geschrieben:Ich vermute mal, dass das unterschiedliche Verhalten nur bei der Verwendung von Fließkomma-Bitmaps auftritt.
Reiner M hat geschrieben:
Ja, es handelt sich offensichtlich um einen Bug im Effekt "RGB-Kurven" (RGB Curves) in Pr CC.
Das ist die Frage. Man könnte auch argumentieren, dass es vorher ein Bug war, der nun beseitigt wurde. Denn immerhin gibt es kein schwärzer als Schwarz (Weiß analog) und das neue Verhalten sollte dem Verhalten bei der Verwendung von Integer-Bitmaps entsprechen.
Letztlich läft es darauf hinaus, dass man sich als Entwickler für ein Verhalten entscheiden muss und dieses auch dokumentieren sollte.
Das ist doch eine gute Nachricht ich sehe das wie Bubble, .... ein Bug weniger.
Eine korrekte Transformtion vom anliegenden YCbCr nach RGB beseitigt das Problem nämlich im Ansatz.
Wer hinterher trotzdem "Superweiss" herstellen möchte und über kein Farbmanagment verfügt, kann ja immernoch kurbeln- nur eben in die andere Richtung- und sich bei dunklen Farben den Grünstich einhandeln und bei hellen Farben das Rosa.
Wer's mag .... jedenfalls hat Adobe, spät, aber immerhin, den Fehler erkannt
... bei den Grafik/Videoauflösungen hat es bei Adobe ja auch 10 Jahre gedauert, aber letztlich kam es dann.... genauso überraschend.
Still und heimlich .... Bugs hängt man nun mal nicht so gern an die grosse Glocke.
Aber die Programme reifen immerhin beim Kunden. Nur nicht bei allen Herstellern. Einige Ignorieren ihre Bugs einfach.
(Das wird übrigens alle leidgeplagten Besitzer von Kameras mit türkisfarbenen Bildern freuen.) :-))
WoWu hat geschrieben:Das ist doch eine gute Nachricht ich sehe das wie Bubble, .... ein Bug weniger.
Interessante Sichtweise.
Wenn ich die eine Farbkorrekturmethode anwende, kann ich Werte ausserhalb des standardisierten Bereichs sichtbar machen. Und wenn ich eine andere anwende, dann sind die Werte weg.
Und das heisst dann, damit ist ein Bug behoben.
Aber mit WELCHER der beiden Methoden.
WoWu hat geschrieben:
Das ist doch eine gute Nachricht ich sehe das wie Bubble, .... ein Bug weniger.
Eine korrekte Transformtion vom anliegenden YCbCr nach RGB beseitigt das Problem nämlich im Ansatz.
Das ist falsch.
Bereits die Y-, wie auch die Cb- und Cr-Daten (also die Daten im Videofile) liegen außerhalb des bildgebenden Bereichs. Völlig standardkonform. Ist so.
Die YCbCr-to-RGB-Transformation wird von Premiere Pro korrekt vorgenommen gemäß der Ausrichtungs- und Synchronisationspunkte. Premiere Pro macht das allerdings standardmäßig in einem 32bit-float-RGB-Farbraum, in dem die Bildinformationen außerhalb des bildgebenden Bereichs bewahrt werden können. Das ist wohl gewöhnungsbedürftig?
In einem 8bit- oder 16bit-Integer-Zielfarbraum wird allein aufgrund der technischen Begrenztheit der Speichermethode voll automatisch gekappt.
Leute, die auf solchen Systemen arbeiten, kennen es nicht anders, sehen diese Bildinhalte auch nie.
Der Bug besteht nun darin, dass der Effekt RGB-Kurve (und nur der! - alle anderen funktionieren einwandfrei), praktisch wie auf einer 8bit-Umsetzung arbeitet.
Der "Schaden", den dieser Bug verursacht, hält sich in Grenzen. Er ist nur für Leute bedeutsam, die die Vorteile eines 32bit-Workflows auch mit diesem Effekt nutzen, um z. B. extrem hellen Bildpartien (es geht nicht um inhaltsleeres "Superweiß"), die detailleer und ausgebrannt wirken, noch die Zeichnung zu geben, die im Quellvideo tatsächlich enthalten ist.
Da JPEG und folgende keine Synchronisationswerte in den Bilddatenstrom abbilden müssen, also 0 u. 255 und weiters keine Sicherheitsbereiche, also 1-15 und 236-254, konnte schon immer für die Werte Y, Cb und Cr der volle Wertebereich von 8 Bit (oder mehr) verwendet werden.
Ich habe Camcorder gehabt, die sich brav an den eingeschränkten Wertebereich hielten aber auch solche, die ihn voll ausnützten, alles gut im Waveformmonitor zu beobachten.
Eigentlich verstehe ich nicht, dass nicht irgend ein Flag in den Metadaten einen Hinweis auf die beiden Codierungsmethoden gibt.
domain hat geschrieben: ... konnte schon immer für die Werte Y, Cb und Cr der volle Wertebereich von 8 Bit (oder mehr) verwendet werden.
domain,
das ist nicht der Grund.
Es ist zu unterscheiden, ob der Encodierer in der Cam Daten außerhalb des bildgebenden Bereichs speichert oder nicht. Beides ist nach den Standards zulässig und beides kommt vor. Die meisten Cams, die mir bisher untergekommen sind, machen das jedoch.
Davon zu unterscheiden ist, wie diese Bildinformationen aus dem Videofile im NLE behandelt werden. Beim Mappen gemäß einer korrekten yuv2rgb-Umsetzung in einen 8bpc-RGB (bildgebender Bereich umfasst maximal 0-255) ist dafür schlicht kein Platz, weil keine Werte größer 255 gebildet werden können. Folge: Clipping. Aber das bemerkt man gar nicht, weil man es eh nicht anders kennt oder sichtbar machen kann in einem solchen RGB-Raum.
In einem 32bpc-float-RGB (bildgebender Bereich maximal 0.0 - 1.0) ist Platz, weil Werte größer 1.0 darstellbar und erlaubt sind. Premiere Pro nutzt das.
Die "Überhänge" werden nun dort korrekt gemäß der yuv2rgb-Umsetzung gespeichert (>1.0). Die Berechnungen aus Luma mal Colors mal Faktoren ergeben als Ergenisse ganz schlicht diese Werte größer 1.0, wie sie auch Werte größer 255 für 8bpc ergeben würden. Die Werte gößer 1.0 stehen aber in diesem Modus für nachfolgende Operationen, z.B. für eine Luma-Korrektur, zur Verfügung. Das geht mit 8bpc eben nicht.
Der Bug besteht darin, dass der Effekt RGB-Kurve offensichtlich Werte größer 1.0 kappt, sich also quasi wie im 8bpc-Modus verhält. Effektiv gehen dadurch wichtige Informationen, die im Video enthalten sind und die Premiere-Pro-User (alle anderen dürfte das eh nicht interessieren) seit der CS3 nutzen können, verloren.
Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Do 20 Jun, 2013 09:20, insgesamt 1-mal geändert.
domain hat geschrieben:Da JPEG und folgende keine Synchronisationswerte in den Bilddatenstrom abbilden müssen, also 0 u. 255 und weiters keine Sicherheitsbereiche, also 1-15 und 236-254, konnte schon immer für die Werte Y, Cb und Cr der volle Wertebereich von 8 Bit (oder mehr) verwendet werden.
Ich habe Camcorder gehabt, die sich brav an den eingeschränkten Wertebereich hielten aber auch solche, die ihn voll ausnützten, alles gut im Waveformmonitor zu beobachten.
Eigentlich verstehe ich nicht, dass nicht irgend ein Flag in den Metadaten einen Hinweis auf die beiden Codierungsmethoden gibt.
SMPTE240M bzw.260M ist die Norm für Videosignale und regelt das seit den 90er Jahren. Signale ausserhalb der Videonormierung (z.B. xvYCC) benutzen das Signalbit 240. Damit wird auch HDMI umgeschaltet auf -non default-.
Und es gibt auch keine Werte ausserhalb der normierten Bereiche. Luma endet bei 235 und Chroma bei 240.
Ist doch alles klar und funktioniert doch auch in allen NLEs, die die Signale normgerecht behandeln.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Reiner_M hat geschrieben:In einem 32bpc-float-RGB (bildgebender Bereich maximal 0.0 - 1.0) ist Platz, weil Werte größer 1.0 darstellbar und erlaubt sind. Premiere Pro nutzt das.
Die "Überhänge" werden nun dort korrekt gemäß der yuv2rgb-Umsetzung gespeichert (>1.0). Die Berechnungen aus Luma mal Colors mal Faktoren ergeben als Ergenisse ganz schlicht diese Werte größer 1.0, wie sie auch Werte größer 255 für 8bpc ergeben würden. Die Werte gößer 1.0 stehen aber in diesem Modus für nachfolgende Operationen, z.B. für eine Luma-Korrektur, zur Verfügung. Das geht mit 8bpc eben nicht.
Langsam begreife ich, wieso hier immer so unverständliches Zeugs steht.
Reiner_M glaubt, dass Adobe Premiere sein Material beim Import normgerecht behandelt. Und da es ihm dann gelingt, mit 32bit Effekten Werte von oberhalb 255 wieder *zurück* zu holen, baut er sich sein Weltbild nach dem Motto, 32bit bringen ihm Reserven , die es in 8bit nicht gibt (konkret eben Werte von 255+ bzw. 0-). Und lässt sich dafür auch noch lustige Begründungen einfallen ;) (sei nicht böse, so ist das nun mal).
Wenn er aber wüsste, dass Premiere beim Import den Farbraum auf FullRange (0-255) spreizt und damit erst die Werte, die vorher im Bereich 235-255 lagen, über die magische Grenze von 255 hinausschiebt, würde er, und davon bin ich übertzeugt, zu ganz anderen Schlüssen kommen.
Das ist mir auch erst nach der Diskussion um den richtigen Workflow zwischen Avid und Premiere von vor zwei Tagen klar geworden.
So siehts aus ;)
Reiners Denkfehler liegt darin, dass er von einer linearen Übertragung des Signals ausgeht, wie sie auch in der ursprünglichen Fassung von SMPTE240 im Jahr 1986 vorgesehen war.
Darin sind etwas gröbere Quantisierungsschritte vorgesehen und die Übertragung endete bei Referenz-Weiss und umfasste 7 Blenden.
Bei einer solchen linearen Übertragung entsteht ein Gap zwischen Referenz-Ws und FullWell.
Das ist wohl die "Reserve" von der er immer spricht und meint, einige Hersteller würden diese noch ausnutzen. Aber das ist seit 1989 vorbei.
Denn 89 hat Sony den Vorschlag der gekrümmten Übertragungskurve in die Arbeitsgruppe eingebracht und gleichzeitig die "Normalisierung" des Signals vorgeschlagen, was sowohl die volle Ausnutzung des Weissbereiches, als auch die Kompartibilität aller Kameras, aller Hersteller mit sich brachte.
Dafür wurden die Quantisierungsschritte verkleinert.
Seit der Zeit gibt es keine "Reserve" mehr und wenn Signale ausserhalb des Wertebereiches auftauschen, so sind das Transienten und andere Probleme, für die der Bereich extra freigemacht wurde. Das ist aber alles Andere als ein Videosignal, auch wenn man es auch schnellen Waveforms sieht.
Es gibt also diese "Reserve", von der Reiner spricht, nur noch in Kameras, die vor 20 Jahren gebaut wurden. Heute wird die gesamte Dynamic von Peak-Weiss, bis zum Noise Limit übertragen. Da gibt es keine Reserve, dafür aber 2,5 Blenden mehr.
WoWu hat geschrieben:
Das ist wohl die "Reserve" von der er immer spricht und meint, einige Hersteller würden diese noch ausnutzen.
Ich vermute die "Reserve" die von ihm angenommen wird, liegt in dem für die Überschwinger freigehaltenen Bereich. Natürlich soll dieser nicht verwendet werden.
Wenn jedoch jemand z.B. einfach eine sRGB Bitmap (0-255) zu BT.709 (16-235) "umlabeld" ohne auch nur einen Wert anzupassen, dann verschiebt sich plötzlich Schwarz- und Weißwert und eine Menge nicht erwünschte Werte (alles nahe 0 und nahe 255) landen in den für Überschwinger reservierten Bereichen. Dies wäre dann die "Reserve", die es so gar nicht geben sollte. Mag sein, dass einige digitale Kameras das auch absichtlich tun und dazu die Übertragungsfunktion für diese Bereiche fortsetzen (vermutlich in der Hoffnung, dass nie jemand ein analoges Signal daraus erzeugt, ohne vorher die nicht erlaubten Werte abzuscheiden oder den verwendetet Wertebereich sonstwie anzupassen).
Eine andere Sache wäre Color Grading, da kann es für bestimmte Arbeitsabläufe nützlich sein, als Zwischenergebnis auch nicht sichtbare Werte zuzulassen, damit diese für weitere Korrekturfilter noch verfügbar sind und ggf. im Arbeitsergebnis nach Anwendung weiterer Filter wieder sichtbar werden können. In dem Fall sollte das genaue Verhalten aber gut dokumentiert werden.
dienstag_01 hat geschrieben:So sieht die Y-Wavform eines Bildes mit sattem Schwarz und völlig überstrahltem Weiss im Avid aus.
Ist von einer EX1 oder 3.
Es gibt Bildinformationen über 235? (Laut Skala nebendran). Wo kommen die denn her?
Was passiert im zugehörigen Video, dort in den Lichtern, wenn Du dessen Luma so korrigierst, dass diese Spitzen oberhalb 235 auf unterhalb 235 (100%) runtergedrückt werden (nicht clippen).
Reiner_M hat geschrieben:Was passiert im zugehörigen Video, dort in den Lichtern, wenn Du dessen Luma so korrigierst, dass diese Spitzen oberhalb 235 auf unterhalb 235 (100%) runtergedrückt werden (nicht clippen).
Da lässt sich natürlich minimal noch etwas Zeichnung retten.
Aber, weil du von 235 als 100% schreibst: das ist ja dein Trugschluss. In Premiere sind 100% natürlich 255.
dienstag_01 hat geschrieben:
Da lässt sich natürlich minimal noch etwas Zeichnung retten.
Danke. ;)
Beste Grüße,
Reiner
Edite:
Und wo kommen diese Werte größer 235 nun her? Ihr erklärt doch laufend: Die gibt es nicht und kann es nicht geben. Macht Avid da etwa was falsch? das ist Luma, also Y. Nicht RGB.
Ich könnte natürlich auch eine RGB Parade reinstellen.
Aber: Avid macht natürlich nichts falsch, das Bild idt überstrahlt/clipped.
In Premiere wird das Bild nur nochmal gespreizt, deshalb enstehen da Werte oberhalb 1.0 (255), die du dir dann mit einer 32bit Farbkorrektur zurück holst. Und glaubst, das ist was ganz besonderes von Adobe Premiere. Das selbe geht mit Avid in 8bit auch ;)
dienstag_01 hat geschrieben:... deshalb enstehen da Werte oberhalb 1.0 (255), die du dir dann mit einer 32bit Farbkorrektur zurück holst. Und glaubst, das ist was ganz besonderes von Adobe Premiere. Das selbe geht mit Avid in 8bit auch ;)
Werte über 255? Zurückholen? In 8bit? Mach mal .... ;)
Im Ernst:
Du hast mit Avid ein tolles Programm an der Hand. Es zeigt m. E. wie Premiere Pro auch für Luma in der Waveform Werte größer 100% bzw. Byte 235. Ich habe nichts anderes erwartet.
Hast du Premiere Pro?
In Premiere Pro heißt die Skala statt 100%/235 nur eben Volt (für PAL) bzw. IRE (für NTSC) gemäß den Standard-Empfehlungen. Hier wäre 1.0V Dein 235/100% in Avid.
In beiden NLEs gibt es oberhalb dieser Linie Werte. Dein Video-File würde bei mir ein entsprechendes Bild mit Werten zwischen 1.0V und 1.06V zeigen
Das liegt daran, dass der Standard etwa +10% (genauer +10IRE) Überstrahlungsbereich erlaubt. das ist so festgelegt. Das ist der Bereich zwischen Reference White (100%, 100IRE, 700mv, 1.0V, Byte 235 - je nach Skala des Herstellers.) und White-Peak (+10IRE). Dies kann man auch in Deinem Waveform-Screenshot als Skalenvorgabe sehr schön sehen.
Vertraue dem Avid. Prüfe künftig, ob deine Videos Luma über 100% zeigen und korrigire sie ggf. entsprechend. Das wird sich positiv auf die Farben in den Lichtern auswirken und ggf. augenscheinliche Ausbrennungen partiell retten können.
Wolfgangs Grafik, die er weiter oben gepostet hat, zeigt einen Sonderfall und ist nicht der Weisheit letzter Schluss.
-------------------------
@Wolfgang,
ich weiß ja nicht, wo Du die Grafik her hast. Wieder fehlt der Kontext.
Die Grafik zeigt eindeutig einen Sonderfall, nämlich die Wirkung eines "Clippers" in der Prozesskette. Steht ja auch deutlich drin, in der Grafik.
Dieser Clipper hat die Aufgabe, sendefähige Farben zu erzeugen. D.h. er "clippt" ganz einfach den Bereich zwischen Reference White und White Peak - so zeigt es die Grafik. Oder sind nun 110IRE gleich 700mV? Das glaube ich kaum! Du sicher auch nicht ...
Der Clipper sorgt also dafür, dass die insgsamt 110 IRE Signalbereich in die 100IRE bildgebenden Bereich überführt werden - leider durch Clipping. Da kommt ja sein Name her.
Das kann wohl jedes NLE auch in der Post erledigen. In Premiere Pro heißt dieser Effekt übrigens "Sendefähige Farben". Funktioniert genau so. --- Aber genau das wollen wir ja nicht!
Es gibt Cams, in denen ist das so oder ähnlich realisiert. Z. B. die Canon DSLRs, wie Dienstag bestätigen kann. Diese Cams produzieren keine Signale oberhab 100% in den NLEs. Das ist bereits kameraseitig unterbunden. Genau wie es Deine Grafik erklärt.
Die meisten Cams haben aber keinen implementierten Clipper! ist so.
So z. B. auch nicht Dienstags EX1 oder meine X909 oder tausend andere. Was auch völlig standardkonform ist - das weißt Du auch.
Diese Cams nutzen in Y die nach Standard erlaubten +10 IRE (236-254). Es ist nirgends verboten, das zu tun. Deshalb sieht man dort echte, diskrete Signalwerte im Luma-Wave.
Nach Standard ist der bildgebende Bereich aber nur 100 IRE (0-100) groß (100%, PAL 300mv bis 1.0V =700mV; Y 16-235). Ist ganz einfach so festgelegt.
Alles, was darüber liegt, darf von einem NLE gar nicht angezeigt werden ohne Manipulation. Sonst wäre ja der bildgebende Bereich als solcher plötzlich ein anderer. Ich kann es aber erzwingen, jedoch nur durch Eingriff in die Luminanzkurve.
Die Umsetzung nach RGB ist dann erst ein weiterer Schritt.
Mach doch mal das Bild dazu auf, was das für "Streusel" sind. So ist das einwenig "fischen im Trüben".
@Reiner...
Die 109% gelten für analoge Signale und für lineare Übertragungen, nicht aber für gammakorrigiertes Material.
Hab ich oben alles geschrieben.
Die Zeichnung ist Teil einer SMPTE Publikation zu 240M
Im Standard ist auch festgelegt, dass Kameras mit dem "Normelizer" ausgestattet sein müssen und so sicherstellen, dass die Bereiche, die ja auch in der Übertragung eine andere Verwendung haben, denn sie sind ja nicht zur Schikane eingefügt, freigehalten werden.
Der Normalizer ist zwar erst 1993 in den Standard eingefügt worden, weil Sony ihn verspätet eingebracht hat, wird aber von den Herstellerfirmen bereits seit der Einbringung ausgeführt.
Es geht also nicht darum, dass der Videobereich eingeschränkt wird, sondern darum, dass die restlichen Bereiche(oberhalb und unterhalb) nutzbar sind -aber eben nicht für Video-
Sofern Kameras ausserhalb des Standards arbeiten (einige DSLR Geräte tun das, wird das Signal aber auch in R'G'B' abgelegt.
Und nun lies den Standard und schau, ob Deine Kamera vielleicht defekt (oder verkurbelt) ist.
Ach, vielleicht noch eine Frage: "warum funktioniert das bei 99% aller Kameras und ebenso (vermutlich) bei allen andern NLEs ?
Nur bei Dir nicht? Hat Adobe da vielleicht doch einen Bug ... oder sind alle andern NLEs defekt ?
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.
