Frage von blenderman:Hallo Miteinander,
für PAL 16:9 habe ich bisher fröhlich 1024x576 (Square Pixel) produziert und das ganze dann mit 720x576 (1,42) ausgegeben. Jetzt muss ich lesen das eigentlich 1050x576(Square Pixel) korrekt ist.
http://www.bbc.co.uk/commissioning/tvbr ... size.shtml
http://help.adobe.com/de_DE/AfterEffect ... 7f3aa.html
http://de.wikipedia.org/wiki/Phase_Alte ... itales_PAL
Wenn ich das richtig verstanden habe, dann war dies ein bisher häufiger Fehler (z.B. Adobe AfterFX bis CS3 falsch). Man hatte das Seitenverhältnis auf Basis der Höhe berechnet. Dabei aber nicht bedacht das von 720 Breite nur 702 Pixel sichtbar sind. Dann wurde vom Sender entweder das Bild gestaucht und je 9Pixel schwarz angefügt oder das Bild wurde so ausgesendet - war aber leicht verzerrt.
Richtig wäre aber gewesen das Bild mit 1050x576(Square) zu Rendern und mit 720x576(1,46) auszuliefern. Den die 18 fehlenden anamorphen Pixel ergeben 26 Square Pixel. Also 1024+26=1050
Ist das so korrekt?
702x576 anstatt 704x576 sind korrekt. Beitrag überarbeitet.
Antwort von tommyb:
Es ist nur dann richtig, wenn es DV ist.
Wenn Du Animationen in 16:9 erstellst und diese dann als DVD speicherst, dann kannst Du es ohne Probleme auf 720x576 runterskalieren ohne Rand.
Willst Du das ganze wiederum als DV auf Tape ausspielen, dann musst Du es auf 704x576 skalieren und links und rechts Ränder hinzufügen damit es 720 ergibt.
Das Seitenverhältnis von 16:9 ist korrekterweise 1.42222. Das trifft etwa auch auf HDTV zu. Das Seitenverhältnis von 16:9 DV ist 1.458 irgendwas.
Antwort von blenderman:
Hallo tommyb ,
vielen, vielen Dank für deine schnelle Antwort. So ähnlich hatte ich das bisher im Kopf. Aber wenn Du mal unter Links schaust dann siehst Du das Adobe, BBC und Wikipedia nicht explizit von DV sprechen. Am passensten finde ich den Wikipedia Namen: Digital PAL
Wenn ein TV Sender Files nach ITU-R BT 601 möchte. Müsste ich laut Web dann 1050x576 -> 720x576 ausliefern. Sehe ich das Richtig?
Anmerkung
Das Seitenverhältnis bleibt bei 16:9 ja immer 1,42. Der voher schwarze Bereich von 720 bis 702 wird jetzt mit Informationen gefüllt. 1050 & 1,46 benötigt man also um im 702 Bereich wieder 1,42 zu haben.
Antwort von blenderman:
Die drei Quellen sprechen nicht nur von DV sondern um PAL im Allgemeinen. AfterFX CS4 scheint nur noch mit diesen Formaten zu Produzieren (manuelle Settings mal ausgeschlossen).
Jemand noch ne Idee, Korrektur, Erklärung, Frage etc?
Antwort von markus.klein:
Hallo Blendermann und Tommyb,
ich habe Euere Diskussion verfolgt.
Die ananloge Fernsehzeile wurde mit 52µS abgetastet. Bei der Einführung von DV wurde nun mit 720 Pixel (1:1,067) und 13,5MHz gearbeitet. Teil man nun 720/13,5MHz so kommt 53,3µS heraus was bei analogen Kamerakopfen mit digitaler Abtastung dann immer zwei unschöne Streifen rechts und links zur Folge hatte. Um diese Streifen zu verhindern wurde nun wahlweise mit 702 oder 704 Pixel gerechnet. Adobe rechnet nicht mit dem Faktor 1,067 (768/720) sondern mit 1,094. (768/702)
Wenn man nun 1,094*4/3 * 720 multipliziert kommt man auf 1050 Pixel. Der Faktor 1,094 ist nicht korrekt!
(Quelle: Fachbuch - Professionelle Videotechnik Prof.Dr.U.Schmidt.)
Bei 4/3 sind 768 Quadratischen Bildpunkten in einer Zeile. Multipliziert man nun 720 * 1,094 (Adobe!) dann erhält man ca. 786! was dann der Flash-Encoder anzahl der Bildpunkte einer Zeile entspricht!
Daher ist es nicht verwunderlich wenn die PAL Auflösung in Adobe Flash Encoder 786*576 beträgt was dann jedoch nicht 4/3 entspricht sonder ca. 4,1 / 3.
Bei Fragen kann ich gerne weiterhelfen …
Ich wünsche noch einen schönen Tag - Markus Klein
Antwort von markus.klein:
Hallo Blendermann und Tommyb,
ich habe Euere Diskussion verfolgt.
Die ananloge Fernsehzeile wurde mit 52µS abgetastet. Bei der Einführung von DV wurde nun mit 720 Pixel (1:1,067) und 13,5MHz gearbeitet. Teil man nun 720/13,5MHz so kommt 53,3µS heraus was bei analogen Kamerakopfen mit digitaler Abtastung dann immer zwei unschöne Streifen rechts und links zur Folge hatte. Um diese Streifen zu verhindern wurde nun wahlweise mit 702 oder 704 Pixel gerechnet. Adobe rechnet nicht mit dem Faktor 1,067 (768/720) sondern mit 1,094. (768/702)
Wenn man nun 1,094*4/3 * 720 multipliziert kommt man auf 1050 Pixel. Der Faktor 1,094 ist nicht korrekt!
(Quelle: Fachbuch - Professionelle Videotechnik Prof.Dr.U.Schmidt.)
Bei 4/3 sind 768 Quadratischen Bildpunkten in einer Zeile. Multipliziert man nun 720 * 1,094 (Adobe!) dann erhält man ca. 786! was dann der Flash-Encoder anzahl der Bildpunkte einer Zeile entspricht!
Daher ist es nicht verwunderlich wenn die PAL Auflösung in Adobe Flash Encoder 786*576 beträgt was dann jedoch nicht 4/3 entspricht sonder ca. 4,1 / 3.
Bei Fragen kann ich gerne weiterhelfen …
Ich wünsche noch einen schönen Tag - Markus Klein
Antwort von blenderman:
Hallo Markus,
vielen Dank für dein Interesse und deinen Input. Leider hab ich immer noch ein paar Fragen.
Bis jetzt weiß ich das Adobe die Pixelmaße bei Squarepixel und die Pixelseitenverhältnisse bei Non-Sqare geändert hat und die BBC zu dem Thema eine extra Seite aufgestellt hat.
vom Adobe Link
After Effects CS3 und frühere Versionen verwendeten Pixel-Seitenverhältnisse für SD-Videoformate, die das Konzept einer sauberen Blende ignorieren...
PAL
D1/DV PAL von 1,07 zu 1,09
Quadratpixel-Entsprechung PAL D1/DV von 768 x 576 zu 788 x 576
PAL Breitwand
D1/DV PAL Breitwand von 1,42 zu 1,46
Quadratpixel-Entsprechung PAL D1/DV 16:9 von 1024 x 576 zu 1050 x576
Eigentlich dreht sich alles um die Frage: Mit welchen Seitenverhältnissen Produziert man digitales PAL 16:9 für Broadcast?
A. 1050x576 -> 720x576(1,49) wie CS4
B. 1024x576 -> 720x576(1,46) wie CS3, 3dsmax...
und wann gilt das andere Seitenverhältnis?
Vielen Dank für eure Teilname. Ihr seid mir eine Große Hilfe. Vielen Dank und einen schönen Start in die neue Woche.
Antwort von WoWu:
@ markus.klein
Die aufgeführte Umrechnung bezieht sich ausschliesslich auf ein analog entstandenes Bild, wobei der Faktor 1,094 völlig korrekt ist:
Kopiert man nämlich ein analogen Signale in die digitale Welt, muss man aus dem zeitlichen Bereich in Pixel umrechnen denn in der Welt der Standardauflösung unterschied man zwischen PAL- square- Pixel mit 768 x 576 Auflösung und einem Seitenverhältnis von 4:3 = 1:0,75 und im digitalen SD Bereich CCIR 601 mit 720x576 und einem Seitenverhältnis von 5:4=1:0,8.
Beim "Square PAL" haben die Pixel quadratische Abmessungen. Beim ITU-R BT.601 (digiteles SD) sind die Pixel nicht exakt quadratisch sondern rechteckig; bei Darstellung auf dem Computermonitor erscheinen die Bilder deshalb leicht verzerrt.
Das analoge PAL-Signal besteht aber aus Frequenzen, Zeitschlitzen und Amplituden und nicht aus "Pixels" wie oft irrtümlich angenommen wird.
Im ITU-R BT.60155 wird nun festgelegt, wie die Signale in die digitale Welt überführt werden.
Nach der Digitalisierung werden aus den 720 leicht rechteckigen Bildpunkten dann 702 quadratische Pixels pro aktiver Zeile und 576 aktive Zeilen pro Fernsehbild.
Die 702 x 576 ergeben sich aus der zeitlichen Länge (52µs) mal 13,5 MHz Abtastfrequenz.
Rein analog wären es lediglich 575 Zeilen.
Wären die Pixels des digitalisierten SD Signals quadratisch, würde ein Verhältnis von 702 : 575 (etwa 1,22:1) entstehen.
Das ist im Verhältnis zum Bildformat der Röhre (4:3) ziemlich schmal, denn umgerechnet sind das etwa 1,33:1.
Daher müssen die Pixel, um einen solchen Bildschirm zu füllen, einwenig „breitformatiger“ sein. Es sind also liegende Rechtecke.
Will man nun eine solche Bildschirmdarstellung auf einem Computermonitor ansehen, der nur mit quadratischen Pixels arbeitet, würde das Bild „hochformatig“ ausfallen.
Man muss das Bild also in der Horizontalen dehnen, und zwar um den Faktor 1,094.
Dadurch ergibt sich 702 x 1,094 = 768 und somit das richtige Bildformat : 768 : 576 = 4:3.
Die TV Karte eines Computers muss demnach auf dieses Format (768x576) eingestellt sein, um ein 4:3 TV Bild korrekt darstellen zu können.
In der digitalen SD-Welt hat das Fernsehbild eine horizontale Auflösung von 720 anstatt 702 Bildpunkten, weil die horizontale Austastlücke, die dem Rücklauf des Kathodenstrahls diente, wegfällt und die Darstellungszeit somit auf 53,22 µs anwachsen kann.
Multipliziert man das wieder mit den 13,5 MHz der Abtastfrequenz, so ergibt das 720 Samples (Bildpunkte) pro Zeile für den Y-Wert. (Chroma hat wegen (bei) der 4:2:2 Unterabtastung ohnehin nur 6,75 MHz Abtastfrequenz).
Vergleicht man nun ein ehemals analoges TV Bild mit einem digitalen TV Bild und versucht man beide Bilder zur Deckung zu bringen, so wird man feststellen, dass dem analogen Bild rechts und links wirklich 9 Pixels fehlen.
Mit dem horizontalen Dehnungsfaktor 768:702 = 1,094 werden aus 720 rechteckige Pixels der digitalen Komponente 788 quadratische Pixels im Computer, woraus ein Bildformat resultiert, das sich mit 788:576 = 4,1:3 allerdings nur geringfügig bzw. unmerklich zu 4:3 ändert.
@ Markus
Da es kein "digitales" PAL gibt, (PAL ist immer analog), beziehen sich die Angaben auf quadratische Pixels. demnach wäre Dein Produktionsformat auch 1024:576
Antwort von markus.klein:
Hallo blenderman,
Ich habe mir die Links von Adobe und der BBC auch mal angesehen. Streng genommen wird mit nach ITU-R 601 mit 720*576 gearbeitet, so dass ein Pixelseitenverhältnis von 16/15 oder 1:1,067 fakt ist. Wenn du nun das 4:3 Format nochmals mit 4/3 multilizierst kommst du auf 16:9. Soll heissen bei 16:9 hast du ein Pixelseitenverhältnis von 1,42222. Das sind nun die Fakten sauber durchgerechnet und durch die (Softwarehersteller unabhängige) Fachliteratur (Quelle: Professionelle Videotechnik U.Schmidt 3.Auflage) bestätigt. Aber wenn du selbst nun 16 durch 9 teilst dann erhälst du 1,7777777 wenn du 1024 durch 576 teilst erhälst du das Gleiche.
Ich denke du bist auf der sicheren Seite wenn du einfach exakt die Bildseitenverhältnisse 4:3 oder 16:9 beachtest. Ich kann nachvollziehen wie die Werte 1050*576 sowie 1,46 - 1,09 entstehen, um jedoch sachlich und fachlich korrekt zu bleiben spreche ich hier keine Vermutungen aus.
Antwort von markus.klein:
@ WoWu
Ich werde es nun kurz machen bevor du mir noch weiter Dinge versuchst zu erklären; vier kurze Fragen:
1.) ist ITU-R 601 mit 720 Bildpunkten pro Zeile definiert ja oder nein ?
2.) ergibt 768/720 = 1,067 ja oder nein ?
3.) ergibt 720/13,5MHz = 53,33 µS ja oder nein ?
4.) ist nun 768/576 = 4/3 oder ist 788/576 = 4/3 ?
rede ich mit Dr.-Ing. Wolfgang Wunderlich?
Antwort von WoWu:
Durch aufmerksames Lesen wären solche Fragen erst gar nicht entstanden.... steht alle oben...
.. denn reduziert man es auf die reinen Zahlen und berücksichtigt nicht die jeweilige Pixelausformung, kommt man zu falschen Schlüsen. (Bei 601 sind die Pixel z.B. nicht quadratisch !!)
Man darf nicht munter zwischen analog, digital 601 und Computer hin und her springen .... jedenfalls nicht, ohne die nötigen Korrekturen zu berücksichtigen.
Antwort von markus.klein:
@ WoWu
das ist leider nicht die Antwort auf meine Frage. Wenn Sie in der Tat Wolfgang Wunderlich sind dann kennen Sie bestimmt auch den Mann der mich diese Fakten gelehrt hat, Klaus Ruelberg. oder?
Durch die Tatsache das Sie der Antwort ausweichen gehen einem Beweis aus den Weg.
Antwort von markus.klein:
@ WoWu
ich springe nicht munter hin und her! meine Fakten sind und bleiben immer Digital mit 720 Bildpunkte pro Zeile. Sie selbst wechseln zwischen 702 und 720 Bildpunkten pro Zeile.
Antwort von WoWu:
Es gibt Fragen, die man nicht auf ein losgelöstes Example reduzieren kann: Beispiel bitte mit ja oder nein beantworten:
"haben Sie letzte Woche aufgehört Ihre Frau zu schlagen ?"
Sie sehen, meine Antwort steht bereits in der Erklärung. Ein aufmerksames Studium beantwortet Ihnen alle Ihre Fragen im entsprechenden Kontext.
Also bitte ... was stimmt daran nicht, und warum ?
Sie selbst wechseln zwischen 702 und 720 Bildpunkten pro Zeile.
Eben nicht ! Wenn ich 702 schreibe, sind auch 702 gemeint. Bitte lesen Sie dazu die Wandlungsvorschrift der ITU.
Aber, wie gesagt, es steht alles oben.
Antwort von markus.klein:
@ WoWu
also das mit der Frau ist unsachlich.
Ich gehe von der Definition aus das DV-Videobilder eine Größe haben von 720*576 Bildpunkten(U.Schmidt Seite 139) . Diese entsprechen (wie Sie bereits sagten) nicht einen Bildformat von 4/3 sondern 5/4. Wendet man nun die Anforderung an, dass dieses Videobild ein 4:3 sein soll müssen die 720 Bildpunkte auf 768 Bildpunkte gedehnt werden mit den Faktor 16/15 was gerundet 1,067 entspricht.
Die per Definition genannten 720 Bildpunkte dividiert durch 13,5 MHz ergeben eine aktive Zeilendauer von 53,33 µS (U.Schmidt Seite 107) somit ist die digitale Zeile 1,33 µS länger als die analoge mit 52 µS. Nun gab es in der Vergangenheit einige Camcorder welche rechts und links schwarze Streifen ( die 1,33µS der H-Austastlücke) erzeugten, jedoch auch Camcorder bei welchen diese Streifen nicht auftraten. Selbstverständlich im identischen Workflow. Daher liegt meine (von Klaus Ruelber, und Franz Stollenwerk) bestätigte Vermutung nahe das einige DV-Camcorder intern arbeiten. Um nun die Streifen zu entfernen rechnete Adobe mit 702 Pixel pro Zeile um die unschönen Streifen bei DV-Camcordern mit analogen Kameraköpfen zu verhindern. Der Dehnungsfaktor von 1,094 welcher von 702 Bildpunkten pro Zeile kommt, ist bis heute bei Adobe beibehalten worden, obwohl das DV Format mit 720 Bildpunkten pro Zeile definiert ist. Bei FCP wird z.B. mit den Faktor 1,067 gerechnet. Was somit wieder 768 dividiert durch 720 entspricht. Nun sagen Sie mir nun was konkret an meiner Darstellung falsch ist.
Antwort von WoWu:
Das mit der Frau sollte auch nur ein anschauliches Beispiel dafür sein, dass man verkürzte Fragen nicht immer beantworten kann.
(Ich hoffe, es ist nicht persönlich verstanden worden .. denn so war es nicht gemeint).
Der Dehnungsfaktor von 1,094 welcher von 702 Bildpunkten pro Zeile kommt, ist bis heute bei Adobe beibehalten worden, obwohl das DV Format mit 720 Bildpunkten pro Zeile definiert ist.
Adobe geht nach der ITU Wandlungsvorschrift korrekt vor.
Der Fehler, wenn man von DV direkt umrechnet ist der, dass eben nicht berücksichtigt wird, dass die DV Pixel nicht quadratisch, sondern rechteckig sind.
Das wird oft vergessen (oder nicht gewusst) und führt zu diesen Missverständnissen.
Antwort von markus.klein:
@ WoWu
"Nach der Digitalisierung werden aus den 720 leicht rechteckigen Bildpunkten dann 702 quadratische Pixels pro aktiver Zeile"
702 also … und wie kommt es dann das bei 4:2:2 mit 360 Farbwerten pro Zeile gerechnet wird was richtigerweise 720 entsprechen müßte da 360*2=720 sind?
Antwort von markus.klein:
@WoWu
ich vergesse keinefalls das die Pixel nicht Quadratisch sind. Jedes Pixel hat ein Bildseitenverhältnis von 1,067! oder 16/15. Die Definition für DV mit 720*576 Bildpunkten ist doch festgelegt.
Antwort von WoWu:
Das ist wieder einmal vor der Wandlung 720 / 360, verglichen mit dem gewandelten Format !!!!
Hier werden plötzlich die 360 den 702 zugeordnet .... Das ist ein fataler Fehler, denn Croma wird natürlich auch gewandelt !!!
Antwort von WoWu:
Aber wir können das nun natürlich noch einmal alles im Detail aufbröseln.
Weil es oben aber bereits alles zusammengefasst steht, schlage ich nochmals den oben dargelegten Text vor.
Antwort von markus.klein:
Sie ignorieren leider das was ich geschrieben habe und gehen nicht konkret auf Fragen oder Fakten ein! Ich begehe auch keinen Fatalen Fehler wie Sie schreiben. Richtig ist auf jeden Fall das mit 360 Farb und 720 Helligkeitswerten gerechnet wird! Was Sie behaupten ist falsch, mein Darstellung wird von Ihnen ignoriert, mit den Worten das steht doch alles oben … Diese Verhalten ist weder richtig noch angebracht.
Antwort von markus.klein:
Wir einigen uns also darauf das 1,067 stimmt da DV mit 720 Pixel Pro Zeile definiert ist und 768*576 Bildpunkten dem Bildformat 4:3 entsprechen - danke :-)
Antwort von markus.klein:
@ WoWu
ich denke ich werde mir ihr Buch mal besorgen ist bestimmt ganz ok. Ich wünsche Ihnen noch eine gute Nacht.
Markus Klein
Antwort von WoWu:
Wieder so ein Ding aus dem Zusammenhang gerissen ... sind Sie zufällig Rechtsanwalt ?
Wir können uns darauf einigen, dass die, von Ihnen zitierte Behauptung:
Der Faktor 1,094 ist nicht korrekt!
falsch ist. Und das dürfte ja nun hinlänglich belegt sein.
Aber, nichts wird so heiss gegessen, wie es gekocht wird ....
und nur die Auseinandersetzung erzeugt Fortschritt.
Gute Nacht, wünsche ich auch.
Antwort von markus.klein:
Ich habe hinlänglich bewiesen das meine Fakten richtig sind!
Antwort von markus.klein:
Die Kollegen sprechen auch nur von 720 Pixel, Sie machen einen Denkfehler! das ist das Problem.
Antwort von markus.klein:
Was bitte ist an der Rechnung 768/720 falsch ? Und kommen Sie jetzt nicht wieder mit … das steht doch alles oben! Dann habe Sie sich oben eben nicht korrekt ausgedrückt!
Antwort von WoWu:
Was bitte ist an der Rechnung 768/720 falsch?
Das dazwischen ein Sprung in der Pixel Aspekt Ratio liegt !!!!!!
Das habe ich nun aber mehrfach erwähnt !
Und die ITU schreibt es sogar explizit vor, wie es gemacht werden muss: nämlich nicht 768/720 !!!
Antwort von markus.klein:
Aber ich mache Ihnen gerne eine Vorschlag:
Wird mit der analoge kurze Zeile mit 702 Bildpunkten gerechnet (von welcher hier niemand gesprochen hat … nur Sie) dann muß mit 1,094 gerechnet werden. Bei der digitalen Zeile mit 720 Bildpunkten muss demnach mit 1,067 gerechnet werden. Da jedoch aktuell mit der DV Standard mit 720*576 definiert ist bedarf es keiner weiteren Diskussion mehr das 1,067 richtig ist. :-)
Antwort von WoWu:
Obiges zitiertes Papier BBC:
What size is a television picture?
There are 576 active lines in a television picture, making it 576 pixels high. A 4:3 image would therefore be:
(576 x 4) ÷ 3 = 768 pixels wide.
However this assumes the pixels are square - but television pixels are not square. They have an aspect ratio of approximately 1:1.094. A 4:3 television picture would therefore be:
768 ÷ 1.094 = 702 non-square pixels wide
So a 4:3 television image is 702 pixels wide by 576 high.
... nicht gesprochen ??
... und was steht da für ein Faktor ???
... lese ich da 1,094 ? Oder irrt sich die BBC nun auch ?
Und den Übergang zu 720 regelt die ITU, wie oben beschrieben ... irrt die ITU auch ?
Nein, nein, man muss schon alle Umrechnungen nacheinander machen und darf vom Anfang nicht zum Schluss springen, dabei bleibt nämlich das Ratio der Pixels auf der Strecke !!
Antwort von markus.klein:
und lese ich da auch 702 ? oder bezieht sich die BBC auf die analoge Zeile ?
Aber ich bemerke das dass Nieveau nicht mehr fachlich ist. ist 720 Pixel pro Zeile falsch ?
Antwort von WoWu:
Nein, aber es geht doch darum, welche (neue) Produktionsform zum bisherigen SD Fernsehbild kompatible ist. Um nichts anderes geht es ja auch in den, vom Threadstarter erwähnten Papieren der BBC und Adobe.
Wobei es dabei noch speziell um das Grafikformat geht und weniger um das eigentliche Bildformat.
Denn die "Erweiterungen" decken ja nur die Differenzpunkte in der Bildgröße, also noch ein anderes Spielfeld.
Aber auf das gehe ich heute nicht mehr ...
Gute Nacht.
Antwort von markus.klein:
OK ich fasse mal zusammen es ist richtig das 720 Pixel pro Zeile stimmen, aber es ist nicht die 5/4 Darstellung bei 720*576 einfach mit einem Dehnungsfaktor zu multiplizieren damit ein bei 768*576 Bildpunkten ein 4:3 Bild entsteht. Dann ist also auch alles was Apple macht, wenn bei FCP von einem Aspekt Ratio von 1,067 gesprochen wird falsch! Aber nun ist noch eine logische Unklarheit bei ihren Ausführungen warum darf nicht 720*1,067=768 rechnen, dann aber 702*1,094 = 768. Da liegt dann auch ein Sprung in der Aspekt Ratio jedes einzelnen Pixels. (laut Ihnen). Es kann gut sein das sich andere Personen von Ihnen so behandeln lassen, ich persönlich möchte diese Thema verstehen, ohne das immer und immer wieder Fakten wiederholt werden welche mit welche ich bis vor kurzem noch nicht gerechnet habe (1,094) und die Fakten mit welchen ich schon sehr lange rechne (1,067) falsch sein sollen und das mir somit 2 Professoren und 3 Dozenten etwas falsche Erzählt haben sollen. Fakt ist einige DV-Camcorder haben schwarze Streifen, andere nicht! bei einigen muss man mit 1,067 rechnen bei anderen mit 1,094. Was man laut ITU nicht so einfach darf, aber wohl so notwendig ist das einige Softwarehersteller es trotzdem machen … na dann guten Nacht …
Antwort von WoWu:
Lassen sie uns darauf morgen noch einmal eingehen.. natürlich gibt es Erklärungen dafür. Als versöhnlichen Abschluss möchte ich nur kurz anführen, dass solche Themen selbst von Fachleuten manchmal nicht durchblickt werden, weil oft nicht zwischen „Pixel Aspect- „Screen Aspect-
und „Picture Aspect Ratio differenziert wird.
Der „sequence Header“ von MPEG1 Bitstreams z.B. beinhaltet einen beschreibenden „Identifyer“ des Ratios, des nachfolgenden Video Beitrages.
In der Rev 1 des ISO/IEC DIS 2-11172 beschreibt das MPEG-1 Committee 2 von 16 Token für das Aspect Ratio von 480i und 576i.
Leider hat keiner der Werte dahinter etwas mit 10:11 oder 59:54 (der Ratio der Pixels) zu tun. Auch sie hatten die Werte aus der Bild- Aspect Ratio 4:3 abgeleitet und offenbar nicht erkannt, dass dies nichts miteinander zu tun hat.
In der Rev 2 des ISO/IEC DIS 2-11172 wurden dann zwar die Tables des Aspect Ratio geändert, hatten aber immer noch nichts mit den richtigen Seitenverhältnissen der Pixels zu tun.
Und was noch bizarrer war, das Committee entschied in beiden Drafts, die 12 offenen Slots im Pixel Aspect Ratio table mit linearen Inter- und Extrapolationswerten von 480i und 576i zu füllen.
Zu allem Überfluss krönten sie dies damit, dass sie “a certain degree of tolerance” zuliessen und öffneten die Tür damit, für jeden, der das System nicht verstanden hatte.
Seitdem ist dem encodierten pixel aspect ratio in MPEG 1 nicht mehr zu trauen gewesen.
Nun könnte man annehmen, dass sich mit MPEG 2 alle gebessert hat.
Leider nicht, es wurden die Tables von MPEG 1 zwar überarbeitet, die richtigen Verhältnisse aber tauchten hier wieder nicht auf.
1995 kam dann endlich ein SMPTE Papier (SMPTE RP 187) das ein für allemal dies Problem regeln sollte.
Alles war klar geregelt und überaus durchdacht.
Klare Richtlinien für die Industrie und alle Programmierer.
Nur leider war in der Vergangenheit bereits so viel falsch gemacht worden, dass es immer wieder Inkompatibilitäten mit älteren Modellen gab und vor allem immer wieder Entwicklungsingenieure, die nach der Devise arbeiten: „das haben wir immer schon so gemacht“.
Von denen wurden die klaren Vorgaben ignoriert und so haben wir heute immer noch Bilder, die nach der Umwandlung voneinander abweichen und 720 umgerechnete „non square“ Pixels nicht 768 quadratische Pixels ergeben.
Soviel zu den Recordern, die mal so oder mal so darstellen und den Dozenten will ich gar nicht unterstellen, dass sie es nicht richtig beschrieben haben ... aber sind Sie sicher, es richtig verstanden zu haben ?
Sie wären da in gar nicht so schlechter Gesellschaft ..:-))
Ebenso gute Nacht ..
Antwort von MK:
Viel Spaß beim Lesen, Verstehen und Nachrechnen:
http://lipas.uwasa.fi/~f76998/video/conversion/
Antwort von markus.klein:
@ WoWu
guten Morgen. Um auf ihre Frage einzugehen ob ich es richtig verstanden habe? Ich habe die Bestätigung bekommen das nichts falsches an den Dehnungsfaktor 1,067 ist. Die Erfahrung gemacht das meine XHA1 wenn Sie im DVFormat aufzeichnet tatsächlich 720*576 Bilder produziert, genauso wie die VX2000. Dieser Prozess von Verständnis ergänzt durch theoretischer und praktischer Bestätigung der tagtäglichen Arbeit wird nun hier als falsch dargestellt, ohne das eine Fallunterscheidung gemacht wird. Es ist zwar fachlich nicht richtig falsches mit Falschem zu multiplizieren damit etwas richtiges herauskommt, aber kann dass einem Menschen der nichts anderes gelernt und bestätigt bekommen hat vorgeworfen werden? insbesondere da dieser dann selbst sich intensiv aus eigener Motivation mit der Thematik auseinandergesetzt hat und diese Werte noch durch Hausarbeiten, Referate und Klausuren gefestigt wurde? Ich denke solche Vorwürfe sind ohne Differenzierung kontraproduktiv da Sie nur Gleichgültigkeit im Ergebnis zur Folge haben.
Ich fasse somit die Fakten zusammen: DV ist mit 720*576 definiert, damit bei der Quantisierung der analogen Fernsehzeile mit 52µs nicht die H-Austastlücke zwei schwarze Streifen verursacht wird mit 702 Bildpunkten gerechnet. Hier ist dann noch die Frage in wie weit die Rechnung ihres Kollegen U.Schmidt bei welcher er 720/13,5 MHz =53,33 µS rechnet missverständlich verstanden wurde?
Antwort von blenderman:
Guten Morgen Miteinander,
vielen Dank für Ihre Mitwirkung. Seit den letzten fünf Jahren arbeite ich einem Digitalen Workflow. Mit Bänder und Sendetechnik habe ich kaum direkten Kontakt. Das 1024x576 genau einem Seitenverhältnis von 16:9 entspricht konnte ich mir bisher wunderbar errechnen. Die Ergebnisse wurden zusätzlich von gängiger Produktionssoftware bestätigt. Darum wurde ich von Wikipdia, Adobe ab CS4 und BBC mit den neuen Werten wirklich überrascht.
Auch nach den 34 Beiträgen in diesem Thread lande ich immer wieder bei der gleichen Vermutung. Darum hier noch mal ein Erklärungsversuch mit einfachen Worten. Sozusagen ein von Vermutungen gespicktes Fazit:
Ursache des Problems
Bisher wurde das Signal Analog über den Äther geschickt. Die Breite entsprach etwa 702Pixel. Nun wird über DVB ein digitaler Stream gesendet. Dieser ermöglicht die volle Breite von 720Pixeln. Die meisten Geräte zeigen weiterhin eine breite von etwa 702 Pixeln. Aber immer mehr Geräte können die vollen 720 Pixel empfangen und darstellen. Darum sollte man heute den ehemals schwarzen 18 Pixel Bereich mit Information füllen.
Auswirkung
Verlangt der Sender / die Produktionsfirma:
PAL 16:9 nach CCIR 601 dann produziere 1024x576(Square) / 720x576 (1,42)
PAL 16:9 nach ITU-R BT.601 dann prodzuiere 1050x576(Square) / 720x576(1,46)
Antwort von markus.klein:
Hallo blenderman …
Ich würde es auch so sehen
1024*576 mit Faktor 1,42 was dann aber wieder auf 768*576 mit 1,067 zurückgeführt werden kann aber laut WoWu nach ITU nicht gerechnet werden darf. Andererseits habe ich auch keine Lust mehr das Erfahrungswerte und bestätigte Fakten hier zerrissen werden, ohne das diese hinreichend einer Fallunterscheidung unterzogen werden.
Antwort von blenderman:
Hallo Miteinander,
ein professionelles: juhuu! Wir sind dem Kern des Problems also nahe. Leider habe ich bisher 4:3 bewusst ausgelassen um das Thema zu vereinfachen. 16:9 erschien mir als Beispiel besser. Inzwischen ist mir aber bewusst, dass die Umrechnung von Analog zu Digital nicht ohne 4:3 geht. Entschuldigt bitte falls dies zu Verwirrungen geführt hat.
Hier ein weiterer Versuch meines angepassten Fazits:
Auswirkung
Verlangt der Sender / die Produktionsfirma:
PAL 4:3 nach CCIR 601 dann produziere 768x576(Square) / 720x576 (1,07)
PAL 16:9 nach CCIR 601 dann produziere 1024x576(Square) / 720x576 (1,42)
PAL 4:3 601 nach ITU-R BT.601 dann prodzuiere 788x576(Square) / 720x576(1,09)
PAL 16:9 nach ITU-R BT.601 dann prodzuiere 1050x576(Square) / 720x576(1,46)
Sind meine Auswirkungen so korrekt? Ist meine vereinfachte Ursachenerklärung richtig?
Antwort von MK:
Du könntest auch einen Kreis abfilmen und schauen bei welcher Einstellung dieser am PC entzerrt wieder exakt kreisrund ist ;)
Antwort von markus.klein:
also zusammengefasst:
CCIR 601(1,067)
ITU-R BT.601(1,094)
und da die ITU die Umrechnung 768/720 (laut WoWu) untersagt ist, und somit der Faktor 1,067 in deren Augen unzulässig, definiert die ITU-R BT.601 den Faktor 1,094
dann bin ich mal gespannt was WoWu dazu sagt …
Antwort von WoWu:
Hallo.
Zunächst einmal eine Richtigstellung:
Nicht ich habe einen Faktor als falsch deklariert, sondern Markus.klein hat eine Falschbehauptung aufgestellt, die nicht tragfähig ist:
Der Faktor 1,094 ist nicht korrekt!
Also: Markus.. ein gutes Erinnerungsvermögen ist bei einem langen Thread manchmal nützlich.
Ansonsten würde ich mir mal die ITU ITU-R BT 601/55 beschaffen und auch lesen, denn darin ist vorgeschrieben, wie eine Umrechnung zu erfolgen hat.
Wenn es Dir mit einem Workaround auch gelingt: herzlichen Glückwunsch.
Übrigens ist CCIR601 und ITU-R BT 601 ein und dasselbe.
Es hat lediglich eine Bezeichnungsänderung gegeben, als die ITU und die CCIR 1999 gemeinsame Veröffentlichungen verabredet haben. Einzige Änderung war es, dass aus den 52 µs der CCIR aus der BT.601 53 1/3 µs also 720=864x144 Pixels) übernommen wurden.
Das hier ist also wieder einmal so eine Phantasie, um 1,067 irgendwie einen "offiziellen Anstrich" zu geben (jedenfalls findet sich der Faktor in dem 601 Papier nicht:
also zusammengefasst:
CCIR 601(1,067)
ITU-R BT.601(1,094)
Ansonsten steht alles oben in meiner Darstellung, was es für mich dazu beizutragen gibt.
@ MK
Danke für den amüsanten Beitrag (Link). :-))
Man könnte das Ganze nun noch um das interlaced-Thema und dem damit zusammenhängenden "Gewürge" erweitern und hätte noch einmal mindestens ebenso viel Spass.
Antwort von blenderman:
Natürlich ist dass eine Phantasie – meine. Darum deklarierte ich mein Fazit auch als persönliche Vermutung. Ein Erbärmlicher Versuch einer Fallunterscheidung. Ich filme nix und habe auch keinen Zugriff auf Sendetechnik. Photoshop -> 3dsmax -> AfterFX -> Mjpeg. Darum kann ich auch nicht wie von MK gewünscht rundes mit rundem Vergleichen.
Wann produziere ich mit 1024x576 und wann mit 1050x576 für PAL 16:9?
Wie kann ich diese beide Werte Textlich unterscheiden?
@WoWu das mit dem interlaced thread finde ich eine verdammt gute Idee. Für die ITU http://www.itu.int/rec/R-REC-BT.601-6-200701-I/en bin ich hier Richtig?
Antwort von WoWu:
@ blendermann
Ich hatte mit der Phantasie eher gemeint, dass unbedingt auf noch so obskurem Weg da wieder irgendein Faktor ins Spiel gebracht werden sollte, weniger Deine Resume ... man müsste übrigens mal verifizieren, ob dieser Faktor eigentlich auch für Widescreen Gültigkeit hat oder ob das lediglich so ein Zufallsprodukt aus: "Was könnte denn der Faktor von x nach y sein.." ist.
In Bezug auf die das Produktionsformat ist es wichtig zu wissen, ob Du eine Grafik meinst, oder eben bewegtes Bild, weil die Geometrie eines Grafikformates 1050 ist, wohingegen Du ein Video ja nicht mit springenden seitlich Balken haben möchtest, sondern in einem "Guss", daher ist ein Videoformat 1024.
Bei der Grafik wirst Du (klar) die seitlichen 20 Pixel nicht mit Inhalt belegen, weil sie bei analog TV ohnehin nicht sichtbar sind.
(Oft besprochen: weil die Bildpunkte auch leicht rechteckig sind - zwar kaum merklich, aber es ist eben, wie in dem Beitrag von MT aufgeführt, eine Frage des Anspruches, ob "so ähnlich" reicht, oder man sich den kritischen Augen eines TV Senders stellen muss).
Da ich zu den Letzteren gehöre, ziehe ich die korrekte Methode vor.
Bezüglich des EBU Papiers liegst Du richtig. (Ich habe es allerdings irgendwo im Netzt auch schon mal als freies pdf gesehen) .. weil es sich um ein geschütztes (und kostenpflichtiges) Papier handelt, kann ich es nicht einfach beistellen. Bitte um Verständnis, aber einwenig Suche lohnt bestimmt.
Ich hoffe, Du bist einen Schritt weiter gekommen.
Antwort von blenderman:
An alle Thread Teilnehmer. Vielen Dank für euer Interesse, euer Wissen und auch für eure Geduld.
Meine Job sind 3D Animationen. Also Bewegtbilder. Ab und zu mit Realbildmaterial im Hintergrund. Die verwendeten Applikationen können (auch je nach Version) nicht immer mit Non-Square Pixel umgehen. Darum ist es für mich wichtig die Square Auflösung zu wissen. Hier ein Beispiel:
Sehr Alter Workflow mit AfterFX 5.0 (FÜNF)
Das AfterFX konnte zwar NonSquare Footage importieren und ausgeben. Konnte aber mit seinen Effekten und in der Anzeige nur Square Pixel verarbeiten. Der Workaround war folgender:
1. Footage (Realbildmaterial, Renderings) angeliefert mit 720x576 als 1,42 Pal D1 / DV Breitwand zu interpretieren
2. Footage (Photoshop Bilder, Renderings) angeliefert mit 1024x576 als Square Pixel interpretiert
3. Eine Arbeitskomposition 1024x576 mit Square Pixel erstellen
4. Die Arbeitskompoistion in eine Finale Komposition mit 720x576 mit 1,42 Pal D1 / DV Breitwand legen und das ganze Rendern.
Die Version 6 oder 7 der Software machte diesen Workaround überflüssig. Hier stellte ich mein Zielformat Pal D1/Dv Breitwand ein. 720x576 mit (1,42). Die Anzeige erfolgt seit dem entzerrt und die Effekte verstehen sich auf NonSquare.
CS4 ändert das bisherige Pal D1 / DV Breitwand jetzt auf 1,46. Bis CS3 stand das Format auf 1,42. Viele andere Software Packete nutzen 1,42.
Schritt 2 müsste laut CS4 also eine Arbeitskomposition mit 1050x576 Square Pixel sein..
@Wowo ITU Dokument: um Gottes willen, so abgesichert musst Du mir den Link nicht bestätigen. Aber vielen Dank. Das mit der Phantasie hatte ich auch nicht beleidigend aufgefasst. Ich versuche nur das ganze in mein „Square Pixel Denken“ zu bekommen. Hier ist mein „Zuhause“ und damit kann ich bei jedem Software Packet arbeiten.
Antwort von markus.klein:
@ WoWu
interessant das jetzt selbst das Kritisiert wird was blenderman geschrieben hat und ich wiederholt habe.
Antwort von markus.klein:
Hallo Miteinander,
@ WoWu
Hier der Ursprüngliche Satz …
Hier ein weiterer Versuch meines angepassten Fazits:
Auswirkung
Verlangt der Sender / die Produktionsfirma:
PAL 4:3 nach CCIR 601 dann produziere 768x576(Square) / 720x576 (1,07)
PAL 16:9 nach CCIR 601 dann produziere 1024x576(Square) / 720x576 (1,42)
PAL 4:3 601 nach ITU-R BT.601 dann prodzuiere 788x576(Square) / 720x576(1,09)
PAL 16:9 nach ITU-R BT.601 dann prodzuiere 1050x576(Square) / 720x576(1,46)
Antwort von markus.klein:
@ WoWu
aufmerksames lesen hilft! Wie du bereits bemerkt haben solltest - war ich bereits in der Lage dazu zu lernen … natürlich darf das nicht eingestanden werden da sonst die Argumente fehlen … oder WoWu.
Antwort von blenderman:
Hallo Markus,
danke aber ich habe das nicht als destruktive Kritik aufgefasst. Das mein Fazit nicht ganz passen könnte war mir klar. Das in diesem Beitrag mal etwas überlesen wird oder ein Teilnehmer von Äpfeln und der andere über Birnen ist bei dieser Thematik kein wunder. Ich finde eure Beiträge wirklich sehr Hilfreich.
Den letzten Beitrag mit Grafik und Bewegtbild habe ich leider nicht klar verstanden. Darum meine Erklärung eines Standardworkflows aus meiner square Pixelwelt und die weiterhin Frage: so weiter machen oder war das falsch und 1050 ist richtig.
Antwort von WoWu:
kryptisch ..
Antwort von markus.klein:
@ blendermann
Ich muss jetzt mal los, ich wünsche Dir noch einen schönen Abend …
gruß
Markus
Antwort von blenderman:
Wünsche Dir auch einen schönen Abend.
@WoWu was ist kryptisch? Der Workflow, einer der letzten Posts, der Ganze Thread? *lach
Geh einfach davon aus das ich nur mit Square Pixel (die absolut Quadratischen im Computer) arbeiten kann. (Stimmt nicht ganz -egal) Diese Auflösung wird dann in die Breite 720x576 gequetscht.
BISHER
dachte ich mein Empfänger interpretiert das Finale Video mit 1,42 -> Dann muss ich korrekterweise 1024x576 in 720x576 quetschen.
So arbeite ich bisher. So bin ich es gewohnt.
NEU*
Interpretiert mein Empfänger aber die 720x576 mit 1,46 -> Dann muss ich 1050x576 in 720x576 quetschen.
Er arbeitet nach ITU BT 601 und ich muss 1050x576 produzieren.
Antwort von WoWu:
@ blendermann
mein kryptisch bezog sich nicht auf Deine Entgegnung ... aber mit dem ganzen Thread magst Du auch nicht so falsch liegen. :-)))
Schönen Abend noch ..
Antwort von blenderman:
;-) Ebenso einen schönen Abend.
Ist mein Beitrag von 20:47 korrekt?
Antwort von markus.klein:
gehe ich morgen drauf ein … treffe mich morgen noch mit meine früherem Professor mit dem quatsche ich auch mal über das Thema.
Antwort von blenderman:
Hallo Markus,
klasse! Vielen Dank. Bist Du schon weitergekommen?
Antwort von markus.klein:
Bin weitergekommen, aber gerade nicht oft hier online, kannst du mir eine Mail schreiben. Die kann ich regelmäßiger über das iPhone abrufen …
gruß
markus
Antwort von blenderman:
Wird gemacht. Für alle anderen, ich bin auch etwas weitergekommen:
http://www.mikeafford.com/blog/2009/03/ ... s4-vs-cs3/
Meine Ursachen Erklärung stimmt also überein. Das Fazit ist aber genauso offen. Viele nutzen weiterhin 1024. Der Autor hat aber einen Photoshop erzeugten Kreis mit 1050 und mit 1024 getestet. Ergebnis war das der 1050er Kreis etwas Perfekter aussah.
Hier noch ein paar weitere Links
http://provideocoalition.com/index.php ... he_course/
http://blogs.adobe.com/toddkopriva/2009 ... ter_e.html
Antwort von zwiebel_sondermann:
hallo zusammen,
ich schließe mich mal dieser diskussion an da ich ähnliche probleme wie blendermann habe. so wie er komme ich auch aus der welt quadratischer pixel, habe aber in letzter zeit mehr und mehr mit video zu tun und schlage micht mit so schönen sachen wie pixelverhältnisse und deinterlacing etc. rum.
zum thema, auch ich wunderte mich beim wechsel auf cs4 das adobe für material wie bspw. standbilder eine quadratische auflösung von 1050x576 bzw. 788x576 angibt.
habe dann wie ihr auch im netz recherchiert (bbc, wikipedia usw.) und die theorie dahinter auch einigermaßen verstanden.
meine frage ist nun folgende:
ich habe ein premiere projekt (dv pal widescreen 48khz) importiere dort ein standbild aus photoshop (bspw. das testbild von der bbc seite)(1050x576) exportiere das ganze in ein MPEG2 720x576 PAR 1,459 (=> 1050x576).
Das exportierte File wir dann mit ffmpeg in verschiedene Ausgabeformate encodiert bspw. für ipod oder Flahsplayer u.a. in einer Auflösung von 1024x576. Wenn ich mir das 1024er Video anschaue, sehe ich nicht das irgendwelche Pixel an der Seite verloren gehen und ich kann auch nicht sagen das das ganze irgendwie verzerrt wird...
Also was genau wird beim runterrechnen von 1050 auf 1024 gemacht? Es muss doch eigentlich etwas abgeschnitten oder skaliert werden!?
mfg
Antwort von Jollitop:
Hat schon jemand einen Weihnachtsbaum? ;-)
Antwort von Interlaced_Killer:
Frage:
Lieferten die PAL Kameras, welche links und rechts schwarze Streifen einrechneten, ein gecropptes Bild oder ein geschrumpftes Bild im Vergleich zu Kameras, welche die 720x576 voll mit Bild auffüllen?
Hier könnte der Lösungsansatz liegen. Im Endeffekt geht es ja nur um die Frage, was der Sender sich erwartet, wenn er das Material bekommt.
Wenn also gecroppt wird, dann wären die Pixel links und rechts unnötig, und somit über 4:3 vermutlich hinausgehend, wodurch du auch mit 1050 arbeiten musst, oder mit 1024 und das Endergebnis mit schwarzen Pixeln füllen müsstest.
Wenn in den Kameras, welche schwarze Balken liefern, resized wird, dann gehe ich ohnehin davon aus, dass sich die Sender das Material vorher ansehen, schlussendlich bei sichtbaren Balken den Resize-Schritt bereits als vorweggenommen beachten. In diesem Fall könntest du ebenfalls mit 1024 arbeiten, oder auch mit 1050.
Nach diesem mathematisch-logischen Denkansatz, der mit Wissen überhaupt nichts zu tun hat, denke ich, dass du mit 1024 auf keinen Fall falsch liegst.
Antwort von blenderman:
Hallo zwiebel_sondermann,
nur kurz zu Deinem Beitrag. Wenn Du 1050 breites Bild nimmst und Anamorph mit 720 Breite herausrechnest und diese dann mit ffmpeg auf 1024 skalierst kann es nur verzerrt sein. Korrekterweise müsstest du mit ffmpeg das Bild auf 1050 strecken und dann je 8 Pixel links und rechts abschneiden.
mfg
blenderman
Antwort von WoWu:
@ zwiebel_sondermann
Das ganze Thema betrifft nur Grafiken, die mit (Video) gemischt werden, das aus der PAL-Welt, also aus dem ANALOGEN kommen !!
Wenn Du aus 720 kommst hast Du keine "schwarzen" Pixel, ergo auch kein 1050.
Antwort von zwiebel_sondermann:
@blendermann
also ich habs mittlerweile anhand von testbildern auch erkannt das dabei skaliert/verzerrt wird.
ich frage mich nun wie ich meinen workflow am sinnvollsten "anlegen" soll. als input habe ich videos von digitalen camcordern (SD Card oder HD) in 720x576 oder auch mal 704x576 hinzu kommen ab und an werbeclips die mit after effects oder flash erstellt werden und Standbilder in 768x576.
die ausgabeformate sind bisher ausschließlich quadratische Pixelformate 320x240, 640x680 usw..
welche sequenzeinstellung wäre für solch ein material am sinnvollsten sodas ich keine verzerrung habe? wäre es richtig das standard dv anzupassen und auf 768x576 quadratische pixel einzustellen?
achja und bisher gebe ich aus premiere immer ein 720x576 (PAR 1,094) MPEG2 aus, da würde dann ein 768x576 auch mehr sinn machen.
@WuWu
wie oben schon erwähnt arbeite ich ausschließlich mit digitalen input, bedeutet dies, das mein digitales video material auch skaliert/verzerrt wird wenn ich mit der dv sequenzvorgabe arbeite (720x576 PAR 1,094)?
Antwort von blenderman:
Hallo zwiebel_sondermann,
was man wann verwendet, versuche ich gerade anhand dieses Forumbeitrages herauszufinden.
Eins ist aber klar 1050 lassen sich, wie Du auch überprüft hast, nicht in 1024 strecken. Vorerst würde ich nur empfehlen mit 1050 zu arbeiten und die unnützen 16Pixel (8links 8rechts) erst bei Bedarf wegschneiden. Frei nach: "Dreimal abgeschnitten und immer noch zu kurz"
Lg,
blenderman
Antwort von zwiebel_sondermann:
für eine durchgängig saubere vorgehensweise wäre ich sehr dankbar. danke dir für diesen schönen thread.
hab gerade mal meine idee eine 768x576 sequenzvorgabe zu nutzen probiert, die standbilder sind da natürlich korrekt 1:1 leider wird aber das digitale videomaterial (ursprünglich 720x576 von einer SD Sony Cam) links und rechts abgeschnitten und gleichzeitig gestreckt. auch nicht das wahre...
Antwort von zwiebel_sondermann:
also meine voerst sinnvollste lösung ist das bild in 1024 zu speichern und dann in premiere zu skalieren (ca. 102,6% in der Breite). Alternativ kann man auch das Bild per Photoshop nochmal auf 1050 skalieren. Mein Endresultat aus ffmpeg ist dann nicht verzerrt.
was mich an premiere cs4 auch nervt ist das man nicht das pixelseitenverhältnis manuell bei "filmmaterial interpretieren" angeben kann oder zumindest 1,0666.
Antwort von WoWu:
Hallo zusammen ...
Der Kern des Problems steckt doch einfach nur darin, dass die PAR der Videos und der Grafik unterschiedlich sind.
Würdet Ihr eine Grafik + der fehlenden 2x9 Pixels auf das Video legen, dann würdet Ihr "non square" (Video) mit "square" (Grafik) mischen.
Beide Quellen müssen also den Korrekturfaktor 1,094 durchlaufen. Da Ihr die Grafikdaten (die ja schon quadratisch sind) nicht verzerrt, muss also eine solche Verzerrung rechnerisch dargestellt werden.
Daher die 20 statt der fehlenden 18 (18x1,094)-(26 bei Breitbild).
In meinem Buch habe ich eine Grafik, die das (glaube ich) anschaulich darstellt. Bilder sagen eben oft mehr als 1000 Worte.
Aber wenn Ihr ohne analog Bild, lediglich aus DV eine Produktion anlegt, stellt sich das Problem doch gar nicht, weil die Produktion gleich auf 788 x 576 angelegt ist. Das Problem entsteht doch eigentlich nur, wenn Ihr mit einem analog-Bild zusammen arbeitet, dessen Produktion auf 768 x 576 angelegt wäre, also nur bei der Mischung von analogem, digitalem und Grafik.
Das Bild incl. Grafik aber erst in (1024) fertig zu stellen und anschliessend incl. Grafik zu skalieren halte ich für die schlechteste aller Lösungen, denn es reicht doch schon, dass das Bild durch Interpolation an Qualität verliert, da muss doch nicht auch noch die Grafik drunter leiden !!
Antwort von PAR:
Wenn ein TV Sender Files nach ITU-R BT 601 möchte. Müsste ich laut Web dann 1050x576 -> 720x576 ausliefern. Sehe ich das Richtig?
Die ITU-R BT 601 bzw. EBU Standarts sind 768x576 Pixel für Square und 720x576 mit einer Aspect Ratio von 1,07.
Adobe arbeiten nicht nach Standards einer Zertifizierungs Organisation sondern nach BBC Standard. Grundsätzlich sind die BBC überlegungen wohl richtig. Es ist allerdings totaler Murcks plötzlich mal gerade den Standard ohne umschaltmöglichkeit umzustellen. Zu mal nicht alle hersteller mitspielen. So sind noch mehr Fehler vorprogramiert.
Vielen Dank, Ihr Profis von Adobe, für solch eine ...
Antwort von MacPro:
Die ITU-R BT 601 bzw. EBU Standarts sind 768x576 Pixel für Square und 720x576 mit einer Aspect Ratio von 1,07.
Ich habe das offizielle pdf von Rec. ITU-R BT.601-6 grad vor mir liegend.
Wo steht hier etwas von einem PAR von 1.07 ???
Antwort von WoWu:
@ PAR
Das EBU Papier regelt lediglich das Timing der unterschiedlichen Systeme zueinander aber keine PAR.
Und 1,07 ist ohnehin falsch, weil das PAR in 625er Systemen immer 59:54 ist, also mit dem Quotienten 1,094 gearbeitet wird.
http://de.wikipedia.org/wiki/Pixelseitenverhältnis
Häufig ist fälschlicherweise für PAL der Wert 1,0667 zu finden, der sich durch den (fehlerhaften) Bezug auf eine Breite von 720 Pixeln ergibt (d.h. 768/720) und hat eine Verbreitung gefunden, dass er sich selbst in namhafter kommerzieller Software wiederfindet.
Darüber hinaus hat sich doch gar nichts geändert, ADOBE hat lediglich einen bisher gemachten Fehler in den Programmen korrigiert.
Antwort von PAR:
Darüber hinaus hat sich doch gar nichts geändert, ADOBE hat lediglich einen bisher gemachten Fehler in den Programmen korrigiert.
Das "korrigiert" klingt ein wenig harmlos!
1. hat Adobe die Änderung nur unzureichend veröffentlicht!
2. durch die Umstellung kommt es zu etlichen Fehlern,
unter anderem weil Templates in Adobe Photoshop falsch sind.
3. im Zusammenspiel mit Herstellern die sich nicht der Adobe Linie anpassen
(Apple ist dem CS4 weg ja auch wesentlich später gefolgt, in der zwischen Zeit ist es sicherlich zu vielen falschen Interpretationen gekommen)
4. Autodesk beruft sich darauf das der weg von Adobe nicht von der EBU zertifiziert ist.
Antwort von WoWu:
Die EBU zertifiziert ohnehin nichts und wenn es zu Fehlern gekommen ist, dann doch nur, weil man sich auf die falschen Templates verlassen hat.
Der Verfahrensweg hat sich überhaupt nicht geändert und sehr viele Hersteller haben ihn ja auch korrekt implementiert.
Am PAS hat sich nichts geändert, das war schon immer 59:54 und das Timingverhältnis ist auch schon immer so geregelt, dass bei PAL 702 Bildpunkte und bei DV601 720 Bildpunkte vorliegen. Aus dem Quotienten 1,094 hat sich also schon immer eine Projekteinstellung von 758x576 für PAL und 788x576 für DV601 ergeben.
Bezw. für WS entsprechend 1024 sofern es aus PAL kommt, oder eben 1050, wenn es aus DV601 kommt.
Es hat sich also nichts geändert, wenn bisher mit den Parametern korrekt umgegangen wurde.
Der Fehler lag eben nur darin, dass man sich bei PAL Material immer bei Umrechnungen auf die 720 bezogen hat und nie die 18 schwarzen Pixels berücksichtigt hat, die ja zur Geometrie des Bildes gehören.
Es hat sich also wirklich nichts geändert.
Und wenn sich Autodesk da auf die EBU beruft, dann ist das kein Argument, wie gesagt, die EBU zertifiziert nichts und es ist der EBU auch ziemlich egal, ob Hersteller richtig mit der PAR umgehen oder eben nicht.
Die EBU definiert nur die 59:54, die 702 und den Timingübergang zu 720.
Und wenn Hersteller nicht richtig damit umgehen, ist es deren Sache. (Wie Du richtig anmerkst, hat Apple da auch seine lieben Probleme mit und hat noch lange nicht alles umgestellt).
Aber ich gebe Dir Recht, es hätte (auch von Adobe) besser kommuniziert werden können und wenn man alte Grafikeinstellungen benutzt, ist es schon mit etwas Aufwand verbunden, sie zu korrigieren.
Aber es ändert eben nichts daran, dass es ein Fehler war, (den übrigens jeder hätte selbst auch nachrechnen können).
Antwort von trautwin:
Hab ne frage, entstehen beim croppen in virtualdub verluste? oder kann man bneliebig ränder entfernen ???
Antwort von dienstag_01:
Wenn die Ränder Bestandteil deines Videos sind und du die abschneidest, wird dein beschnittenes Video auf die Originalgröße skaliert (vergrößert). Demzufolge gibt es Verluste.
