Klar geht es theoretisch, aber auch wenn Rec709 der Output Colorspace ist?dienstag_01 hat geschrieben: ↑Do 11 Feb, 2021 22:12 Ich denke schon, dass das geht. Da wird bei digitalen Prozessen doch nicht eingegriffen. Früher ging das analog oder bei bestimmten Codecs, die einfach abgeschnitten haben. Deshalb gibt es ja immer noch Filter, die Broadcast Safe ausgeben.
Wieso da nicht?rdcl hat geschrieben: ↑Do 11 Feb, 2021 22:14Klar geht es theoretisch, aber auch wenn Rec709 der Output Colorspace ist?dienstag_01 hat geschrieben: ↑Do 11 Feb, 2021 22:12 Ich denke schon, dass das geht. Da wird bei digitalen Prozessen doch nicht eingegriffen. Früher ging das analog oder bei bestimmten Codecs, die einfach abgeschnitten haben. Deshalb gibt es ja immer noch Filter, die Broadcast Safe ausgeben.
Ich war der Meinung dass Resolve die Levels dann automatisch auf 16-235 beschränkt, es sei denn man erzwingt Data Levels.
Wahrscheinlich verstehen wir illegale Levels unterschiedlich. Illegale Levels gibt es auch bei 16-235, umgekehrt sind Data Levels nicht automatisch illegal.
Data Level sind die Full Range und die gehört eben auch zur 709.carstenkurz hat geschrieben: ↑Fr 12 Feb, 2021 00:03 Man muss natürlich auch die Frage stellen, illegale Levels in Bezug auf welche Nutzung/Interpretation? Wenn an der Datensenke limited range erwartet wird, dann sind das illegale Level, weil sie geclippt werden. Data levels sollte man konsequenterweise auch nicht mehr als rec.709 bezeichnen, zumindest wenn nicht die Interpretation gesichert ist, sprich, die Datei noch als Zwischenprodukt vor einer Konvertierung in ein Normformat gilt.
Mit dem Thema illegale Levels hat das doch eher weniger zu tun, oder. Das ist eher eine Bestätigung, dass Farbraumumwandlungen Fehlerquellen sind.carstenkurz hat geschrieben: ↑Fr 12 Feb, 2021 01:11 Und auch hier passt's rein:
https://www.thepostprocess.com/2020/03/ ... -displays/
Ich habe den Artikel jetzt nicht wirklich gelesen, aber dass es bei Codecs wie DNxHD und Premiere Probleme gibt, weiß jeder Avidnutzer seit vielen Jahren. Für den Austausch musste man da immer einen merkwürdigen Weg gehen, Full Level aus Avid raus, Video Level in Premiere rein - irgendwie so, weiß ich nicht mehr, vergessen ;)carstenkurz hat geschrieben: ↑Fr 12 Feb, 2021 03:17 Ich habe grade jeweils genau die falschen Links in die beiden Themen gesetzt:
Hier geht's um Full/Video Levels:
https://www.thepostprocess.com/2019/09/ ... -vs-video/
Man kann das sicher leicht selbst mit Export/Reimport und Scopes prüfen.
Intern arbeitet Resolve ja eh in 32Bit Fließkomma. Im Grunde machen die Export-Optionen data/video gar keinen anderen Sinn. Bei video levels wird der 32Bit FP Arbeitsfarbraum auf 16-235 skaliert exportiert, bei data auf 0-255. Ob in den data level Anteilen tatsächlich Signal drin ist, ist aber abhängig von der Interpretation der Quellen ggfs. gekoppelt mit dem Arbeitsfarbraum und angewandten Korrekturen. Allerdings werden die exportieren Dateien dann, sofern unterstützt mit video vs. data getagged, was dann im weiteren Verlauf Probleme machen könnte.
Ansonsten gibts da bei YUV Exporten auch noch die Option 'retain sub-black and super-white data', die im Grunde den Zwitter gibt. video levels, aber mit sub-black und super white unten drunter und oben drüber.
Ist das eine Vermutung oder weißt du das sicher?TheBubble hat geschrieben: ↑Fr 12 Feb, 2021 21:46 Man kann schon trotz vorher limitierten Materials "illegale" Levels erzeugen, wenn man einen verlustbehafteten Codec verwendet. Ich würde mir da aber nicht so viele Gedanken machen, denn wenn es wirklich darauf ankommt, dann muß der Decoder den Wertebereich zur Sicherheit erneut limitierten.
Es geht nicht um irgendein bestimmtes File. Es geht darum die Frage zu klären. Vor allem auch im Bezug auf die Scopes in Resolve, die ja auch nicht die Output-Werte repräsentieren. Weil selbst wenn alle Levels während dem Geading auf 0 aufsetzen ist das resultierende File nicht illegal. Und die Frage ist ob das am Output Color Space liegt.
Im Prinzip z.B mit jedem verlustbehafteten DCT basierenden Codec. Bei stark verlustbehafteten JPEGs (als Beispiel für einen Codec) sieht man an Kanten oft Artefakte. Diese Artefakte sind Abweichungen vom gewünschten Wert. In geeigneter Konstellation können durch diese Abweichungen Werte entstehen, die außerhalb des für einige Video-Systeme erlaubten Wertebereich von 16-235 (bei 8 Bit Quantisierung) liegen.
die leider auch nicht funktionieren... :(pillepalle hat geschrieben: ↑Sa 13 Feb, 2021 05:43 PS: Keine Ahnung warum die Screenshots gerade nicht angezeigt werden. Ich habe euch die Links zu den Bildern noch einmal darunter gesetzt.
nein -- der von dir genutzte webserver weigert sich leider momentan verbindungen entgegen zu nehmen:pillepalle hat geschrieben: ↑Sa 13 Feb, 2021 05:59 Ja, keine Ahnung warum die nicht angezeigt werden. Hab die eigentlich auf 900 Pixel runter skaliert damit man sie im Forum sehen kann. Ich habe aber die jeweiligen Links unter die Bilder gesetzt, die man anklicken kann.
Code: Alles auswählen
$ wget -d -4 -O /dev/null https://giotta.de/full_video.jpg
Setting --inet4-only (inet4only) to 1
Setting --output-document (outputdocument) to /dev/null
DEBUG output created by Wget 1.21 on linux-gnu.
Reading HSTS entries from /home/mash/.wget-hsts
URI encoding = »UTF-8«
--2021-02-13 06:05:46-- https://giotta.de/full_video.jpg
Certificates loaded: 127
Auflösen des Hostnamens giotta.de (giotta.de)… 87.230.60.46
Caching giotta.de => 87.230.60.46
Verbindungsaufbau zu giotta.de (giotta.de)|87.230.60.46|:443 … Closed fd 4
fehlgeschlagen: Verbindungsaufbau abgelehnt.
Releasing 0x000055b0f83426d0 (new refcount 1).
nein -- leider! -- die bereits geposteten debug-infos beziehen sich auf den letzten derartigen link in deinem ursprünglichen beitrag. aber eben leider auch dort nur "Verbindungsaufbau abgelehnt" :(pillepalle hat geschrieben: ↑Sa 13 Feb, 2021 06:12 Ich kann aber, wenn ich auf die darunter stehenden Links klicke das Bild sehen. Müsste bei Dir auch funktionieren.
ja -- jetzt geht's! :)pillepalle hat geschrieben: ↑Sa 13 Feb, 2021 06:40 So... jetzt aber :) Habe sie woanders hochgeladen.
bei programmen, die das sauber umsetzten, sollte zw. diesen beiden varianten tatsächlich kein unterschied erkennbar sein. es stehen zwar im einen fall ein paar übertragungswerte mehr zur verfügung, aber das spielt in der praxis nur eine vernachlässigbare rolle und wiegt die nachteile einer nicht standard-konformen übertragung in keiner weise auf.pillepalle hat geschrieben: Warum die Ausgabe von Videolevels, die auch Videolevels interpretiert werden jetzt etwas härter und gesättigter wirken, als wenn man Full Levels ausgibt die man auch als Full Levels interpretiert, verstehe ich allerdings noch nicht so ganz :)