Resoluciones y formatos de video

[Biofix]

Hola gente, quería saber según vuestra opinión, cuál es la mejor forma de renderizar una animación. Me refiero a qué tipo de archivo de vídeo utilizo, la resolución de salida, si se usa compresión, cuál y cuándo, en el render o después etc. Todo esto aplicado a distintas situaciones: para ver el vídeo en el PC, en la web, animación de calidad para un encargo.
(por cierto, no sé si este era el lugar más indicado para tratar esto). Gracias por adelantado. Hasta luego.

[pp]

Depende mucho de para qué va a ser ese vídeo. Si va a ser para broadcast, o televisión profesional, lo mejor es sacarlo en secuencia de (*.tga) con canal alfa (si es necesario), en formato PAL para Europa (720 por 576), y con campos (el impar primero). Si es para pasarlo a VHS (más doméstico) te bastara con secuencias de (*.jpg), ya que la pérdida de calidad no es tan apreciable. Por supuesto también en formato PAL y con campos, si lo que quieres es colgarlo en la web, deberá estar comprimido para que pese lo menos posible. Para ello, puedes sacarlo igualmente en secuencias, y tras hacer la postproducción comprimirlo vía Sorenson, Ccleaner, divx, etc. Esto depende de las pruebas que hagas y veas la relación calidad - tamaño. Esto se puede aplicar también a verlo en el PC, dependiendo de la potencia, de si va a ser visto desde el disco duro o desde un CD, yo personalmente soy partidario de sacar el render a la mejor calidad posible, es decir sin ninguna compresión. Después postproducir, y sacarlo también sin compresión, y después comprimirlo con algún programa adecuando en función de su destino. Un saludo.

[Roberto]

Hola, yo te recomiendo que si tienes espacio en disco lo hagas en (*.tga) con alpha cómo te mencionan arriba, te libraras de muchos problemas, y más si usas discos IDE que muchas veces corrompen los archivos comprimidos en jpg, además es muy curioso, si los ves individuales se ven bien, pero cuando los unes en cadena con cualquier programa de edición hay cuadros que se corrompen. Curioso, pero solo pasa con discos IDE, lo haces con SCSI y perfecto, pero, por si acaso todo lo hago todo en (*.tga), aunque los discos que tengo son SCSI, las resoluciones cómo te comentan PAL 720 por 576 o incluso 768x576 25 frames por segundo, el sistema NTSC 640 por 480 30 frames por segundo o 29.9 creo recordar, en cine hay varios formatos, normalmente están todos prefijados en los programas 3d como el 3ds Max o Maya. Un saludo.

[adal]

Hola. Mira aquí creo que te ayudara. Saludos.

[Biofix]

Muchas gracias a todos, me habéis explicado exactamente lo que yo quería saber, y más. Como controla la gente por aquí. Por cierto, Adal, se te ha olvidado poner el enlace, pero gracias de todas formas. Un saludo.

[lexus]

Muy bueno el link Adal. Tú sí que eres un faro en la oscuridad. Saludos.

[adal]

Un despiste lo tiene cualquiera, mil perdones.

[Biofix]

Tiene razón Lexus, muy chulo el enlace Adal. Gracias. Por cierto, PP, se me olvidé preguntar, que es eso de los campos lo siento, pero es que, estoy un poco verde en esto. Venga, un saludo. Hasta luego.

[pp]

Lo de los campos es una historia que solo es necesaria cuando vas a sacar algo para televisión. Tú puedes sacar un render muy bueno, y verlo en el ordenador y flipar de lo bien que te ha quedado. Ahora bien, lo pasas a televisión y resulta que fliquea (vibra en algunos sitios), cuando en el ordenador no lo hacía. Esto es porque en televisión la pantalla se divide en 625 líneas horizontales, y cuando se ve, la imagen se compone leyendo esas líneas. Bien, pues cuando se hace esa lectura, se empieza desde el impar. Por eso al hacer el render hay que decirle que saque primero el impar, esto es de manera muy básica el tema de los campos. Probablemente aquí haya alguien que sepa mucho más de esto que yo, y pueda explicarlo más profundamente, y corregidme si me equivoco, pero vamos, resumiendo, que le digas campo impar primero (que vendría a ser el estándar), a menos que el que te haga el encargo te diga lo contrario. Un saludo.

[lexus]

Este. Nada para corregir. Pero creo que se te olvido completar el concepto un poco. Veamos: el tema viene siendo así, por razones que no voy a explicar aquí (para no aburrirlos), las transmisiones de televisión. Se hacen barriendo la pantalla con un haz de electrones que traza línea. (625 en PAL y Secam y 525 en NTSC) desde arriba abajo y de izquierda a derecha y que son las que componen la imagen. Ahora bien, estas líneas no sé trazan todas juntas en un solo barrido sino que, se traza primero la mitad (las impares) y luego la otra mitad (las pares) completando entre los 2 barridos entrelazado) un fotograma completo, o una imagen o cuadro (frame), lo que sucede una vez cada 2 ciclos de potencia de la red (de alimentación). De allí que tanto PAL como Secam tengan una taza de 25 frames por segundo mientras que NTSCtiene 30 frames por segundo (los yanquis usan 60 Hz en sus líneas de transmisión de energía). Dicho de otra forma: en cada ciclo se barre medio fotograma un campo (no la mitad superior ni la inferior sino un conjunto de líneas que sumadas son la mitad de 625 en el caso del pal, 312.5 para ser exactos) y cada fotograma se forma por 2 campos, el primero de los cuales es el de las líneas impares, y el último el de las líneas pares, la velocidad de este fenómeno es tal que el ojo lo percibe como una sola imagen, esta es la razón por la cual si la imagen será visualizada en un televisióndebe respetar su modo de representar las imágenes (por el sincronismo) para evitar ese parpadeo (flickering) del que te hablaban. Saludos.

[pp]

Gracias por tu ampliación, Lexus. Sin duda es muy interesante. Ahora lo tengo mucho más claro, y espero que Biofix también (al fin y al cabo, fue el quien formuló la pregunta). Un saludo.

[Biofix]

Si lo tengo más claro, me vale para hacer una tesis. Muchas gracias a los dos por las explicaciones, hasta luego.

[Basajaun]

Pues yo tengo entendido, que solo es necesario entrelazar cuando la resolución de la película/animación/lo-que-sea es alta. Por ejemplo, está el caso de los Video CD que tienen una resolución muy baja y no necesitan ser entrelazados porque la televisión los visualiza bien. El problema viene con la alta resolución, ya que el barrido que empieza en la parte superior, para cuando llega a la parte inferior ya se ha desvanecido la imagen de la parte superior. Y es por esto, que se visualiza cada fotograma en dos pasadas por así decirlo. Eso es lo que leí en un manual de la página de video edición.

Estaría bien que matizarais un poco esto, ya que no lo tengo muy claro.

[Askelmar]

Hola. El tema de los campos no tiene que ver con resolución o calidad. Es tal cual lo explica Lexus. El tema de barrer una imagen en campos se debe a que, en un inicio, la televisión no era lo suficientemente veloz ni en los sistemas de transmisión ni en los de recepción como para reproducir 25 frames por segundo por segundo (el umbral de la persistencia retiniana) por lo tanto, se debió recurrir al truco de los campos y de esta manera engañar al ojo no pudiendo percibirse los flickeos, hoy en día, toda la industria de televisión está basada en esta tecnología que, aunque parezca mentira es vetusta, pero que no se puede cambiar de un día para otro pues no todo el mundo podría comprar receptores digitales y la industria debería dar un giro de 180 grados en su línea de producción lo que ocasionara miles de millones de dólares de perdida. El cambio se está haciendo paulatino y por ahora conviven las dos tecnologías (vemos un DVD en un televisión común y corriente, por ejemplo).

Yo creo que los consejos de p y la explicación de Lexus completan una respuesta muy buena a la pregunta original. Y los campos solo si se va a enviar la animación a video. Si la misma animación se desea pasarla a algún formato digital yo aconsejaría des-entrelazarla (o sea dejarla como una animación sin campos) para evitar vibraciones digitales o cosas por el estilo (si se hace en mpeg2 no hay problema). Un abrazo.

[Askelmar]

En el idioma de Askelmar -dícese de algo que sucede poco a poco-de manera lenta, pero segura - paulatino, (antes de que Lexus me corrija).