DCP erstellen...

[dYna]

Was willst du mir damit mitteilen?!

[carstenk]

Nix.

 

 

- Carsten

[HdGehres]

Ich habe die Bild und Tondateien aus einem DCP extrahiert.

 

Es liegen jetzt 500 Bilder .j2c vor.

 

Bei der Konvertierung mit convert gibt es allerdings Probleme. Es werden nur genau 111 Bilder konvertiert dann wird die .bat beendet weil der Physikalische Speicher voll ist.

 

Diese Konvertierung läuft auch etwas anders ab, als bei extrahieren. Dort kann man beobachten wir Bild für Bild erzeugt wird.

Beim Konvertieren passiert erst mal nix. Weder im DOS-Fenster noch im Verzeichnis. Nur im Tast-Manager sieht man, wie sich der phys. Speicher füllt.

Wenn der voll ist werden auf einen Rutsch die 111 .bmp Bilder erzeugt. Das war's dann.

 

Betriebssystem ist Windows 7. Wo liegt das Problem?

 

HdGehres

[carstenk]

Kannst Du den Batch mal hier reinpasten?

 

 

Passiert bei mir unter XP nicht. Vielleicht alte, nicht auf Win7 angepasste Version von convert, die Probleme mit dem Speichermanagement oder multithreading hat? Oder ne falsche Version von Imagemagick runtergeladen?

 

Man kann das natürlich in 5 Häppchen a 100 Bildern machen, bis Du den Grund für das Problem gefunden hast.

 

Google findet ein paar andere Schilderungen dieses Problems.

 

Andere Möglichkeit einer Lösung wäre, nicht wildcards für convert zu benutzen, sondern die Bilder der Reihe nach EINZELN per Schleifenkonstrukt an convert zu übergeben.

 

- Carsten

[HdGehres]

Kannst Du den Batch mal hier reinpasten?

 

 

Passiert bei mir unter XP nicht. Vielleicht alte, nicht auf Win7 angepasste Version von convert, die Probleme mit dem Speichermanagement oder multithreading hat? Oder ne falsche Version von Imagemagick runtergeladen?

 

Man kann das natürlich in 5 Häppchen a 100 Bildern machen, bis Du den Grund für das Problem gefunden hast.

 

Google findet ein paar andere Schilderungen dieses Problems.

 

Andere Möglichkeit einer Lösung wäre, nicht wildcards für convert zu benutzen, sondern die Bilder der Reihe nach EINZELN per Schleifenkonstrukt an convert zu übergeben.

 

- Carsten

So sieht die Batch-Datei aus, die bei 110 Bildern abbricht:

-----------------

convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic*.j2c pic.bmp

-----------------

Jetzt verwende ich den folgenden Batch. Der hat aber das Problem mit den führenden Nullen, d.h. ich muß pic00025.j2c erst in pic25.j2c umwandeln und später die BMP wieder mit führenden Nummen versehen.

-----------------

@echo off

set /a i=1

:start

if /I %i% GEQ 485 goto :next

convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic%i%.j2c pic%i%.bmp

set /a i=%i%+1

goto :start

:next

-----------------

 

HdGehres

[carstenk]

Welche Version, Linktyp, etc. von Imagemagick verwendest Du denn genau? Sind das 2k oder 4k Bilder?

 

- Carsten

[REPTILE]

Na das Batch kommt mir doch bekannt vor :D

[carstenk]

So sieht die Batch-Datei aus, die bei 110 Bildern abbricht:

-----------------

convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic*.j2c pic.bmp

 

 

Bin grad zu busy zum selber Testen, aber versuch in diesem Aufruf mal mit der option '+adjoin' das Schreiben von Einzelbildern zu forcieren und beobachte mal das Swap File. Könnte zwar sein, dass das Lesen der kompletten Sequenz davon unabhängig erfolgt, aber wer weiss, wofür es gut ist.

 

 

- Carsten

[carstenk]

Nee, klappt nicht mit +adjoin. Ich glaube, das passiert bei uns genauso mit dem SwapFile wie bei Dir - allerdings wird es bei uns nicht größer als 2.5GByte, und darf bis 4 wachsen und hat auch den Platz dafür. Also hat es bei uns scheinbar immer geklappt und ist nie jemandem aufgefallen. Möglicherweise passiert es bei höheren Bittiefen und/oder 4k auch eher.

 

Das mühsame Umbenennen kann man aber auch umgehen indem man einfach für jeden Hunderter den Aufruf einmal in einer Batchdatei startet.

 

also pic00001*.j2c

pic00002*.j2c

pic00003*.j2c

pic00004*.j2c

pic00005*.j2c

 

Muss aber irgendwie auch ne saubere Lösung dafür geben.

 

 

Hmm, sauber...?

 

http://www.imagemagick.org/script/command-line-options.php#limit

 

 

Das mit den dort erwähnten defaultmäßigen 2GB image area und 768 Files könnte erklären, warum das swapfile bei uns dann nicht weiter wächst.

 

 

 

- Carsten

[REPTILE]

Das ist aber ein ungewöhnliches verhalten...

 

Ich verwende auch batch scripts (also das von oben, kommt ja von mir) um trailer um zu wandeln und bei mir erstellt er ein bild nach dem anderen auf der

Festplatte ohne das es zu vollen Speicher kommt.

[carstenk]

Ja, aber der Batch mit der start:next Schleife ruft natürlich convert auch wirklich immer nur mit einer Bilddatei auf - da können nur die Ressourcen für ein einzelnes Bild belegt werden, von den anderen Bildern weiss Convert zum Zeitpunkt des Aufrufs ja nichts.

 

Der Aufruf convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic*.j2c pic.bmp dagegen übergibt faktisch die gesamte Bildsequenz auf einmal an convert - die wildcards * darin sind ja keine shell-funktion, sondern werden von convert selbst ausgewertet. Und offensichtlich macht convert da gerne viele Bilder auf einmal in einer Pipeline auf. Vielleicht auch, um selbsttätig multithreading auf file- bzw. Bildebene machen zu können.

 

Es gibt ja auch einige Zielformate - animated GIF z.B., die direkt Sequenzen in einer Datei aufnehmen können. Der übliche Aufruf von convert pic*.jpg pic.gif konvertiert ohne weiteres eine Reihe von Einzelbildern in ein EINZIGES Animated GIF File mit der Sequenz. Irgendwo dahinter muss sich diese Eigenart mit der Speicherverwaltung begründen lassen, die auch dazu führt, dass das Resultat nicht direkt auf Einzelbildbasis geschrieben wird.

 

Ich denke, bei HdGehres fällt das nur deswegen unangenehm auf, weil er entweder die Swapfilegröße zu knapp begrenzt hat, oder weil er auf dem Swap-Laufwerk nicht mehr genug Platz hat.

 

 

 

- Carsten

[carstenk]

Hmm, ja, ich habe grade mal die ganz aktuelle 64Bit Version von ImageMagick (16Bit component) auf einem Core i3 installiert und mal versucht, einen Trailer mit ca. 2600 frames mit dem Convert Einzeiler zu bearbeiten - da passiert das gleiche. das Swapfile wächst ins Unermessliche, irgendwann wird die Kiste extrem zäh, es gibt jpg_dec Fehler von convert, etc. pp.

 

Bei knapp über 800 frames ist Schluss, gibt dann die erwähnte Fehlermeldung 'unable to decode image file', Swapfile hat da fast 12GByte.

Die dann auf einmal geschriebenen BMP Files sind aber alle Schrott, 0 KB

 

Lustig, ich dachte, ImageMagick wird allerorten auf diese Art und Weise zum Konvertieren von ganzen Verzeichnissen mit Megapixel Digiknipsenbildern benutzt...

Läuft unter Linux vielleicht auch anders mit den Wildcards.

 

Kurzer Check mit per pic0000*.j2c auf 100 begrenzter Bildzahl reisst zwar auch die Speichernutzung deutlich hoch, läuft aber erfolgreich durch, auch hier werden die konvertierten Bilder erst alle zusammen am Schluss geschrieben.

 

Ein -limit file 10 bringt da übrigens garnix, das scheint ne andere Bedeutung zu haben. Ein -limit memory 100MiB bringt allerdings was - der Speicherbedarf beschränkt sich auf 150-200MByte. Jetzt läuft grade der ganze 2600er Stappel nochmal durch, mal sehen. Trotzdem werden keine BMPs zwischendurch ins Zielverzeichnis geschrieben. Wenn man der Imagemagick Doku glauben darf, swapt ImageMagick jetzt selbsttätig. Damit läuft die Sache also kaum schneller durch, aber ohne dass die Kiste schlapp macht. Merkwürdig. Aber das ist jetzt spätestens nichts mehr für dieses Forum...

 

- Carsten

[carstenk]

Hmm, nach ner halben Stunde fängt der große Aufruf plötzlich an, Bilder zu schreiben, eins nach dem anderen. Also scheint schon irgendwie zu gehen mit -limit, ist aber ultralangsam.

 

Nee, das muss schon mit einer Batch-Schleife laufen, ist sonst krank. Was haben die ImageMagick Leute sich bloß dabei gedacht...

 

- Carsten

[carstenk]

Okay, hier die wirklich simple Variante als Einzeiler:

 

FOR %a in (*.j2c) DO convert %a %~na.bmp

 

Das funktioniert so nur direkt auf der Kommandozeile - ruft man das in einer batchdatei auf, muss man alle % verdoppeln, also FOR %%a ...

 

Das %~na.bmp am Ende 'schneidet' die Extension des ursprünglichen Dateinamens ab, sorgt also dafür, dass ein pic001.j2c nicht zu einem pic001.j2c.bmp wird.

 

( http://www.rgagnon.com/gp/gp-0008.html )

 

Damit läuft der 2600er Stapel ohne großartige Auffälligkeiten beim Speicherbrauch durch.

 

@HdGehres: Den Rest deiner Aufrufparameter muss Du selber reinpacken. Der Unterschied zwischen einer Zählschleife, die Dateinamen entsprechend Ihrer Nummerierung hochzählt und aufruft, und der DOS-Aufrufvariante '%a', die einfach ALLE Dateien im Verzeichnis nach Auswahl aus (*.j2c) konvertiert, dürfte klar sein, oder? In aller Regel dürfte es kein Problem sein, dass so zu machen. Spart ne Menge Arbeit mit Umbenennung, weil die Nummerierungsvariante in den Dateinamen, also mit oder ohne führende Nullen, überhaupt keine Rolle spielt. Man muss halt seine Verzeichnisse sauber halten. Aber natürlich geht auch (pic*.j2c), wenn man mehrere Projekte im gleichen Verzeichnis hat.

 

- Carsten

[cindom]

tolle Zusammenstellung der benötigten Programme, Anleitung, etc. danke dafür.

 

Leider habe ich ein Problem:

 

Ich habe in Premiere eine Videosequenz erstellt und konvertiere die nun in SUPER, genau mit den Einstellungen wie im Screenshot der PDF Anleitung.

Das funktioniert soweit auch.

Danach möchte ich die entstandene Datei in VirtualDub öffen, dann kommt folgende Fehlermeldung:

 

"Coudn´t locate decompressor for format "XVID" (unknown)

VirtualDub requires a video format for Windows (VFW) compatible codec to decompress video. DirectShow codecs, such as those used by Windows Media Player, are not suitable.

 

Wäre toll wenn mir dazu jemand weiterhelfen könnte.

 

Liebe Grüße,

 

Dominik

[carstenk]

Das ist zwar nicht deine Frage, aber wenn Du aus Premiere kommst, warum exportierst Du nicht gleich von dort deine Einzelbildsequenz? Der Umweg über Super und VirtualDub ist in dem Fall vollkommen unnötig. Die DCPC Anleitung erwähnt diesen Weg nur für den Fall, dass man ein fertiges Videofile konvertieren muss. Hat man vorher schon die Wahl zu Einzelbildern, übergeht man das einfach.

 

 

- Carsten

[cindom]

Ja,

 

habe ich gemacht und läuft prima. (DCPC zeigt an der Stelle keinen Fehler)

 

Jetzt fehlt mir nur noch der Ton.

 

Wie mache ich denn am einfachsten aus einem MP3 ein .wav 24bit 48KHz ?

 

Mit GodWave? Ich habe so manchen Export ausprobiert aber wenn 24bit stimmt dann passt die KHz nicht usw.

 

Welches ist das richtige Format?

 

lg

 

Dominik

[cindom]

OK,

hab es gefunden.

 

"Batch Processing"

 

war das Zauberwort.

[carstenk]

Weiss nicht genau, was Du machst, aber das Audio kannst Du ja auch aus Premiere rausspielen. Ansonsten kann auch Audacity die Tonspuren erzeugen. Damit gehen auch relativ einfach (für ein kostenloses Tool jedenfalls) diskrete Mehrkanalfiles für Surround. Und die nötigen Format-Konvertierungen kann es auch.

 

- Carsten

[dYna]

Von diesem Dolby Countdown würde ich mir gerne ein DCP erstellen.

Bild kein Problem, aber wie kriege ich aus der Datei die, angeblich, vorhandene 5.1 Spur?

Oder hat jemand das Teil zufällig schon als DCP und kann es mir zukommen lassen?

[REPTILE]

Das gibs doch von Dolby als DCP in 3D :)

[dYna]

Muss ich da Dolby nerven, oder gibt es den und/oder andere Spots auch wo anders?

[HdGehres]

Wenn das DCP nicht verschlüsselt ist, dann geht das. Es enthält eine Video-MXF und eine Audio-MXF. Die kann man auspacken und hat dann einen Batzen J2K und eine Interleaved WAV-Datei. Die Einzelbildsequenz kann man mit üblichen Videotools wieder in übliche Computervideoformate konvertieren.

 

 

Alles was man dazu braucht ist im DCPC enthalten.

 

asdcp-test.exe -x audio.wav audio.mxf

asdcp-test.exe -x video.mxf

 

- Carsten

 

Das "Convert Problem" ist jetzt in einer Schleife aufgelöst.

 

Das neueste Problem ist nun die Einzelbild-Auflösung einer 3D.mxf.

 

Die 2D läuft mit asdcp-test.exe -x pic pic.mxf einwandfrei.

 

Bei der 3D habe ich es mit asdcp-test.exe -x pic -3 pic.mxf probiert.

 

Dann bekomme ist pic000001R.j2k und pic000001L.j2k usw. Aber die sind nur zwischen 2 kB und maximal 200 kB groß und nach dem umwandeln in bmp hat man nur eine graue Fläche.

 

Wo liegt der Fehler?

 

HdGehres

[HdGehres]

Nachtrag

 

 

Ein selbst produziertes 3D-DCP läßt sich mit dem Batch einwandfrei in korrekte ca. 600 kB große .j2k Files auflösen. Auch die daraus erzeugten .bmp sind ok.

 

Bei dem Material das nicht funktioniert, handelt es sich um einen Trailer; also auch nicht verschlüsselt.

 

HdGehres

[carstenk]

Was passiert denn, wenn du die '-3' weglässt? Soweit ich weiss braucht man die nur für den umgekehrten Weg. Nicht dass ich glaube, dass das dein Problem mit dem 3D Trailer löst.

 

Hast Du es mal mit den anderen Optionen versucht? -v zum Beispiel?

 

 

- Carsten