DCP erstellen...

[oceanic]

Ob man aus dem normgemäßen DCI-Testfilm ggfs. die 'richtigen' Parameter reverse-engineeren kann? Irgendwann hatte ich mir sowas mal runtergeladen, jetzt scheint es das Ding nur noch gegen Kohle auf Datenträgern zu geben. Man könnte natürlich auch irgendein anderes DCP aus 'offiziellen' Quellen nehmen.

 

 

- Carsten

 

Also wir könnten ggf. ein Kalibrierungsfilm zur Verfügung stellen.

Das sind allerdings doch recht satte Datenmengen....

 

Macht euch, wenn ihr das wollt und keine Server im Web habt, doch mal einen kostenlosen Account bei mydrive.ch, da kriegt ihr 2GB.

 

Da können wir gerne mal paar 30bit Kalibrierungssequenzen hochladen. Und auch böses *FOLTERMATERIAL* für Datenratenmessung, mit dem man selbst 250Mbit DCI zerquält bekommt :)

 

Finden es hier alle toll was Reptile angestossen (und möglich gemacht) hat.

[carstenk]

Kann man sicherlich etwas streamlinen - da es ja ein intraframe codec ist, reicht ja schon ein einzelnes Bild. Rauschen ist ja traditionell problematisch für diese Codecs. Aber natürlich wäre ein bißchen real-life footage schöner.

 

Vielleicht kann man die Programmierer des J2C codecs auch mal daraufhin anhauen, die werden sicher eher mit den Parametrisierungen der DCI spec was anfangen können.

 

Solange man nur 'für den eigenen Server' kodiert, ist das ja noch kein Problem, kann man ja alles testen, aber wenn man dann womöglich mal was verbreitet aus einer echten FullHD Quelle und beim einen oder anderen Server wird dann der Decoder überfahren und steigt aus...

 

Ich bin ziemlich sicher, dass die Server sich nicht strikt auf die DCI-Toleranzen festlegen lassen. Sprich, beim einen mag ne höhere Datenrate kein Problem sein, beim anderen mag es aussetzen sobald man deutlich über 30MByte/s geht.

 

Allein das wäre ja mal lustig auszutesten mit ein paar abgestuften Testsequenzen, die man rumschickt und auf die verschiedenen Server lädt. Soviele verschiedene Server gibts ja glücklicherweise nicht.

 

Jetzt noch ne Scarlet, ein FinalCut-System (mit Bootcamp Windows ;-)...

 

 

- Carsten

[oceanic]

 

Allein das wäre ja mal lustig auszutesten mit ein paar abgestuften Testsequenzen, die man rumschickt und auf die verschiedenen Server lädt. Soviele verschiedene Server gibts ja glücklicherweise nicht.

Wie gesagt, wir stellen gern paar GBs 4K realbild, 2K realbild und testsequenzen zur Verfügung, wenn ihr FTP/mydrive usw Platz habt.

 

Jetzt noch ne Scarlet, ein FinalCut-System (mit Bootcamp Windows ;-)...

- Carsten

So ironisch es ist, aber für 2/3/4K Redcode ist tatsächlich Adobe CS4 und CS5 besser als FCP... weil CS4 komplett nativ Redcode RAW spielt, ohne L&T, proxy usw - in 16bit 4K und CD5 obendrein noch die GPU debayern läßt. Die Mercuryengine in CS5 (ist seit einiger Zeit im Betatest) ist sowieso recht abgefahren was die Leistung anbetrifft....

 

man schaue (und staune) hier. 4K, red und das Kinospezisfische ist am Ende des Vortrags

http://blogs.adobe.com/davtechtable/

[REPTILE]

also FTP ist kein problem, da habe ich unlimited :)

 

 

@carstenk:

 

Zur kompression, da gibs viel viel an optionen... man kann z.b. jeden layer mit einer anderen komprimierungsstufe komprimieren etc...

aber ich denke das wäre zu viele optionen für die meisten...

 

 

und da andere komprimierungs optionen einzustellen, ist ja echt das geringste :) von daher...

[oceanic]

also FTP ist kein problem, da habe ich unlimited :)

Fein, da senden wir die heute oder morgen mal paar Leckerlis. Na denn mal her mit dem FTP (per PM)...

 

 

und da andere komprimierungs optionen einzustellen, ist ja echt das geringste :) von daher...

Yep, was eher herrausfordernd wäre: Key und (3D-)LUTs für die YUV->XYZ.

 

Aber LUTs, 2 wie 3D, sind für DCI nicht mehr soooo wichtig wie einst bei Filmscans.

[REPTILE]

mhh in was liegen denn dann die bilder von wenn man DPX material hat....

 

ist das typischerweise dann YUV Farbraum oder schon XYZ ?

 

 

ftp lege ich später dann an, muss erstmal noch andere sachen machen, da kommt man ja zu garnix mehr :D

[oceanic]

mhh in was liegen denn dann die bilder von wenn man DPX material hat....

 

ist das typischerweise dann YUV Farbraum oder schon XYZ ?

RGB, wie die Mehrzahl der heutigen Kinomaster, und ob RGBlin oder RGBlog kannst du frei wählen.

 

ftp lege ich später dann an, muss erstmal noch andere sachen machen, da kommt man ja zu garnix mehr :D

:)

Kein Stress, keine Eile, wir wollen nur unterstützen.

Stereoskopische 3D Sequenzen können wir, das am Rande, natürlich auch liefern.

[carstenk]

und da andere komprimierungs optionen einzustellen, ist ja echt das geringste :) von daher...

 

Ja, das entscheidende ist halt, die richtigen einzustellen, und eben ggfs. ein Monitoring der Datenrate zu machen.

 

Im Prinzip müsste man die Größe jedes Frames auf die von mir zitierten Werte aus der DCI spec checken und notfalls die Parameter dynamisch anpassen. Sicher nicht unmöglich, da die Bilder ja alle einzeln verarbeitet werden. Ein bißchen Luft ist da sicher drin, allzu präzise muss das sicher nicht eingehalten werden. Gegenwärtig kann man das ja notfalls durch einen nachfolgenden directory-check der J2Cs machen - der gestern von mir ausgepackte Werbetrailer schwankt z.B. zwischen 1100 und 600KByte pro Frame in den Realfilmanteilen - liegt also in den Spitzenwerten schon ziemlich nah an den 1,302,083 bytes per frame - obwohl das eigentlich ziemlich softes hochgerechnetes Video zu sein scheint.

 

 

J2C Verzeichnis nach Größe sortieren, und wenn es da deutlich zu hoch wird, nochmal neu mit anderen Parametern. Von daher wäre es sinnvoll, wenn Du an irgendeiner Stelle einen Zugriff auf die Kompresionsparameter erlaubst, und wenn es vorläufig nur durch unmittelbaren Zugriff auf die cmdline parameter per ini-file o.ä. ist.

 

 

- Carsten

[Pudding]

hat jemand die DCPs auf einem G3 laufen?

Meiner erkennt die nicht, und bietet nix zum ingest an.

Die Doremis fressen es aber ohne Probleme.

Soweit ich weiss, ist der G3 empfindlicher, wenn eine Größe oder ein Name, auf den verwiesen wird, nicht hundertprozentig stimmt.

Doremis sind da etwas schmerzfreier.

[REPTILE]

ich habe gerade ne neue version hochgeladen, die etwas an den filename bzw im assetmap ändert... da hatte ich weng schmarrn drin...

[Gast T-J]

Meiner erkennt die nicht, und bietet nix zum ingest an.

 

Brauchst Du dazu nicht ein Zusatzprogramm, damit der Apfel das Dateiformat erkennt?

[REPTILE]

ich glaub eher das er den XDC G3 Server meint... :)

[Gast T-J]

... das er den XDC G3 Server meint ...

 

Herrje, warum können Hersteller ihren Produkten keine unikaten Namen geben? Hätte ja auch ein G3 von H&K sein können. :shock:

[Jensg]

Was'n das für'n Amp von Hughes&Kettner?. Dachte, wir sind im Film :wink:

Jens

[REPTILE]

wo waren wir denn stehen geblieben... ach ja farbraum..

 

also aktuell verwende ich folgende matrix zum sRGB -> XYZ konvertieren..

 

0.4124564 0.3575761 0.1804375

0.2126729 0.7151522 0.0721750

0.0193339 0.1191920 0.9503041

 

vorher gamma auf 0.454545 und nach der umrechnung gamma auf 2.6

 

wie oben zu sehen nehme ich sRGB als grundlage für den ausgangsfarbraum, referenz weiß D65

[REPTILE]

 

Im Prinzip müsste man die Größe jedes Frames auf die von mir zitierten Werte aus der DCI spec checken und notfalls die Parameter dynamisch anpassen. Sicher nicht unmöglich, da die Bilder ja alle einzeln verarbeitet werden. Ein bißchen Luft ist da sicher drin, allzu präzise muss das sicher nicht eingehalten werden. Gegenwärtig kann man das ja notfalls durch einen nachfolgenden directory-check der J2Cs machen - der gestern von mir ausgepackte Werbetrailer schwankt z.B. zwischen 1100 und 600KByte pro Frame in den Realfilmanteilen - liegt also in den Spitzenwerten schon ziemlich nah an den 1,302,083 bytes per frame - obwohl das eigentlich ziemlich softes hochgerechnetes Video zu sein scheint.

 

mhh ich kann mir ehrlich gesagt nicht vorstellen das das so gemastert wird, also jedes bild checken und die komprimierungsrate anpassen....

ich glaub da werden alle bilder mit einer kompressionsstufe durchgerechnet... man kann glaub ich auch beim fertigen bild nicht mehr

herrausfinden mit welcher stufe es komprimiert wurde... zumindest habe ich bisher das nicht rauslesen können....

[carstenk]

Nee, der J2C codestream enthält keinerlei separate Informationen mehr darüber, welche Parameter verwendet wurden, wobei mit Sicherheit einiges an Information dennoch aus dem Muster extrahiert werden könnte, wenn man richtig Ahnung von diesem Algorithmus hat

 

Aber das mit dem Datenratenmonitoring ist doch nicht ganz uninteressant, wenn Du mal überlegst, wie das irgendwann mal mit Material in Filmlänge und aus echten 2k Quellen aussehen würde, von 4k mal ganz abgesehen.

Du kannst nicht einfach davon ausgehen, dass das schon passt, bzw., je nach verwendeten Parametern verschenkst Du eben Qualität.

 

Schau Dir mal den thread 'DCP Größen/AVATAR' an. Da geht's um den bisher unerklärlichen Größenunterschied zwischen der deutschen/europäischen und der US/UK Version (156GByte/276GByte). Wenn es dafür keine anderen Erklärungen gibt - Ich versuche mal eine:

 

Beim europäischen Encoding hat man eine konservative Kompression gewählt, die bei konstanten Kompressionsparametern an keiner Stelle im Film die erlaubte maximale Datenrate übersteigt. Daraus ergibt sich eine mittlere Datenrate von 16MByte/s bzw. 670kByte/3Dframe. An einigen Stellen im Film können die erlaubten 30Mbyte/s durchaus erreicht worden sein. Der größte Teil des Films liegt aber deutlich darunter.

 

Die US Version erreicht konstante 28Mbyte/s - das heisst aber, sie kann in keinem Bereich wesentlich höher oder niedriger als 1180KByte/3Dframe liegen. Das geht über 162min Realfilm, egal wie hoch der CG Anteil da ist, nur, wenn man JEDES Bild optimal auf eine Zieldatenrate komprimiert. Anders lässt sich eine mittlere Datenrate so dicht unter dem erlaubten Maximalwert nicht realisieren.

 

Das wäre jedenfalls mal meine Vermutung. Mag sein, dass professionelle Software dafür eine zeitsparende Prädiktionsfunktion hat, im anderen Falle müsste der Kompressor sich ggfs. durch Mehrfachkompression an die richtigen Parameter rantasten. Also im Prinzip hat man bei der US/UK Version eine ConstantBitrate Kompression durchgeführt, und bei der europäischen eine VariableBitrate Kompression. Da JPEG2000 das als intraframe Kompression nicht direkt unterstützt, muss man das eben durch externes Monitoring und ggfs. Rekompression machen.

 

Für allgemeine Anwendungen scheint das ein sehr hoher Zeitaufwand zu sein, aber für eine Produktion wie AVATAR und mit den dafür verfügbaren Tools ist sowas natürlich kein Kriterium.

 

- Carsten

[carstenk]

Hmm, also wenn dein Tool immer noch

 

image_to_j2k.exe verwendet, was auf OpenJPEG basiert, und wenn man hier:

 

http://www.openjpeg.org/index.php?menu=doc

 

Mal nach unten scrollt und bei den Cinema2K/4K profiles liest, dann garantiert zumindest dieser JPEG2000 Encoder mit diesen settings, dass die zulässige Datenrate nicht überschritten wird. Wie auch immer er das macht. Also wohl kein Problem.

 

 

- Carsten

[REPTILE]

Hmm, also wenn dein Tool immer noch

 

image_to_j2k.exe verwendet, was auf OpenJPEG basiert, und wenn man hier:

 

http://www.openjpeg.org/index.php?menu=doc

 

Mal nach unten scrollt und bei den Cinema2K/4K profiles liest, dann garantiert zumindest dieser JPEG2000 Encoder mit diesen settings, dass die zulässige Datenrate nicht überschritten wird. Wie auch immer er das macht. Also wohl kein Problem.

 

 

- Carsten

 

jup das ganze basiert auf der openjpeg lib in der aktuellen version, als parameter die cinema profile....

 

jo mit der avatar theorie, das ist schon einleuchtend, da man damit die max quali in jeden bild rausholen kann.... aber ob das gemacht wird.. mhh.... ist ja auch ne frage von konstantheit... also ob man das nicht im laufenden film merkt die qualitäts unterschiede....

[REPTILE]

ne ne kleine anmerkung, zum "avatar, größen thread" weil du sagstest das im vergleich zu den anderen filmen avatar ne "normale" größe hat... oehm die anderen sind teilweise aber 2D, und bei 3D hat man im prinzip aufjedenfall das doppelte an Bild daten, da ja jedes bild doppelt da ist, repektive 48fps.... somit ist die größe eigendlich nicht normal....

[carstenk]

Nee, die DCI spec sagt ja, dass bei 3D jedes Bild nur noch halb so groß sein darf wie bei 2D. Die Qualität geht also auch etwas runter.

Bei 2D knapp 1.3MByte/frame, bei 3D 650KByte/frame.

 

 

Hier aus der Doku zu OpenJPEG2000:

 

* Maximum Bit rate for entire frame = 1302083 bytes for 24 fps, 651041 bytes for 48fps

 

Du hast also die gleiche Datenrate wie bei 2D. Und gerade vor diesem Hintergrund ist es eben merkwürdig, dass unsere AVATAR Version dann soviel kleiner ist als die US. Aber im Vergleich zu den anderen genannten 3D Filmen scheint es von der Länge her dann eher normal zu sein.

 

Man darf also für 3D auf keinen Fall zwei 'normale' 2D Codestreams erzeugen und dann interleaven, die müssen auf jeden Fall mit der Option 'Cinema2k 48' erzeugt werden, sonst hast Du die doppelte Datenrate. Hast Du das bei der Dual-Prozessorvariante so gemacht?

 

Wenn Du von Oceanic mal Testmaterial kriegst, kannst Du ja mal schauen, was für Datenraten das liefert.

 

Ich denke im Übrigen schon, dass es kein Problem wäre, für jedes Bild einen optimalen Parametersatz zu verwenden. Innerhalb einer Sequenz unterscheiden sich die Signalkomponenten ja nicht großartig voneinander. Nur bei sehr schnellen Bildänderungen würden die Kompressionsparameter also drastisch wechseln. Und da wechselt ja auch unser Auge seinen 'Blick' ohnehin massiv. Und obendrein liegen die Kompressionsartfekate bei JPEG2000 und diesen Kompressionsraten ja ohnehin noch deutlich unter der Wahrnehmungsschwelle.

Und wenn sowas bei extremeren Anforderungen deutlich sichtbarer wäre, müsste man es halt glätten, die Parameteränderungen also fließend gestalten.

 

Bei hochwertiger MPEG2 Konvertierung für DVD ist das ja auch durchaus kritisch, da werden auch szenenbasiert die Kompressionsparameter angepasst. Pro Bild geht da natürlich nicht mehr, weil es ja auch ein interframe codec ist.

 

image_to_j2k kennt aber auch nunmal immer 'nur' das aktuelle Bild und weiss nichts vom vorhergehenden oder folgenden, von daher müsste man sowas eben extern nachrüsten. Muss mal ein bißchen mehr damit rumspielen um zu sehen, was da passiert mit den Datenraten.

 

Grundsätzlich ist JPEG2000 ja so aufgebaut, dass man nicht erst einen kompletten Kompressionsvorgang abwarten muss um die resultierende Datenmenge durch Neukompression variieren zu können. Der zeitaufwendige Teil ist ja die Wavelet-Transformation. Erst danach findet durch geeignete Wahl der Parameter die Entscheidung statt, was weggelassen wird. Und offensichtlich macht image_to_J2k das eben dort.

Ausserdem hat JPEG2000 im Unterschied zu JPEG auch eine Möglichkeit, direkt einen Kompressionsgrad vorzugeben, mit der '-r' Option ('Each value is a factor of compression, thus 20 means 20 times compressed.')

Bei normalen JPEG gibt es nur einen etwas abstrakten Qualitätsparameter, der aber keine Zieldatenrate garantiert.

 

 

- Carsten

[Pudding]

ich habe gerade ne neue version hochgeladen, die etwas an den filename bzw im assetmap ändert... da hatte ich weng schmarrn drin...

 

Da hab ich nun bei 2D Still picture eine leere mxf, cpl und pkl.

[REPTILE]

hmpf... probier mal ohne xyz... wenn das geht... dann bau ich heute abend mal weng um... das ist dann immer das imagemagick das zickt....

wollte es ja vereinfachen daher habe ich ja die convert.exe mit ins tools verzeichniss... aber mhh da mag bei einigen rechnern nicht...

 

da werde ich erstmal unter den einstellungen eine pfadangabe machen wo man den ort von den imagemagick installation angiebt....

 

das ist dann erstmal nen workaround bis ich das komplett ins programm integriert habe....

[Pudding]

hmpf... probier mal ohne xyz... wenn das geht... dann bau ich heute abend mal weng um... das ist dann immer das imagemagick das zickt....

wollte es ja vereinfachen daher habe ich ja die convert.exe mit ins tools verzeichniss... aber mhh da mag bei einigen rechnern nicht...

 

da werde ich erstmal unter den einstellungen eine pfadangabe machen wo man den ort von den imagemagick installation angiebt....

 

das ist dann erstmal nen workaround bis ich das komplett ins programm integriert habe....

 

das war ohne xyz.

Sowohl SMPTE als auch MXF haben beide diese leeren Dateien ausgeworfen.

die Vorgänger Version hat ja zumindest ohne XYZ gefunzt.

[REPTILE]

grumel... die vorgängerversion war 1.0.1.0 ?