| DivX und Schwarz-Weiss-Filme
Frage von Chris Schultz:
Hallo,
ich versuche zur Zeit einige "Alte Schätzchen", also Schwarz-Weiss-Filme aus
den 40ern usw. vom Video oder (;falls mal einer wiederholt wird) von einer
DVB-S-Festplatte mit DivX in eine DVD-Player taugliche Größe von einem
80min.-CDR-Rohling zu bekommen.
Da frage ich mich zwangsläufig, wieso diese S/W-Filme nicht eigentlich in
einer deutlich kleineren Dateigröße hin zu kriegen sind als Farbfilme.
Virtual Dub zeigt mir als zulässige Farbtiefen für DivX lediglich 24 und 32
bpp an (;also 16 mio (; ) Farben), dabei sollte doch eigentlich dort der
Ansatz zu finden sein. 16 Mio Grautöne sind doch wohl ein wenig viel :-)
Hat das mal einer gemacht oder sich das auch gefragt und ggf. einen Tip/Hint
für mich? Oder passen S/W auch nur etwa 1h40 in brauchbarer DivX-Qualität
auf eine CDR?
Danke
Chris
Antwort von Volker Schauff:
Chris Schultz wrote:
> Da frage ich mich zwangsläufig, wieso diese S/W-Filme nicht eigentlich in
> einer deutlich kleineren Dateigröße hin zu kriegen sind als Farbfilme.
> Virtual Dub zeigt mir als zulässige Farbtiefen für DivX lediglich 24 und 32
> bpp an (;also 16 mio (; ) Farben), dabei sollte doch eigentlich dort der
> Ansatz zu finden sein. 16 Mio Grautöne sind doch wohl ein wenig viel :-)
Moment, arbeitet DivX nicht im YUV-Farbraum? (;nicht an dich sondern an
die Allgemeinheit gerichtet)
Wenn ja wirst du dich über folgendes freuen können:
YUV bedeutet: Y - die Helligkeit und U/V die Farbdifferenzen. Ist das
Bild wirklich exakt S/W und nicht leicht Sepia (;z.B. neu abgetasteter
Monochrom-Film) oder mit leichtem Farbrauschen oder leichten
Farbanteilen durch einen verstellten Eingang (;im Zweifelsfall einfach
per Filter noch das letzte bischen Farbe entfernen) dann tritt folgender
Fall ein:
Komprimier mal ein Einzelbild (;ruhig Farbe) als JPG. Einmal original,
einmal stark kontrastreduziert und dunkel (;statt Helligkeiten von 0-100%
nur noch 0-50%) und einmal kontrastreduziert und hell (;mit Helligkeiten
von 50-100%). Geht alles gut dürften das zu helle und das zu dunkle
kontrastarme etwa gleichgroß und deutlich kleiner sein als das
originale. Warum? Bevor man verlustbehaftet an die eigentliche
Kompression rangeht kontrolliert man erst mal die Vielfachheit der
Farben darauf ob man die Bits so remappen kann, daß man die im Bild
vorkommenden Farben auch mit weniger Bits speichern kann weil z.B.
einige Farben/Helligkeitsgrade garnicht vorkommen. Einfaches Beispiel:
Ein Bild das nur gerade Helligkeitsgrade enthält (;also 0, 2, 4, 6, 8,
... 254) braucht keine 8 Bit, man stellt einfach in einer Tabelle fest
00, 21, 42, ... und kommt so mit nur der Hälfte der Bits aus.
Was bedeutet das in deinem Fall? Wenn DivX RGB arbeitet hast du
verloren, denn R, G und B sind bei S/W gleich und haben die gleiche
Vielfachheit, nämlich im Regelfall "volle Möhre". Arbeitet DivX in YUV
hast du bei Y volle Vielfachheit, bei U und V jedoch keinerlei
Abweichungen, es reicht ein Bit um die U und V Differenzen darstellen zu
können (;eigentlich reichen 0 Bit aber soweit wird der Codec nicht
gehen). Das heißt, daß weniger auf die Komprimierung von U und V
verschwendet werden muß da es ohnehin schon verschwindend gering
vorhanden ist -> Der Codec beschäftigt sich quasi nur noch mit den 8 Bit
Y-Anteil.
Ach ja und 16,7 Mio Grauwerte wirst du nie kriegen, entweder du hast bei
YUV ein 8 Bit Helligkeitssignal oder du hast bei RGB jeweils R, G und B
die gleichgroß sind und somit Grau ergeben, also auch nur 256
Graustufen, alles was von RG=B abweicht und die Anzahl der Farben
erhöht ist kein Reingrau mehr.
--
Gruß... Volker Schauff (;thunderbird.elite@t-online.de, ICQ 22823502)
www.cavalry-command.de - Über Saber Rider und andere 80er Jahre Serien
foren.cavalry-command.de - Forum für Spät70er - Früh-90er TV-Nostalgiker
www.dark-realms.de - Für Fantasy/Mittelalter und alles mögliche Kreative
Antwort von Heiko Nocon:
Chris Schultz wrote:
>Da frage ich mich zwangsläufig, wieso diese S/W-Filme nicht eigentlich in
>einer deutlich kleineren Dateigröße hin zu kriegen sind als Farbfilme.
Sind sie doch. So ungefähr 75%..80% der Dateigröße lassen sich bei
gleicher subjektiver Qualität erreichen. Das gilt aber natürlich nur
dann, wenn die Qualität der Vorlage in etwa vergleichbar ist. Alte
SW-Filme zeichnen sich aber nun nicht gerade durch hohe Rauschfreiheit
aus, so daß hier sogar mit deutlich höherem Platzbedarf gerechnet werden
muß als mit neuzeitlichen Farbmaterial von einer guten Quelle.
>Virtual Dub zeigt mir als zulässige Farbtiefen für DivX lediglich 24 und 32
>bpp an (;also 16 mio (; ) Farben), dabei sollte doch eigentlich dort der
>Ansatz zu finden sein.
Nein. Diese Einstellung ist (;selbst wenn z.B. ein 8-Bit-Modus für 256
Graustufen auswählbar wäre) für die Dateigröße und Bildqualität ziemlich
irrelevant. Allenfalls könnte der Codec Rechenzeit sparen, wenn er von
vornherein wüßte, daß er da SW-Material bearbeitet. So muß er sich zu
dieser Erkenntnis erst selbst durchrechnen.
>ggf. einen Tip/Hint
>für mich?
Informiere dich, wie MPEG-Kompression eigentlich funktioniert. Dann
klären sich diese scheinbar unlogischen Sachen von ganz alleine auf.
>Oder passen S/W auch nur etwa 1h40 in brauchbarer DivX-Qualität
>auf eine CDR?
Genau so ist das. Wobei "brauchbar" natürlich ein ziemlich dehnbarer
Begriff ist.
Antwort von Ralf Fontana:
Volker Schauff schrieb:
>{...]
>Ach ja und 16,7 Mio Grauwerte wirst du nie kriegen, entweder du hast bei
>YUV ein 8 Bit Helligkeitssignal oder du hast bei RGB jeweils R, G und B
>die gleichgroß sind [...]
Woraus ergeben sich die exact 8 Bit Helligkeitssignal? Ist das nicht
vom A/D-Wandler bestimmt?
--
"KACK DICH REICH"?
Was will mir Pro7 sagen?
Antwort von Volker Schauff:
Ralf Fontana wrote:
>>Ach ja und 16,7 Mio Grauwerte wirst du nie kriegen, entweder du hast bei
>>YUV ein 8 Bit Helligkeitssignal oder du hast bei RGB jeweils R, G und B
>>die gleichgroß sind [...]
>
> Woraus ergeben sich die exact 8 Bit Helligkeitssignal? Ist das nicht
> vom A/D-Wandler bestimmt?
Na ja im Endeffekt werden die 8 Bit halt gespeichert, möglich, daß
manche Wandler mehr abtasten und dann runterrechnen. Aber die Codecs
haben meist 8 Bit. Außerdem haben viele YUV-Codecs ja noch Headroom und
schwarz beginnt nicht bei 0 sondern bei 16 und Weiß endet nicht bei 255
sondern schon bei 239 und all sowas. Aber ich fand die Ausführung schon
erschreckend ausführlich genug, als daß ich auch noch mit solchen
Details kommen wollte
--
Gruß... Volker Schauff (;thunderbird.elite@t-online.de, ICQ 22823502)
www.cavalry-command.de - Über Saber Rider und andere 80er Jahre Serien
foren.cavalry-command.de - Forum für Spät70er - Früh-90er TV-Nostalgiker
www.dark-realms.de - Für Fantasy/Mittelalter und alles mögliche Kreative
Antwort von Matthias Wieser:
Volker Schauff wrote:
> Einfaches Beispiel:
> Ein Bild das nur gerade Helligkeitsgrade enthält (;also 0, 2, 4, 6, 8,
> ... 254) braucht keine 8 Bit, man stellt einfach in einer Tabelle fest
> 00, 21, 42, ... und kommt so mit nur der Hälfte der Bits aus.
Nicht die Hälfte, sondern nur ein Bit weniger, oder nicht?
Viele Grüße,
Matthias
Antwort von Volker Schauff:
Matthias Wieser wrote:
>>Einfaches Beispiel:
>>Ein Bild das nur gerade Helligkeitsgrade enthält (;also 0, 2, 4, 6, 8,
>>... 254) braucht keine 8 Bit, man stellt einfach in einer Tabelle fest
>>00, 21, 42, ... und kommt so mit nur der Hälfte der Bits aus.
>
> Nicht die Hälfte, sondern nur ein Bit weniger, oder nicht?
Stimmt.
Es war spät und ich brauchte den Schlaf ;-)
--
Gruß... Volker Schauff (;thunderbird.elite@t-online.de, ICQ 22823502)
www.cavalry-command.de - Über Saber Rider und andere 80er Jahre Serien
foren.cavalry-command.de - Forum für Spät70er - Früh-90er TV-Nostalgiker
www.dark-realms.de - Für Fantasy/Mittelalter und alles mögliche Kreative
Antwort von Tor-Einar Jarnbjo:
Volker Schauff wrote in
> Na ja im Endeffekt werden die 8 Bit halt gespeichert, möglich, daß
> manche Wandler mehr abtasten und dann runterrechnen. Aber die Codecs
> haben meist 8 Bit.
Nun kenne ich MPEG4 nicht so genau, aber der Codec wird sich nicht von
anderen Video-Codecs so weit unterscheiden, dass es Sinn ergibt von einer X
Bit Farbtiefe zu sprechen. Intern arbeitet der Codec wahrscheinlich mit
Fließkommazahlen und nach der inversen Cosinus-Transformation wird einfach
auf 8 Bit umgerechnet, weil es so von der Grafikhardware gewollt ist.
Gruß, Tor
Antwort von Udo Wolter:
On 2004/11/07 20:30 you (;thunderbird.elite@t-online.de) transmitted structured data:
>> Da frage ich mich zwangsläufig, wieso diese S/W-Filme nicht eigentlich in
>> einer deutlich kleineren Dateigröße hin zu kriegen sind als Farbfilme.
>> Virtual Dub zeigt mir als zulässige Farbtiefen für DivX lediglich 24 und 32
>> bpp an (;also 16 mio (; ) Farben), dabei sollte doch eigentlich dort der
>> Ansatz zu finden sein. 16 Mio Grautöne sind doch wohl ein wenig viel :-)
>
> Moment, arbeitet DivX nicht im YUV-Farbraum? (;nicht an dich sondern an
> die Allgemeinheit gerichtet)
Ich benutze zwar xvid und nicht divx, aber das sollte identisch sein,
was die Farbraum-Nutzung betrifft. Ich benutze transcode, ein
transcoding-Programm, bei dem ich zwischen YUV und RGB wählen kann.
Ich muß sagen, bei Farb-Filmen ziehe ich definitiv RGB vor, YUV
wird später auf dem TV etwas blaß, da der Codec scheinbar versucht,
hier möglichst viel rauszuholen. Bei S/W-Filmen dagegen kann man
mit dem Farbraum YUV tatsächlich bei gleicher Qualität fast 30-50%
rausholen, WENN denn das Bildmaterial dazu geeignet ist. Laurel & Hardy
z.B. sind in relativ guter Qualität, aber schon ein paar Jahre voraus
sind die Chaplin-(;Stummfilm)-Filme so grottig, daß ich einfach mehr
KB/s rauflegen muß. Und das ist nicht nur ein alter/neuer Film-Phänomen.
Es gibt S/W-Produktionen aus den 60ern, die so viel kleine Fehler
im Film haben wie die Chaplin-Sachen. Das liegt vor allem am
Aufnahmematerial und wie es gelagert wurde. Bei vielen Filmen
kommen analoge Flimmereien, die durch Abplatzen des Filmmaterials
auf der Rolle entstanden sind. Sowas durch einen Kodierer zu jagen,
ist grauenhaft und oft sinnlos, da muß man erst filtern wie verrückt
und nachher hat man ein matschiges Bild, das VHS alle Ehre machen
würde.
Die Antwort lautet also wie so oft: it depends. Bei gutem Filmmaterial
sparst Du mit S/W (;kann man mal ausprobieren, wenn man mal Farb-DVDs
nimmt und sie als S/W-Filme runtercodiert, da spart man irre viel),
sobald das Material fleckiger wird, kann man es vergessen.
Mermgfurt,
Udo
--
Udo Wolter | /"
email: uwp@dicke-aersche.de | / ASCII RIBBON CAMPAIGN
www: www.dicke-aersche.de | X AGAINST HTML MAIL
dark: heaven@lutz-ziffer.de | /
Antwort von Ottfried Schmidt:
Udo Wolter wrote:
>Ich benutze zwar xvid und nicht divx, aber das sollte identisch sein,
>was die Farbraum-Nutzung betrifft. Ich benutze transcode, ein
>transcoding-Programm, bei dem ich zwischen YUV und RGB wählen kann.
Das betrifft dann aber höchstens den Source, bzw. wie er gelesen wird,
denn ALLE MPEG-Formate - also auch DivX & Co - encoden grundsätzlich
in YV12.
Und wenn Dir die Einstellung YUV zu blaß erscheint, dann wette ich um
'nen Kasten Bier, dass Du dann bei YUV immer mit falscher Lumarange
encodest.
Antwort von Udo Wolter:
On 2004/11/08 13:48 you (;b racer@gmx.de) transmitted structured data:
> Und wenn Dir die Einstellung YUV zu blaß erscheint, dann wette ich um
> 'nen Kasten Bier, dass Du dann bei YUV immer mit falscher Lumarange
> encodest.
Und hier ist mein Latein am Ende: wo kann ich sowas einstellen ? Gibt's
dafür auch noch andere Worte oder Definitionen ?
Mermgfurt,
Udo
--
Udo Wolter | /"
email: uwp@dicke-aersche.de | / ASCII RIBBON CAMPAIGN
www: www.dicke-aersche.de | X AGAINST HTML MAIL
dark: heaven@lutz-ziffer.de | /
Antwort von Ottfried Schmidt:
Udo Wolter wrote:
>Und hier ist mein Latein am Ende: wo kann ich sowas einstellen ? Gibt's
>dafür auch noch andere Worte oder Definitionen ?
Puh, Transcode ist ja für Linux, und mit Linux kenn' ich mich nicht
aus. Somit kenne ich auch das Programm nicht.
Auf die Schnelle konnte ich da jetzt auch nichts über YCbCr / CCIR 601
finden, auch nicht über Lumarange (;16-235 / 0-255). Nur diesen Link
hier, der darauf hin deutet, das transcaode damit nicht umgehen kann
(;also für manche Anwendungen Schrott ist):
http://itdp.fh-biergarten.de/~itdp/html/transcode-users/2004-06/msg00099.html
Aber das hier sieht doch gut es (;für S/W):
-K enable b/w mode [off]
Aber diese Angaben erfolgen ohne Gewähr, das muss jemand verifizieren,
der sich voll mit transcode auskennt.
Antwort von Udo Wolter:
On 2004/11/08 15:44 you (;b racer@gmx.de) transmitted structured data:
> Aber das hier sieht doch gut es (;für S/W):
> -K enable b/w mode [off]
Ja, das Flag kenne ich.
> Aber diese Angaben erfolgen ohne Gewähr, das muss jemand verifizieren,
> der sich voll mit transcode auskennt.
Ok, trotzdem Danke, ich denke, dafür wird es einen import/export-Filter geben.
Ich frage mal im transcode-Forum weiter.
Mermgfurt,
Udo
--
Udo Wolter | /"
email: uwp@dicke-aersche.de | / ASCII RIBBON CAMPAIGN
www: www.dicke-aersche.de | X AGAINST HTML MAIL
dark: heaven@lutz-ziffer.de | /
Antwort von Ottfried Schmidt:
Udo Wolter wrote:
>Ja, das Flag kenne ich.
Laut Beschreibung ist es am sinnvollsten, es im YUV-Modus zu nutzen,
da dann eventuelle Farb-Fehler erst gar nicht ins resultierende
S/W-Bild mit eingehen.
Ist halt die Frage, was ein Decoder in den jeweiligen Modi liefert:
16-235 oder 0-255.
Nach der reinen Lehre sollte YUV immer nur in 16-235 vorliegen, RGB
immer mit 0-255 - leider ist das im wirklichen Leben aber nicht so. Da
gibt's Codecs/Decoder, die trotz RGB 16-235 liefern, und den
umgekehrten Fall gibt's auch. Deshalb sollte ja eine guter Encoder
eine Möglichkeit haben, das diesbezügliche Verhalten anpassen zu
können. Denn der qualitative Overkill ist es, wenn ein Video, das
bereits die Range von 16-235 hat nochmals einer Range-Komprimierung
unterzogen wird. Bei 32-219 sieht kein Video mehr wirklich gut aus...
(;wird blaß und kontrastarm). Umgekehrt, wenn ein Video, das 0-255 hat,
nicht in der Range komprimiert wird, ist's genauso schlimm. Dann wird
das Bild viel zu dunkel, der Kontrast viel zu hoch (;Stichworte
Superwhite und Superblack).
>Ich frage mal im transcode-Forum weiter.
Gute Idee, wenn die's nicht wissen, wer sonst? ;)
Antwort von Andre Beck:
Udo Wolter writes:
> On 2004/11/08 13:48 you (;b racer@gmx.de) transmitted structured data:
>> Und wenn Dir die Einstellung YUV zu blaß erscheint, dann wette ich um
>> 'nen Kasten Bier, dass Du dann bei YUV immer mit falscher Lumarange
>> encodest.
>
> Und hier ist mein Latein am Ende: wo kann ich sowas einstellen ?
In jeder ordentlichen Toolchain, in der potentiell ein derartiger
Fehler auftreten könnte, sollte es dafür Schalter geben. Ich verwende
für MPEG2 Encoding unter Linux lieber mpeg2enc (;mjpegtools), dort
kommt zum Füttern des Encoders das Format YUV4MPEG2 zum Einsatz.
Die Manpage sagt:
NOTES ON IMAGE DATA
Currently only planar, 4:2:0-subsampled CCIR-601, Y'CbCr image data is
supported.
Anders gesagt, mpeg2enc will *immer* mit CCIR.601-konform eingeschränktem
Material gefüttert werden und ändert an den YUV-Ranges gar nichts.
Bei yuvcorrect(;1) finden sich dann Optionen wie:
-Y for keyword concerning color corrections in the yuv space
Possible yuv keywords are:
[...]
CONFORM to have yuvcorrect generate frames conform to the
Rec.601 specification for Y'CbCr frames that is
LUMINANCE 1.0 16 235 16 235 and
CHROMINANCE 0.0 1.0 128 1.0 128 16 240
um Material mit full range YUV auf die CCIR.601-Range zu komprimieren.
Der Schritt ist natürlich nur nötig, wenn das Quellmaterial nicht
bereits (;weitgehend) in der CCIR.601-Range liegt, was bei DV, MJPEG
und MPEG als Urquelle sehr wahrscheinlich ist, nicht aber wenn das
Zeug vorher mal RGB war.
> Gibt's dafür auch noch andere Worte oder Definitionen ?
CCIR 601 legt das fest. Siehe auch die diesbezügliche Diskussion letztens
hierzugruppe.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
| |
