DCP erstellen...

[carstenk]

@Reptile: Logfunktion einbauen, dann kann man vielleicht einfacher sehen, woran es hakt bei den div. Modulen, also Aufrück, Rückgabe, etc. in eine Datei schreiben.

 

 

- Carsten

[REPTILE]

@Reptile: Logfunktion einbauen, dann kann man vielleicht einfacher sehen, woran es hakt bei den div. Modulen, also Aufrück, Rückgabe, etc. in eine Datei schreiben.

 

 

- Carsten

 

mhh das ist eigendlich ne gute idee :D

[Pudding]

grumel... die vorgängerversion war 1.0.1.0 ?

 

Nein, die ging auch schon nicht mehr.

 

Die noch ging, war die 0.3.0. oder so ähnlich.

Habe sie leider nicht mehr zum Nachschauen.

[carstenk]

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

[REPTILE]

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... :)

[carstenk]

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

[REPTILE]

also nicht 2x avatar in ein verzeichnis :D

[carstenk]

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

[Roland]

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

[carstenk]

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

[REPTILE]

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 ?

[Roland]

Wenn ich deine ausführung richtig verstanden habe, ist es genau das was ich meine.

[carstenk]

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

[REPTILE]

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

[carstenk]

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

[REPTILE]

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.....

[carstenk]

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

[oceanic]

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.

[ml_2]

 

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

[REPTILE]

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....

[carstenk]

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

[REPTILE]

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... :)

[carstenk]

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

[REPTILE]

najo damit meinte ich ja lineare RGB datein.... :)

[carstenk]

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