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?
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)
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.
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?
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
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.
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?
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.
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.
Hier der Ursprüngliche Satz …
Hier ein weiterer Versuch meines angepassten Fazits:
[b]Auswirkung[/b]
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)
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.
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.
@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.
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.
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!?
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.
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.
@ 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.
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)?
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"
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...
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.
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 !!
blenderman hat geschrieben: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?[/size]
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 ...
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
