this is an animation done for a music program.
animated completely is ASP, composited in AAE (used AAE mainly beacause i had some problems with interlace flicker)
comments please
animation for music program
Moderators: Víctor Paredes, Belgarath, slowtiger
animation for music program
http://www.youtube.com/watch?v=tXuNSZr_T2U
this is an animation done for a music program.
animated completely is ASP, composited in AAE (used AAE mainly beacause i had some problems with interlace flicker)
comments please
this is an animation done for a music program.
animated completely is ASP, composited in AAE (used AAE mainly beacause i had some problems with interlace flicker)
comments please
thanks a lot jahnocli!jahnocli wrote:Ooooh -- you mentioned interlace flicker, but I think you got away with it...I liked the 2.5D feel to it; could have done with a little faster cutting (maybe MTV has totally messed with my head...). Ithought it was pretty good though -- well done!
you cant see much detail on youtube, but i used some blur and such.
but even with these...there is still a tendancy to flicker in the final braodcast (mainly with fine, non horizontal lines)
and i had a lot of problems with color burning, still finding out the safe area in the color picker
but why "ooooh interlace flicker"?
I watched the high quality version, and it was totally OK. Not a single glitch visible. There is especially no "interlace flicker".
Of course there are a few problematic areas when producing content for TV broadcast. One is, as you correctly note, the colour space you use. The RGB space we use on computers is definitely bigger than the TV colour space, so if we are not careful enough we might pick colours which are too saturated for TV.
The other problem is small, nearly horizontal lines of less than 2 px width. If these have a high contrast, like shiny white lines on dark bg, they tend to flicker in the broadcast. This problem only existed sincs TV graphics and animation were done digitally. In real world it rarely happens, and only on occasions like thin tree twigs in front of a bright white sky.
Both these problems can be avoided. One measurement for the second is to blur the affected areas. The other would be to add some kind of noise, like film grain, or some other texture (preferrably moving).
Of course there are a few problematic areas when producing content for TV broadcast. One is, as you correctly note, the colour space you use. The RGB space we use on computers is definitely bigger than the TV colour space, so if we are not careful enough we might pick colours which are too saturated for TV.
The other problem is small, nearly horizontal lines of less than 2 px width. If these have a high contrast, like shiny white lines on dark bg, they tend to flicker in the broadcast. This problem only existed sincs TV graphics and animation were done digitally. In real world it rarely happens, and only on occasions like thin tree twigs in front of a bright white sky.
Both these problems can be avoided. One measurement for the second is to blur the affected areas. The other would be to add some kind of noise, like film grain, or some other texture (preferrably moving).
the thing with details is that, when you have fine details (ex. fine black lines on white back) if the lines are too thin they merge and become Grey, or if they are too large. the lines look rough.
i used to make all the projects double PAL size and when i rendered a frame
the preview would fill up the whole screen, and all the fine detail would be very clear. (this can be very misleading)
but when you finally render it and look at it in a broadcast monitor, the drop in resolution and color depth has a blurring effect. and if there is contrast, flicker. now i only change to double size AFTER i finished the animation and am ready to render.
and color is the same thing. i used to 'look' at the color on the monitor and chose it. but a senior animator at work told me to always look at the RGB values when i chose colors. and you cant compleatly rely on the 'broadcast colors' filter that you find on AAE. i'm still hazy about that whole thing.
and i'm learning now that if you want to have a bright seeming red text, you cant just put the text with the fullest saturation of red and expect the viewer to say 'ahh thats brights red' you have to think of the whole composition, (ex: changing the background color, can change how you see the red text)
sorry if i rambled
thank you slow tiger for commenting!
i used to make all the projects double PAL size and when i rendered a frame
the preview would fill up the whole screen, and all the fine detail would be very clear. (this can be very misleading)
but when you finally render it and look at it in a broadcast monitor, the drop in resolution and color depth has a blurring effect. and if there is contrast, flicker. now i only change to double size AFTER i finished the animation and am ready to render.
and color is the same thing. i used to 'look' at the color on the monitor and chose it. but a senior animator at work told me to always look at the RGB values when i chose colors. and you cant compleatly rely on the 'broadcast colors' filter that you find on AAE. i'm still hazy about that whole thing
.and i'm learning now that if you want to have a bright seeming red text, you cant just put the text with the fullest saturation of red and expect the viewer to say 'ahh thats brights red' you have to think of the whole composition, (ex: changing the background color, can change how you see the red text)
sorry if i rambled
thank you slow tiger for commenting!
i use png sequences for final render. i find this better in terms of file size than Targa.
but if i use a flat color (without any textures) there is a tendency for the color to become unstable (oversaturate and clip).
i read some where that the PNG format has can have the problem of gamma shifting when you move between software. anyone know anything about this?
but if i use a flat color (without any textures) there is a tendency for the color to become unstable (oversaturate and clip).
i read some where that the PNG format has can have the problem of gamma shifting when you move between software. anyone know anything about this?