Frage von pillepalle:Fand dieses Video zu dem Thema recht aufschlußreich. Vielleicht nimmt der ein oder andere ja auch was mit...
https://www.youtube.com/watch?v=U_NWEK3hn8w
VG
Antwort von klusterdegenerierung:
Ich fand dies damals ganz toll.
https://www.youtube.com/watch?v=jRI40Gl4I8g
Antwort von domain:
Ja das damals muss man wohl betonen.
Generell waren log-Aufzeichnungen ja aus der Not geboren, speziell Highlights, also höhere Dynamikumfänge noch irgenwie in 8 Bit codieren zu können, allerdings mit nachträglicher Korrektur durch Linearisierung.
Aber schon User vor ca. 10 Jahren hatten bemerkt, dass diese zusätzlich zur Verfügung gestellten Bits in den hellen Bereichen zulasten der "Feinzeichnung" in den Mitteltönen gingen.
WoWu hat das ausdrücklich bestätigt und unterstrichen.
Aber mit den höheren Bittiefen (10 oder mehr) dürfte sich das Thema wohl ziemlich erledigt haben.
Antwort von klusterdegenerierung:
Das stimmt, das macht auch Sinn die ganzen Entwicklungskosten in ein sinnloses Format zu stecken, wir sollten mal allen Anbietern von Log in 8Bit Cams verklickern das dies eine Schnaps Idee ist.
Wer weiß, vielleicht bekommen wir sogar von allen etwas Geld geschenkt weil sie nun wo sie wissen das dies überflüßig ist, ja auch wieder Kosten sparen.
Ich frag mal bei Sony ob die mir das Slog darausmachen und bei Blackmagic werd ich auch mal anklingeln das die sich den Speicherplatz der Log Luts sparen können.
Hatte eh immer das Gefühl das man mit Rec709 und Gamma 2.4 viel mehr highlight speichern kann als mit Log.
Man sind die alle dämlich, wenn die wüßten was Du weißt!
Antwort von dienstag_01:
domain hat geschrieben:
Ja das damals muss man wohl betonen.
Generell waren log-Aufzeichnungen ja aus der Not geboren, speziell Highlights, also höhere Dynamikumfänge noch irgenwie in 8 Bit codieren zu können, allerdings mit nachträglicher Korrektur durch Linearisierung.
Aber schon User vor ca. 10 Jahren hatten bemerkt, dass diese zusätzlich zur Verfügung gestellten Bits in den hellen Bereichen zulasten der "Feinzeichnung" in den Mitteltönen gingen.
WoWu hat das ausdrücklich bestätigt und unterstrichen.
Aber mit den höheren Bittiefen (10 oder mehr) dürfte sich das Thema wohl ziemlich erledigt haben.
Es ging darum, eine höhere Dynamic Range als in Rec709 möglich zu speichern. Und das sicher nicht in 8bit. Auf 8bit wurde es erst in den Consumerknipsen beschnitten.
Antwort von mash_gh4:
domain hat geschrieben:
Aber schon User vor ca. 10 Jahren hatten bemerkt, dass diese zusätzlich zur Verfügung gerstellten Bits in den hellen Bereichen zulasten der "Feinzeichnung" in den Mitteltönen gingen.
...
Aber mit den höheren Bittiefen (10 oder mehr) dürfte sich das Thema wohl ziemlich erledigt haben.
naja -- ein wesentlicher vorteil dieser ganzen LOG-hexerei liegt darin, dass man damit normalerweise helligkeitswerte in etwa der weise mathematisch behandelen kann, wie es auch den physikalischen gesetztmäßgkeiten draußen in der wirklichkeit entspricht. diese
scene referred helligkeiswerte bringt man mit der log() darstellung nur in eine form, die mit ganzzahliger werten gut abbildbar ist bzw. jeder blendenstufe gleich viele mögliche abstufung zur verfügung stellt, außer in den ganz dunklen bereichen, wo ja auch in linearer darstellung noch weniger unterschiedliche ausganswerte pro blendenstufe vom sensor geliefert werden. fast alle diese log-übertragungskurven setzten sich deshalb aus einem anfänglichen liniaren verlauf und danach mathematischer log() kodierung zusammen.
die altmodischen
display referred helligkeitswerte, die ja eigentlich noch aus der analogen videotechnik stammen, mögen zwar jede menge nostalgisches potential in sich bergen, verursachen aber jede menge probleme, wenn man komplexere bildbearbeitungunsoperationen mit diesen werten durchführen will. am bekanntesten ist das beispiel, was an farübergängen passiert, wenn man derartige sRGB bzw. rec709 farben ohne vorheriges linearisieren mit einen blur filter weichzeichnet:
zum Bild
(siehe:
https://ninedegreesbelow.com/photograph ... ssing.html)
während man im falle von LOG-material diese linearisierung relativ sauber vornehmen kann, so dass sich die farben auch rechnerisch so verhalten wie das in der natur der fall ist, ist das leider mit sRGB bzw. rec709 nur mehr ansatzweise möglich, genau genommen aber meist gar nicht mehr. d.h. derartiges material kann man zwar mit hilfe des vektorskops od. fingerspitzengefühl noch oberflächlich ein bisserl verbiegen, aber man bringt es kaum mehr in jene form zurück, wo man wirklich mit komplexere farboperationen od. kalibrierungstrechniken physikalisch korrekt -- also bspw. einen wirklich sauberen nachträgliche weißabgleich -- durchspielen könnte.
diesen unterschied halte ich für fast bedeutsamer als alleine nur das ständige herumreiten auf den abstufungsbezogenen unterschieden bzw. vor- und nachteilen.
Antwort von rdcl:
klusterdegenerierung hat geschrieben:
Das stimmt, das macht auch Sinn die ganzen Entwicklungskosten in ein sinnloses Format zu stecken, wir sollten mal allen Anbietern von Log in 8Bit Cams verklickern das dies eine Schnaps Idee ist.
Wer weiß, vielleicht bekommen wir sogar von allen etwas Geld geschenkt weil sie nun wo sie wissen das dies überflüßig ist, ja auch wieder Kosten sparen.
Ich frag mal bei Sony ob die mir das Slog darausmachen und bei Blackmagic werd ich auch mal anklingeln das die sich den Speicherplatz der Log Luts sparen können.
Hatte eh immer das Gefühl das man mit Rec709 und Gamma 2.4 viel mehr highlight speichern kann als mit Log.
Man sind die alle dämlich, wenn die wüßten was Du weißt!
So viel Log in 8bit gibt es doch garnicht mehr. Hst wohl auch seinen Grund.
Antwort von klusterdegenerierung:
Aha, Du meinst nur weil es jetzt 2 Consumer Cams mit intern 10Bit gibt, können die kein 8Bit Log?
Antwort von rdcl:
klusterdegenerierung hat geschrieben:
Aha, Du meinst nur weil es jetzt 2 Consumer Cams mit intern 10Bit gibt, können die kein 8Bit Log?
Nein, ich meine damit dass, sobald 10bit technisch möglich ist, es auch integriert wird. Das machen die ja auch nicht zum Spass. Ob das jetzt an Kundenwünschen liegt, oder an den Vorteilen für Log Formate, wird man nicht abschliessend klären können. Und 8bit LOG zu nutzen, obwohl 10bit verfügbar wäre, ist ja wirklich vollkommen unsinnig.