Wieso nur 12-bit Farbraum?

na, du hast schon noch deine 16,7 Mio Farben, keine Bange.

24 bit per Pixel (bpP) heisst, dass Du jeweils 8 Bit fuer R G und B hast, oder aber jeweils 8 Bit fuer Y U und V (Y = Helligkeit und U V = Farbe)

bei 16 bpP hast du zwei Y - Pixel nebeneinander, die sich eine Farbeigenschaft teilen, d.h. pro Pixels hast du die Datenmenge von 1xY , 0.5xU und 0.5xV , was im schnitt 16 bpP ergibt. (YUY2)

und bei 12 bpP teilen sich vier Y-Pixel ein Farbsample, was dazu fuehrt, dass ein Pixel die Datenmenge von 1xY, 0.25xU und 0.25xV hat. (YV12 oder YUV420)

dadurch aendert sich aber nicht die anzahl der darstellbaren Farben, sondern nun die Farbaufloesung.
Also keine Sorge. Das ist schon richtig so. YV12 wird immer bei MPEG verwendet.

http://www.uni-kassel.de/~eckhardm/Frame8HQwip.htm

Ist eine Erklaerung fuer die verschiedenen Colorspaces.

Wenn man denn darauf zugreifen könnte - 403:

Zitat

Sie sind nicht berechtigt auf die angeforderte Seite zuzugreifen.

Bitte beachten Sie:
Falls Sie versuchen, auf eine Seite zuzugreifen, die nur für den Zugriff durch Angehörige der Universität freigegeben ist, muss Ihr Computer an das Netzwerk der Universität Kassel (ghknet) angeschlossen sein.
Das bedeutet, dass Sie entweder einen Computer benutzen müssen, der sich innerhalb der Universität befindet und ordnungsgemäß angemeldet ist; oder Sie müssen den Einwählzugang des Hochschulrechenzentrums benutzen.

Falls Sie sich über einen externen Provider einwählen, können Sie nicht auf interne, zugriffsbeschränkte Dokumente zugreifen!

____

Vielleicht noch mal etwas ausführlicher (groß ausdiskutiert haben wir ähnliche Sachen z.B. in diesem Beitrag):

Alle (alle!) MPEG-kompatiblen Videoformate (egal ob MPEG1-, MPEG2- oder MPEG4-kompatibel) speichern standardmäßig Helligkeits- und Farbdifferenz-Informationen mit der Subsampling-Konfiguration 4:2:0, (fast) die selbe würde auch von unkomprimierten YV12-AVIs verwendet werden (wie das aussieht: Siehe diese Webseite; ebenfalls interessant: diese Seite); andere sind zwar teilweise auch erlaubt, müssen aber gesondert eingestellt werden, und sind z.T. nicht DVD-kompatibel.
_

Ein unkomprimiertes RGB24-AVI benötigt für jeden Pixel in allen drei Komponenten (rot, grün, blau) 8 bits: 3 Komponenten * 8 bits / 1 Pixel = 24 bits pro Pixel. Soweit einfach.

Jetzt ein bißchen komplizierter:

Bei 4:2:2-Subsampling (wie bei YUY2 oder UYVY) hat jeder einzelne Pixel einen Helligkeitswert Y, aber je zwei nebeneinander liegende Pixel teilen sich je eine Farbdifferenzkomponente U und V. Das bedeutet: Die kleinste Einheit, die man mit (einer Gruppen von) vollständigen 8-bit-Bytes speichern kann, ist eine Gruppe von je zwei nebeneinander liegenden Pixeln. Die benötigen dann 2 Bytes für die einzelnen Y-Werte, und je 1 Byte für die gemeinsamen U- und V-Werte - die kleinste speicherbare Einheit sind somit 2+1+1 = 4 Bytes. Das macht also 4 Bytes * 8 bits / 2 Pixel = 32 bits / 2 Pixel = durchschnittlich 16 bits pro Pixel.

Und zum Schluss noch komplizierter:

Bei 4:2:0-Subsampling (wie bei YV12) hat jeder einzelne Pixel einen Helligkeitswert Y, aber je vier im Quadrat benachbart liegende Pixel teilen sich je eine Farbdifferenzkomponente U und V. Das bedeutet: Die kleinste Einheit, die man mit (einer Gruppen von) vollständigen 8-bit-Bytes speichern kann, ist eine Gruppe von je vier neben- und untereinander liegenden Pixeln. Die benötigen dann 4 Bytes für die einzelnen Y-Werte, und je 1 Byte für die gemeinsamen U- und V-Werte - die kleinste speicherbare Einheit sind somit 4+1+1 = 6 Bytes. Das macht also 6 Bytes * 8 bits / 4 Pixel = 48 bits / 4 Pixel = durchschnittlich 12 bits pro Pixel.
__

Und warum meldet nun DivX "24 bit", während XviD "12 bit" meldet?

"Keine Ahnung - die Programmierer fragen!"

Vielleicht ist der DivX etwas ungenau und meldet als bevorzugtes Decodierformat "RGB24", obwohl sein natürliches unkomprimiertes Format eigentlich YV12 am ähnlichsten ist - weil praktisch alle Videoverarbeitungs-Programme unkomprimiertes RGB-Video problemlos verarbeiten können.

Der XviD ist da vielleicht genauer; nur ist (wie in dem oben genannten Beitrag) nicht jedes Programm in der Lage, planare Formate zu verarbeiten. Deshalb bietet sich der XviD-Codec zusätzlich auch als "Codec" für YV12 an, um solche (in dieser Hinsicht 'unfähigen') Programme zu unterstützen, und eine Konvertierung von YV12 in das gewünschte Format bereitzustellen. (Seit kurzem tut DivX das übrigens auch...)

Oder es kommt darauf an, womit der DivX-/XviD-Codec ursprünglich gefüttert wurde (also ob RGB24, YUY2 oder YV12 zu MPEG4 komprimiert wurde). Und dann läge es tatsächlich daran, welches Programm verwendet wurde, und wie es eingestellt war (z.B. VirtualDub oder -Mod im Fast-Recompress- oder Full-Processing-Mode). In dem Fall wäre die Frage nach den Qualitätsunterschieden so zu beantworten: "Je weniger Umwandlungen zwischen den Formaten, umso besser" - dann wäre der Sieger: YV12 (für YUY2 wären Mittelwertbildungen und Interpolationen nötig, für RGB24 sogar eine Komplett-Umrechnung zwischen RGB und YUV; da geht viel Genauigkeit verloren!).
__

Programme, die sich von einem VfW-Codec ein komprimiertes Video (z.B. bei DivX oder XviD im MPEG4-Format) decodieren lassen, dürfen sich übrigens vom "Image Compression Manager" (der Technologie, die seit Windows 3.x mit VfW 1.x existiert) in einer Liste wünschen, in welches Format sie es gern decodiert haben würden - und zwar in der Reihenfolge, wie sie's am liebsten hätten. Manche Programme wünschen sich vom ICM nur RGB24; andere hätten gern erst YUY2 oder UYVY, dann RGB24; nur wenige (wie VirtualDubMod) erlauben auch YV12. Das dürfte damit zusammenhängen, dass YUY2 und UYVY genau wie RGB24 auch "gepackt" sind, während YV12 "planar" ist, und deshalb völlig anders behandelt werden muss. Näheres dazu im hier oben genannten Beitrag...
____

Falls jemand fragt: Ich bin dafür verantwortlich, dass so viele gesammelte Details "sticky" gemacht wurden...

Zitat

Wenn man denn darauf zugreifen könnte - 403:

Krass! Ich hab mich danach todgesucht und dann auch so um 23:xx Uhr gefunden. Aber ab um 0:00 kam dann nur der 403. Da ham die im Rechenzentrum wohl was umgebaut *grrrr*.

Aber ich hab die Seite geistesgegenwaertigerweise gespeichert.
Und mal auf meinen Space gelegt: http://home.arcor.de/scharfis_brain/colorspaces/

hi

ich hab viel über mpeg4 gelesen und da dies warscheinlich auch ein verwandter ist kann ich nur folgendes sagen
das liegt am codec der nur simple profile unterstützt
bei studio profile oder vieleicht bei core studio profile hast du 24 - 32 bit
und datenraten zwischen 400-1600Mbit/s zur verfügung.
also ich suche noch immer vergeblich nach studio profile codec

mfg lod

Na super - da läßt man sich wochenlang zu solchen Themen aus, und dann kommt da jemand mit Halbwissen und bringt wieder alles durcheinander...

Ein normaler PC kann auf YUV-Overlays der Grafikkarte nur 8 bit pro Komponente (Y, U, V) verwalten. Bei 4:2:0-Subsampling macht das 4*8 bit für Y, 1*8 bit für U und 1*8 bit für V für je 4 Pixel, also 32+8+8=48 bit / 4 Pixel, also im Durchschnitt 12 bit/Pixel.

Sollten diese ominösen Studio-Profile (eine Quellenangabe zu deren Definition wären schon nett gewesen, um auch mal was der Gemeinschaft beizutragen) mehr als 8 bit pro Komponente erlauben, dann wären am Ende tatsächlich durchschnittlich mehr als 12 bit pro Pixel möglich; beispielsweise würden 16 bit pro Komponente die doppelte Datenmenge pro Pixel ermöglichen (24 bit/Pixel). Wollte man das Video mit 4:4:4-Subsampling speichern, wären sogar 48 bit pro Pixel nötig!

Nur frage ich mich dann ernsthaft, wo bitte schön du Originalmaterial in so fein aufgelöster Genauigkeit herbekommen willst? Ich kenne jedenfalls keinen einzigen Codec, der auf einem PC mehr als 8 bit pro Kanal speichern kann. Laut http://www.fourcc.org sind lediglich einige Codecs bekannt, die 10-bit-genaue Komponenten speichern können sollen (UYVP, YUVP).

Ich bleibe also weiterhin dabei: "Schuld" an der angeblich geringeren Bitanzahl im Header von Videos ist die Durchschnittsberechnung wegen des Subsamplings. Aber egal ob 24, 16 oder 12 bit drin stehen (weil das Ursprungsvideo RGB, YUY2 oder YV12 war), gespeichert wird immer MPEG4 mit 4:2:0-Subsampling, und decodiert wird ganz am Ende nach RGB (etwas anderes gibt eine Grafikkarte über das VGA-Kabel ja nicht aus).

sorry

ich möchte mich entschuldigen dass ich keine quelle angegeben habe
ich denke dass müßte sie sein

Teil 1

hier werden nochmals die Profile durchgenommen

Teil 2

ich hoffe ihr seid mir nicht böse denn ich hab mich tatsächlich bei ein paar dingen geirrt und entschuldige mich bei allen doch nobody is perfekt

auf der seite stand dass man im mainprofile 32 bit rgb farbraum hat
das ist nur dann wichtig wenn du ne renderszene gemacht hast die du nicht gleich wieder killen willst in dem du gleich wieder 99% daten wegwirfst was du durch monatelanges rendern erschaffen hast
wär ja nicht wirklich gut wenn du nen film so eindämmen würdest
k ich weiß nur wenige von euch machen renderscenen aber ich z.b. mache renderscenen und ich will nicht gleich wieder dass alles umstonst war

ich hoffe ihr verzeiht mir meine unwissenheit
aber ich lass mich gerne belehren und gebe meine fehler gerne zu

mfg lod

32-bit-Farbraum - kenne ich bisher nur als RGBA, also mit Transparenzkanal. Meiner Meinung nach ist der für Videos aber relativ unsinnig.

In der ersten Quelle steht leider nichts über Profile. Bei der zweiten muss man sich erst mal anmelden (hab grad keinen leichten eMail-Zugriff)...

Aber in der DivX-5-Kommandozeile soll man Studio-Profile auswählen dürfen. Über den Wizard aber nicht?!

Ich finde allerdings, dass diese Diskussion nicht besonders zum genannten Thema passt. Lass uns diese Diskussion im anderen Beitrag fortführen.
__

Und keine Angst: Wenn mir jemand einen Fehler nachweist, dann stehe ich genauso dazu. Wäre nicht das erste Mal! :cheers: