Beiträge von Marco

    Es gibt schon auch noch ein paar andere Schnittprogramme, die bezüglich Materialverwaltung genauso aufgebaut sind, also Binstruktur und v.a. eben das, was bei Premiere als "Sequenzen" bezeichnet wird. Avid macht's teilweise so, Edit, CineStream und ich glaube auch Edition Liquid.


    Dieses Arbeiten mit Sequenzen halte ich auch für ein ganz starkes Feature, besonders bei größeren und komplexen Produktionen. Damit hat man selbst bei solchen Projekten eine klasse Übersicht, da man immer nur relativ kleine Häppchen bearbeiten muss. Sowas ist wirklich sehr angenehm.

    Das kommt daher, dass Graphiken ein anderes Pixelseitenverhältnis benutzen als DV-Video. Bei Graphiken werden Pixel quadratisch dargestellt, bei DV-Video werden sie rechteckig dargestellt. Möchte man ein Standbild aus einem Video als Graphik benutzen, bzw. entweder ein Graphk in einem Video, dann muss man entweder die Auflösungen auf die jeweils andere Darstellungsart anpassen. Oder aber man muss dann in dem jeweils anderen Programm eine Korrektur des Pixelseitenverhältnisses vornehmen.
    Wenn man die Auflösungen anpassen möchte, dann ist es entscheidend, welchen Korrekturfaktor eine Software dafür benutzt.


    In Premiere fährt man meines Wissens am besten, wenn man für zu importierende Graphiken eine Auflösung von 768x576 benutzt. Damit sollten die schwarzen Ränder verschwinden und die Geometrie des Bildes sollte annähernd korrekt sein.


    Schau doch auch mal --> hier rein. Dort findest Du einen Grundlagenartikel von Holger Scheel zu diesem Thema.

    Es geht dabei nicht darum, verlorene Informationen rückzugewinnen, sondern nur darum, sicherzustellen, dass durch ein eventuell unterschiedliches Decoding sich Differenzen zwischen den verschiedenen Testern einschleichen, die aber nichts mit dem Encoding, das ja eigentlich Testgegenstand ist, zu tun haben.


    Ich habe z.B. schon sehr oft bei solchen Tests, die in's Internet gestellt wurden, gesehen, dass Leute MS-DV-Clips benutzt haben und für den Test dann erstmal mit Canopus-DV decodiert haben. Damit wird der ganze Test vollkommen wertlos. Das ist zwar ein extremes Beispiel, aber eine gleiche Renderbasis kann nur dann wirklich garantiert sein, wenn eine jede Abweichung durch das Decoding ausgeschlossen ist. Und das geht eben dadurch, dass jeder die gleichen unkomprimierten Files als Basis hat, die werden nicht decodiert. Und wenn dann ein Test auch gleich mehrere Rendergenerationen beinhaltet, dann folgen die weiteren De- und Encodingvorgänge ja mit gleichem Codec (sofern die Systeme richtig konfiguriert sind).
    Gleiches gilt auch für JPEG-Files. Die sollten alle auf einem einzigen System zuerst zu unkomprimierten AVI gewandelt werden und danach dann verteilt.

    Mir sind für den Eigenbedarf zwar ein paar Prompter-Programme bekannt, aber wie das Problem der 'Hardware' dazu zu lösen ist, das wusste ich bisher nicht. Guter Link, Wiro. Das müsste man ja wirklich mal ausprobieren.

    Als Testbasis sollte ein Clip oder ein Bild auf keinen Fall ein unnötiges Rendering durchlaufen haben, bevor der Test beginnt. Ich würde eine jede Testvorlage entweder in dem Originalformat bereitstellen, in dem es auch aufgenommen wurde. Dann sollte das jeder, der einen Test machen möchte, zunächst auf dem eigenen Rechner zu einem unkomprimierten AVI rendern und von dieser Basis her den Encodertest starten.


    Das Beste und Neutralste aber ist es, wenn sämtliche Testdateien an einem zentralen Rechner zunächst zu unkomprimiertem AVI gerendert werden und von dort aus dann anderen zur Verfügung gestellt wird. Ich würde vorschlagen, es so anzugehen.


    Natürlich wird das eine heftige Datenmenge. Aber: Entweder - Oder. Wenn es ein objektivierbarer Rendertest werden soll, dann darf nicht schon die Basis des Tests manipulierbar sein. Ausserdem reicht es ja, wenn je Testbild ein einzelnes Frame extrahiert wird, solange dort keine Bewegungen drin vorkommen. Bewegungen könnte man in einer ersten Testphase noch ganz ausschließen. Damit hätte man 10 bis 15 verschiedene Frames, 15 Frames sind unkomprimiert und ohne Ton ca. 18 MB, als ZIP gepackt noch 12 MB. Diese Datenmange sollte uns dieser Test schon wert sein.

    Es gibt da eine Reihe von typischen Prüffällen, die man relativ allgemein beschreiben kann.


    - sanfte Helligkeits- und Farbverläufe wie z.B. ein Blauverlauf im Himmel
    - harte Luminanz- und Farbkontraste, wie sie an scharfen Objektkanten auftreten
    - Rastermuster, wie eine Kachelung in einer Totalen
    - gerade und schräge Linien und Kanten, wie z.B. die Kanten von Häusern
    - scharfe Rundungen, wie die Umrisse einer Uhr
    - Detailsmuster, wie Salz/Zucker bei einer Nahaufnahme, Gras oder bewegtes Wasser in einer Totalen
    - feine Details, wie einzelne Haare oder einzelne Sandkörner
    - sehr gleichmäßige und langsame Bewegungen, wie ein Flugzeug in sehr großer Höhe, sanfte Kameraschwenks und Kamerazooms
    - sehr schnelle, gleichmäßige Bewegungen, wie an der Kamera vorbeifahrende Autos
    - schnelle und ungleichmäßige Bewegungen, wie abrupte Kameraruckler
    - Informationen im extremen Licht- und Dunkelbereich, wie z.B. helle Strukturen auf einer weißen, hell bestrahlten Hauswand (die das Zebra einer Kamera "anspringen" lässt) und dunkle Gegenstände in einer schattigen Ecke


    Die Liste ist sicherlich nicht vollständig, aber in dieser Art kann man praktische Problemfälle definieren.

    Zitat

    Künstliche Clips und eigenhändisch geflimte Szenen im AVI-DV-Codec sind doch die besser Ausgangsbasis, oder?


    Wenn zum Decodieren von Testclips schon ein besonderer DV-Codec genutzt werden muss, könnte das eventuell wirklich etwas kritisch sein. Wenn's dann aber Canopus-DV ist, womit decodiert wird, hätte ich weniger Bedenken. Wenn das Decoding hochwertig ist und im Verhalten dem Hardware-Codec der Kamera, die das Signal eventuell aufgenommen hat, entspricht, ist das generell o.k., wenn auch nicht ideal (siehe unten).


    Künstliche Clips und Graphiken enthalten meistens Bildmuster, für die die DV-Codecs nicht entwickelt wurden und somit Fehlverhalten der Codecs dann auch keine wirklichen Rückschlüsse auf den Praxisgebrauch zulassen. Graphiken für DV-Codectests werden meist nur verwendet, weil das so schön bequem ist. Es ist ein Notbehelf. Ich würde da als Alternative eher noch Photos eines hochwertigen digitalen Photoapparates verwenden.


    Gerade um eine uneinheitliche Decodierung von Testbildern auszuschließen, ist es aber schon sinnvoll, unkomprimiertes Material zu verwenden. MB1 hat das mit Bedacht so getan.

    Ich denke, die Art und Weise, wie ein optimaler Workflow gestaltet wird, hängt von vielen Faktoren ab, wobei die verwendeten Werkzeuge dafür nur ein Aspekt von vielen ist.


    Wieviel Rohmaterial gibt es? Wie viele und welche Medienformate? Wieviel Zeit bleibt zur Bearbeitung? Welche Art von Film soll damit gemacht werden? Welche Länge soll der fertige Film haben? Wo liegt der Schwerpunkt - in einer extrem schnellen Bearbeitung oder in oder in einem sehr gründlichen inhaltlichen und dramaturgischen Aufbau? Schließen sich irgendwelche Spezialbearbeitungen an? Muss die Projektarbeit so angelegt sein, das gleich mehrere Versionen produziert werden können? Ist nach einer ersten Fertigstellung noch mit gravierenden Änderungen zu rechnen? Werden sämtliche Arbeiten von einer Person übernommen oder gibt es in irgendeiner Form eine Teamarbeit, so dass verschiedene Arbeitsläufe aufeinander abgestimmt sein müssen?
    Das sind für mich die 10 wesentlichsten Punkte, wenn es um die Workflow-Gestaltung geht. Allein daraus ergeben sich schon sehr unterschiedliche Modelle, die sich teils schon im Ansatz stark voneinander unterscheiden.


    So gibt es Arbeiten, die den höchsten Workflow erreichen, wenn man von einem Band aus mit In- und Out-Markierung direkt in die Timeline schneiden kann, dort eine kurze, marginale Überarbeitung der Übergänge von Bild und Ton in Echtzeit und diese Timeline dann sofort wieder raus auf Band. Geeignet für Projekte, die unter starkem Zeitdruck stehen und die nach dem Ausspielen auch sofort auf die (Müll)-Halde landen können. Obwohl das eigentlich ein primitiver (aber auch ein verdammt schneller) Workflow ist, bieten den nur sehr wenige Schnittsysteme!
    Umgekehrt gibt es Arbeiten, wo die Materialorganisation mit Abstand der wichtigste Teil innerhalb des Workflows darstellt. Da kann es Wochen dauern, bis der erste Schnitt vollbracht ist. Da müssen eventuell ständig mehrere Timelines parallel laufen, weil unterschiedliche Produktversionen bei gleichem Ausgangsmaterial gefordert werden. Da wird später an jeder einzelnen Eistellungen über Farbkorrektur eine Optimierung vorgenommen. Klammerteile werden mit besonderen Effekten versehen. Und viele weitere Vorgänge, die es notwendig machen, mit einer möglichst detailierten Planung an die Sache ranzugehen.


    Einen allgemeingültigen Workflow gibt es meiner Meinung nach nicht. Um sich bezüglich Workflow auf einen gemeinsamen Nenner zuzubewegen, müsste man erst aufiltern, inwiefern zum Beispiel die oben genannten 10 Punkte untereinander identisch sind.