Zum Inhalt springen

DCP erstellen...


REPTILE

Empfohlene Beiträge

Das hier habe ich grade gefunden:

 

'If you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation for better performance, and especially if the first six characters of the long file names are similar.'

 

Könnte recht schnell relevant werden, wenn man seine Verzeichnisse nicht sauber hält respektive mit mehrere Versionen arbeitet.

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das hier habe ich grade gefunden:

 

'If you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation for better performance, and especially if the first six characters of the long file names are similar.'

 

Könnte recht schnell relevant werden, wenn man seine Verzeichnisse nicht sauber hält respektive mit mehrere Versionen arbeitet.

 

 

- Carsten

 

300.000 frames wären aber schon über 3 stunden... :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das geht schneller als man glaubt wenn man mit mehreren Versionen oder Filmen arbeitet und das nicht auf mehrere Verzeichnisse verteilt.

 

Wenn Du das mit dem Log machst - pack die jeweiligen Systemzeiten vielleicht zu jedem Eintrag dazu, dann kann man auch sehr schnell ein Eindruck von der Performance einzelner Module kriegen und da vielleicht noch etwas rumtricksen. Ich vermute, dass gegenwärtig die J2K Kompression am meisten Zeit kostet? Wie sieht es mit der Farbtransformation aus?

 

Angeblich ist Graphicsmagick signifikant schneller als Imagemagick und besser an Mehrprozessorsysteme angepasst. Ließe sich wohl wahlweise einsetzen, oder?

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

naja, mit GUI verliert man da schnell die Übersicht über die Ordnerinhalte. Dann hat man womöglich noch das BMP oder TIF Zwischenprodukt im selben Verzeichnis, bei 3D ist eh alles doppelt vorhanden... Wie gesagt, das geht schneller als man denkt.

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Muss man halt überlegen, wie man das mit minimalem Aufwand so hinkriegt, dass so eine Standardgeschichte halbwegs sinnvoll zu handhaben ist. Ehrlich gesagt halte ich jeden Aufwand in diese Richtung, die über ein einzelnes Bild mit wählbarer Zeit hinausgeht, für nicht sinnvoll - schlicht weil man eine Abfolge von Standbild DCPs ja mit der Playlistenverwaltung der Server wesentlich flexibler und mit kaum mehr Aufwand organisieren kann.

 

Und sobald man Ansprüche wie Überblenden und sowas hat, muss man eh ne ganz andere Software vorschalten. Ab einer gewissen Komplexität macht es eh keinen Sinn mehr, das über den Kinoserver zu machen, da muss halt ein PC an den Projektor.

 

Da würde ich eher dazu tendieren, vorhandene freie Tools für sowas als Tips mit Links in die Doku zu integrieren, als in das Softwarepaket. Das kann und soll ja kein Videoschnittprogramm oder Diashowprogramm werden, wenn ich mir mal anmaße für reptile zu sprechen. Wenn man damit anfängt, wird das ein Fass ohne Boden.

 

Wie gesagt - der Einfachheit halber würde ich eine Funktion integrieren, normale JPEGs beliebiger Auflösung mit Skalierung/Cropping zu integrieren. Aber wirklich nur um diesen Standardjob möglichst kompakt abwickeln zu können, nicht weil JPEG an sich ein sinnvolles Ausgangsformat wäre. Maximal würde ich vielleicht noch an einfaches Ein/Ausblenden denken, einfach auch weil Imagemagick das eben auch kann (denk ich...). Aber dann hörts meiner Ansicht nach auf.

 

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich fände eine Funktion das man mehrere verschiedene Standbilder in ein DCP packen könnte nicht schlecht. Max. 5 Bilder oder so.

 

Gruss

Roland

 

mhh... wie carstenk schon sagte... das problem ist da nicht die technik sondern die benutzerschnittstelle... man kann ja kaum für jedes einzelbild ne eingabestelle für die datei und dann vieleicht auch noch die zeit reinbauen.. weil du sagst jetzt 5 bilder, der andere 7 stück etc...

ABER... was ich mir gerade überlegt habe ist folgendes...

 

man könnte es so machen das man wählen kann, einmal wie bisher, ein bild angeben und gut... ODER... man gibt ein verzeichniss an in dem dann bilder liegen mit folgenden dateinamen.....

 

bild1-48.bmp

bild2-190.bmp

bild3-24.bmp

 

soll heißen... bild1....3 bildreihenfolge in dem diese gezeigt werden sollen, und bildx-4 soll bedeuten, das bild für 4 frames anzeigen.. also die zahl nach dem "-" sagt die anzahl an frames die das bild gezeigt werden soll..

 

wäre das OK ?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Genau so eine Lösung wäre ein 'vertretbarer' Aufwand, weil man nicht im GUI rumbasteln müsste. Wenn Imagemagick das kann, könnte man durch eine einfache Erweiterung der Dateibenennung eventuell auch noch Fade aus/nach Schwarz einbauen. Das könnte aber auch ein globaler Parameter im GUI sein, streng genommen müsste die Zeit nichtmal einstellbar sein, einfach eine Checkbox 'Ein/Ausblenden' fest mit 1s oder so.

 

Damit hätten die meisten DCI Vorführer alles nötige für Pausendias, einfache Ankündigungen, etc. Wer es dann aufwendiger will, muss eben externe Software bemühen.

 

'Frames' als Zeitbasis würde ich nicht nehmen. Zwar sind Vorführer gewöhnt, damit umzugehen, aber rein von der Ergnonomie und Nachvollziehbarkeit her würde ich mit Sekunden arbeiten. Unter einer Sekunde muss auch nicht operiert werden (es sei denn, man will da Pornobilder flashen ;-)

 

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Bin gerade dabei diese multi Standbild funktion einzubauen, gleichzeitig baue ich noch eine überprüfung der bildauflösung ein....

 

dann kommt das multithreading auch für 2D film hinzu und man kann wählen zwichen 2 oder 4 Threads also dual bzw quad core CPUs....

 

und die neue imagamagick behandlung kommt rein, das die operationen direkt per dll/com+ aufruf ausgeführt wird statt der convert datei, das sollte das aktuelle problem lösen....

 

ach ja und der DPX und TIF support kommt mit rein..

 

kann also etwas dauern.. :D

Link zu diesem Kommentar
Auf anderen Seiten teilen

Super...multicore support ist schon sehr edel, aber glücklicherweise bei solchen unkorrelierten Bildsequenzen ja noch recht einfach umzusetzen.

 

 

Wie solide ist denn die Farbtransformation, gibts für die Parameter verbürgte Quellen, kann man da noch was verifizieren?

 

Ich habe ein kommerziell erstelltes DCP mal 'rückkonvertiert' in RGB, die zuerst sehr grünlichen Hauttöne sehen nach der inversen Farbtransformation mit imagemagick jetzt ordentlich aus. Aber vielleicht kann man da mal Testmaterial 'vermessen'.

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

ja gute frage... man breuchte dazu zwei mal das gleiche testbild einmal in XYZ und einmal in RGB.....

 

dann könnte man das RGB in XYZ (bzw andersrum) konvertieren und mit dem echten RGB/XYZ vergleichen... anders sehe ich keine möglichkeit das zu überprüfen.....

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wenn ich das richtig sehe, dann hat ml_2 das wohl schonmal mit kommerzieller Software vor- und zurückgerechnet und verglichen.

Aber ne zweite Quelle wäre sicher kein Fehler, ausserdem müsste man das ganze sicherheitshalber auch mal komplett in 16Bit durchführen.

 

Vielleicht kann Oceanic da Testmaterial zu Verfügung stellen.

 

Hier:

 

http://www.wizards-toolkit.org/discours...87&start=0

 

Stehen etwas andere Transformationwerte drin:

 

X=0.4124240*r+0.3575790*g+0.1804640*b;

Y=0.2126560*r+0.7151580*g+0.0721856*b;

Z=0.0193324*r+0.1191930*g+0.9504440*b;

 

Hier gibts eine üppige Tabelle, D65 ist für uns ausschlaggebend:

 

http://www.brucelindbloom.com/index.htm...atrix.html

 

Die 'billigste' Methode ist natürlich wie früher in der Schule abgucken - einfach mal ein RGB Test-Bild von Fraunhofers Easy-DCP nach DCP zu konvertieren und das mit den Resultaten von Imagemagick zu vergleichen. Und dann wieder zurück und mit dem ursprünglichen RGB vergleichen. Die Fraunhofers werden schon wissen, was sie tun ;-)

 

ml_2, woher stammen deine Parameter?

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Vielleicht kann Oceanic da Testmaterial zu Verfügung stellen.

Yep, Anfang der kommenden Woche gibts Tesmaterial, auch mit im Bild integrierten numerischen & technischen Meßreferenzen.

 

Dieses Wochenende (Berlinale-Berg) ist allerdings noch Sonderschicht angesagt und Leitungen & Renderfarm glühen lustig vor sich hin, daher wirds eher mo/di/mi in einer der Nachtdispos wohl mal eine freie Suite geben.

 

Reptile, carsten... am besten wäre wohl lineares 10bit RGB, oder?

 

Log-RGB und 12/16 bit könnte ja zu einem gewissen Eigenleben in den Tools führen, zumindest wäre ich NICHT sicher das Imagemagik LUTs richtig interpretiert.

Link zu diesem Kommentar
Auf anderen Seiten teilen

 

Hier:

 

http://www.wizards-toolkit.org/discours...87&start=0

 

Stehen etwas andere Transformationwerte drin:

 

X=0.4124240*r+0.3575790*g+0.1804640*b;

Y=0.2126560*r+0.7151580*g+0.0721856*b;

Z=0.0193324*r+0.1191930*g+0.9504440*b;

 

Hier gibts eine üppige Tabelle, D65 ist für uns ausschlaggebend:

 

http://www.brucelindbloom.com/index.htm...atrix.html

 

Die 'billigste' Methode ist natürlich wie früher in der Schule abgucken - einfach mal ein RGB Test-Bild von Fraunhofers Easy-DCP nach DCP zu konvertieren und das mit den Resultaten von Imagemagick zu vergleichen. Und dann wieder zurück und mit dem ursprünglichen RGB vergleichen. Die Fraunhofers werden schon wissen, was sie tun ;-)

 

ml_2, woher stammen deine Parameter?

 

- Carsten

 

Hi,

 

meine Werte sind auch von Bruce - sRGB to XYZ (D65).

 

"Getestet" hab ich es anhand eines umgewandelten Frames, von dem ich RGB und XYZ-konvertiert schon hatte und dann optisch verglichen (PS übereinandergelegt) habe.

 

Heute habe ich einen Werbspot offensichtlich "falsch" umgerechnet und keine XYZ-Konvertierung durchgeführt - wenn man dieses Material im RGB Modus des Projektors abspielt ist das Ergebniss wie es sein soll, im "normalen" Modus bekannt rot/rosastichig.

 

lg

Link zu diesem Kommentar
Auf anderen Seiten teilen

Vielleicht kann Oceanic da Testmaterial zu Verfügung stellen.

Yep, Anfang der kommenden Woche gibts Tesmaterial, auch mit im Bild integrierten numerischen & technischen Meßreferenzen.

 

Dieses Wochenende (Berlinale-Berg) ist allerdings noch Sonderschicht angesagt und Leitungen & Renderfarm glühen lustig vor sich hin, daher wirds eher mo/di/mi in einer der Nachtdispos wohl mal eine freie Suite geben.

 

Reptile, carsten... am besten wäre wohl lineares 10bit RGB, oder?

 

Log-RGB und 12/16 bit könnte ja zu einem gewissen Eigenleben in den Tools führen, zumindest wäre ich NICHT sicher das Imagemagik LUTs richtig interpretiert.

 

Log-RGB müsste man testen, ob es damit klar kommt...

 

12/16bit sind kein problem, bis 16bit wird unterstützt....

Link zu diesem Kommentar
Auf anderen Seiten teilen

Andere Frage: Brauchen wir sowas wie Multi-Reel oder Multi-CPL Unterstützung, und wenn, wie könnte man sowas einbauen?

 

Die entsprechenden MXFs könnte man ja vom Tool problemlos partiell erzeugen lassen, aber die zusätzlichen XML Files müssten entprechend angelegt werden.

 

Momentan ist das sicher nicht wichtig, aber man kann ja mal drüber nachdenken.

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

schreibe gerade an einer Audio erkennungs routine... damit wir prüfen können ob das audio material den vorgaben entspricht...

 

0: 52 49 46 46 26 C7 FF 0B 57 41 56 45 66 6D 74 20 
   RIFF    Dateigröße-8   WAVE	   ‚fmt ‚

16: 12 00 00 00 01 00 06 00 80 BB 00 00 00 2F 0D 00 
   Header Länge PCM   Chan sample rate  bytes/sec

32: 12 00 18 00   
   blk	depth        

 

das ist der Wav header... :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

12/16bit sind kein problem, bis 16bit wird unterstützt....

 

Das ist grad nur Fischen im Trüben - in einigen Dokumenten zum DCI Mastering habe ich gelesen, dass die TIFFs im Mastering-Prozess 16Bit Format haben, aber nicht linear auf die 16Bit verteilt, sondern mit 12 belegten Bits, und die unteren 4 leer. Das kann in der Toolchain natürlich schon einen Unterschied machen. Müsste man mal durchtesten. Auf der PostPro Seite kann man davon ausgehen, dass die das schon richtig machen, aber bei 16Bit Material aus anderen Quellen, DSLRs, RAWs z.B....

 

Muss da einfach mal ein paar Testbilder machen, die Interpretationsfehler offensichtlich machen können.

 

Ah, da habe ichs, aus der DCI spec. Das bezieht sich allerdings nur auf die offiziellen Anforderungen an das DCI konforme DCDM-TIFF:

 

---

3.2.2.2.

File Mapping

The DCDM Image Structure shall be mapped into the TIFF Rev 6.0 File Format and further constrained as follows:

16 bits each per X', Y', and Z' channel, stored in the nominal TIFF R, G and B channels.

The DCDM gamma-encoded X', Y' and Z' color channels are represented by 12-bit unsigned integer code values. These 12 bits are placed into the most significant bits of 16-bit words, with the remaining 4 bits filled with zeroes.

---

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das heisst, 'unsere' Verarbeitungskette 'streched' übliche 8 Bit Daten linear auf 12Bit J2k, und 'komprimiert' 16Bit Daten linear auf 12Bit J2k (Gamma mal aussen vorgelassen)?

 

Das scheint mir gegenwärtig auch am sinnvollsten zu sein. Wer DCI konforme DCDMs mit 'soft truncation' anliefert, sollte halt wissen, was er tut. Wer auf dem Level operiert, dürfte eh alle Möglichkeiten haben.

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Filmvorführer.de mit Werbung, externen Inhalten und Cookies nutzen

  I accept

Filmvorfuehrer.de, die Forenmitglieder und Partner nutzen eingebettete Skripte und Cookies, um die Seite optimal zu gestalten und fortlaufend zu verbessern, sowie zur Ausspielung von externen Inhalten (z.B. youtube, Vimeo, Twitter,..) und Anzeigen.

Die Verarbeitungszwecke im Einzelnen sind:

  • Informationen auf einem Gerät speichern und/oder abrufen
  • Datenübermittlung an Partner, auch n Länder ausserhalb der EU (Drittstaatentransfer)
  • Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen
Durch das Klicken des „Zustimmen“-Buttons stimmen Sie der Verarbeitung der auf Ihrem Gerät bzw. Ihrer Endeinrichtung gespeicherten Daten wie z.B. persönlichen Identifikatoren oder IP-Adressen für diese Verarbeitungszwecke gem. § 25 Abs. 1 TTDSG sowie Art. 6 Abs. 1 lit. a DSGVO zu. Darüber hinaus willigen Sie gem. Art. 49 Abs. 1 DSGVO ein, dass auch Anbieter in den USA Ihre Daten verarbeiten. In diesem Fall ist es möglich, dass die übermittelten Daten durch lokale Behörden verarbeitet werden. Weiterführende Details finden Sie in unserer  Datenschutzerklärung, die am Ende jeder Seite verlinkt sind. Die Zustimmung kann jederzeit durch Löschen des entsprechenden Cookies widerrufen werden.