Twenty Four: Fragen zur Nachbearbeitung...

Zitat von Trekkie2

Danke für den Link - hab mich auch schon gewundert und nehme seither nur noch AR-unkritische Bilder fürs Menü :cool:

Wenn man nicht gerade nur Kreise und Quadrate für seine Menübilder nimmt, fällts nicht so auf. Ich bin auch erst über die Problematik gestolpert, als ich ein Motion-Menü gebaut habe, welches Text enthalten soll. Dieser muß ja mit in den Hintergrundfilm kodiert werden. Dann wollte ich mit dem gleichen Font und der gleichen Schriftgröße ein Subpic drüberlegen (Button für Link), aber egal wie ich es probierte, ich habe die beiden Texte nicht deckungsgleich bekommen. Naja, und dann habe ich herausgefunden warum...

Zap

Zitat von Eriman

hilft das?
http://www.cinedrome.ch/hometheater/testpatterns/

Vorsicht, das sind 720x480 NTSC Testpatterns und du kannst nicht einfach vo 720x480 auf 720x576 skalieren, da gibts techn. Unterschiede!
Dies ist ebenso auf Juka Ahos Seite dokumentiert.

Zitat von incredible

Dies ist ebenso auf Juka Ahos Seite dokumentiert.

Nie gehört

Zitat von ZapBee

Nie gehört

http://www.uwasa.fi/~f76998/video/…onversion_table

Zitat

4.6 What about standards conversion? Doesn't PAL 720¥576 exactly equal to NTSC 720x480?

As can be seen from the example in section 3.2.2, the answer is no. If you simply resample from 720x576 to 720¥480, the analog active areas of the source and target formats will not match. Fortunately, there is a bit fool-proofness built-in to the relationship of these two frame sizes. What you will actually get from the process is an image in which the original analog active area (702x576 centermost pixels of 720x576) has become 702x480 in the target format's pixels. This, in turn, almost represents a 4:3 area, albeit a bit smaller than what would be needed for a perfect conversion.

The area that 702x480 covers is not the same as the actual analog active image frame (which would be 710.85¥486, or, in practical terms, 711x486). It is more like a smaller 4:3 frame inside it.

In other words, the result is that the active 4:3 image frame in the source format has shrunk a bit in the conversion: it has lost six (target) scanlines in vertical direction and the same relative amount of width. However, for all practical purposes, it has still retained its original aspect ratio. The easiest way to see this is converting 702x480 (in 13.5 MHz 525-line ITU-R BT.601 format) to "true" square pixels: 639 + 4419/4739 square pixels by 480 scanlines is a close enough match to 640x480, which is 4:3. Wonderful coincidence, isn't it?

The same peculiar relationship applies to all 525/625 "sister resolutions" derived from 13.5 MHz:

* 704x576 vs 704x480
* 480x576 vs 480x480
* 352x288 vs 352x240
* etc.

This holds true on two conditions:

1. The source sampling matrix width (in microseconds) must be exactly the same as the target's.
2. You can only convert between a full-height 625-line resolution and a cropped-height 525-line resolution (i.e. use only those formats that represent exactly 480 scanlines worth of 525/60 data, instead of full 486.)

Alles anzeigen

Zitat

FitCD hab ich auch probiert, aber da gibts ein Problem: Addborders wird in x-Richtung nur in vielfachen von 16 gemacht. Ist das zwecks Bitraten (Macroblock)-Optimierung, oder hat das noch andere Gründe? Da mir die Bitrate so reicht, würde ich auf diese Optimierung verzichten...

Hat m.W. die von dir genannten Bitraten-Optimierungs-Gründe. Um das zu ändern: hast du mal mit den Einstellungen "Round To" bei Crop und Resize rumgespielt? Denke, das wirkt sich genau darauf aus - kanns jetzt leider nicht testen, da kein FitCD am Arbeitsplatz

Zitat

Die ITU-R BT.601 Checkbox: Wie stelle ich bei DVB-S Aufnahmen fest, ob ich das Häkchen aktivieren muß, oder nicht?

Wüsste ich auch gerne...

cu, grua

Zitat von Trekkie2

Grade gesehen - ich werd jetzt als Routinier geführt - dabei komm ich gar nicht wie einer vor...

Du bist aber auf dem besten Wege einer zu werden. :daumen:

Moin,

1. Die Horizontale ist die Vorgabe. Wenn da also kein overscan gewählt wird, wird eben auf die Zielauflösung (z.B. 720) optimiert - sprich: danach werden cropping/resizing ausgerechnet und je nach "real aspect" die Vertikale angepaßt.
Wäre das nicht so, hätte man nur Variablen und damit kann man nicht so gut rechnen...
Die Vorgabe in ganzen Blöcken deshalb, weil das für die MPEG2-Komprimierung günstiger ist.

2. ITU-checkbox ist anzukreuzen/angekreuzt, wenn die Quelle ITU-konform ist; also z.B. bei 720 Horizontal 704 bzw. 702 motion-pixel vorhanden sind. Sind die 720 komplett motion-area dann ist das Ding nicht ITU-konform und der Haken muß raus... Das gilt nur für die aource, denn das Ergebnis wird definitv lt. ITU ausgerechnet (es sei denn, man hat was falsch gemacht). Für DVB-Auflösungen analog - da gibts irgendwo Tabellen, welche Auflösung cropped/noncropped ist. Grundsätzlich kann man davon ausgehen, daß bei einer "cropped-irgendwas" Auflösung der ITU-haken immer zu setzen ist, bei einer "noncropped-irgendwas" nur dann, wenn sich die motion-area nicht über den gesamten horizontalen Bereich erstreckt.
ITU vs. Generic ist in meinem AR-Dokument nachzulesen: http://home.arcor.de/der_karl/aspect/aspect.htm

3. Klar - das ist der TV-overscan! Der TV stellt immer weniger da, als der PC-Monitor oder Beamer und zwar rundrum! - Manchmal ist es auch noch verschoben.

Gruß Karl