View Full Version : computer can't handle workflow?
Josh Bass June 23rd, 2010, 02:04 AM So, working on an animated project.
I decided to export HD image sequences from my animation program, rather then use QT movies. This was recommended by the folks on the message board for that animation program as the best way to maintain high quality, and I've personally seen some glitches result from trying to encode movies.
So, in FCP, you can't really use image sequences. What you have to do instead is open QT pro, and take the images and make a reference movie out of them.
Ok, so I have my references movies that contain my HD PNG image sequences.
I have a sequence with the following settings:
1920x1080, square pixel aspect ratio (this is from the animation program), compressor (codec) = PNG (image sequences are PNG).
I would think you would want your FCP sequence to match the settings of the image sequences which is why I chose PNG as the compression setting. However, I get a big red box in the canvas window that says "cannot display, close window and reopen" or something. If I actually do close, and reopen, I get a "general error: out of memory" message. Seems my imac cannot handle PNG compression in this context.
Is there a less robust/taxing codec I could use for this project and not lose quality? Pro Res HQ or something? There are so many codecs and I don't know what most are for.
Romuald Martin June 23rd, 2010, 07:06 AM I guess you may use QT Uncompressed or go for the ProRes 444, which provides close to Animation codec quality in a smaller file. (ProRes 422 don't store all color values for pixel). Just be aware that there are some players than don't support this codec if you need to send the file somewhere else.
William Hohauser June 23rd, 2010, 08:33 AM Is there any reason you need to keep the sequences as reference movies once you bring them into FCP? You are making FCP refer to each individual frame as it's working if it's a reference image sequence. That's a lot of work. Use the animation codec to make movies it's uncompressed but you'll have to render it once it's in the sequence. You've been working at this for a while now, what's your final goal with the animations? Knowing that would help streamline your process.
Josh Bass June 23rd, 2010, 08:53 AM I'm a little lost. . .do you mean why didn't I just make a movie out of the image sequence instead of keeping it as a series of stills?
I guess I hadn't really thought about it. I'm also planning to apply a broadcast filter to the whole movie to clamp down the whites (I have another thread about this). Maybe I'd lose something if I turn the stills into a movie?
I have the sequence setting set with the animation codec right now (I read up on it in the FCP manual right after I started this thread. . .manual says it's lossless), and it's not crashing anything so far.
William Hohauser June 23rd, 2010, 09:35 PM A reference movie is a container that houses the file locations of the original media and the sequence they play in. A self-contained movie is a new file with all the media in one place, filters and effects are rendered but all the other media are just a one for one data transfer unless you are changing codecs. Good luck with the animation codec.
Josh Bass June 23rd, 2010, 10:51 PM Right. I did all my editing already. . .using very low res proxies. I tried to wait 'til I was sure everything was perfect before doing the "uprez".
Do you think there's a benefit to using self-contained movies in the timeline as opposed to reference movies to the image sequences?
When you make a series of stills into a self-contained movie using QT pro, you have the option of leaving it as a reference or making a new, self contained movie. I don't know what, if any compression it applies when making a new movie.
I'm not planning on doing much playback in the new HD timeline or anything.
Shaun Roemich June 23rd, 2010, 11:51 PM Do you think there's a benefit to using self-contained movies in the timeline as opposed to reference movies to the image sequences?
When you make a series of stills into a self-contained movie using QT pro, you have the option of leaving it as a reference or making a new, self contained movie. I don't know what, if any compression it applies when making a new movie.
Benefit? LAWZ, yes! A reference movie OR an image sequence causes the hard drive to go looking for INDIVIDUAL files at a rate equal to your frame rate instead of a stream, such as when you either import all the stills and render out a file (not just render the timeline) or create a movie FROM your image sequence.
Making a movie self contained means it creates a complete self standing movie with all the data included. A refernce movie is merely pointer information that references OTHER media files, in this case your PNGs.
Shaun Roemich June 23rd, 2010, 11:53 PM BTW, I used to do a TON of this when I worked multicamera sports lives - my brother would render out images from Lightwave of whatever crazy 3D animation we were going to use to pump up the crowd and I'd import the images, place them in a timeline, render the timeline and then EXPORT to a QuickTime for subsequent playback in real time.
Josh Bass June 24th, 2010, 12:57 AM Would there still be a benefit if I'm not planning to do any more playback? My next step should be outputting to some final format.
Like I said, the animation codec seems fine with the ref movies/image sequences. If making self contained movies will speed up export/rendering later, that's a reason to use them instead of ref movies.
Shaun Roemich June 24th, 2010, 03:47 PM Most important: if you are planning to take your files off YOUR computer, they NEED to be self contained.
Josh Bass June 24th, 2010, 04:24 PM That shouldn't be an issue.
Craig Parkes June 24th, 2010, 08:23 PM Hey Josh, to be able to smoothly playback image sequences referenced from a quicktime file you will need a very fast RAID. CPU overhead isn't as big a deal, but raid speed is. Unfortunately with an iMac you are limited to an external raid running on Firewire 800, which is probably going to be too small a pipe for the sort of data transfer rates you need.
The question of course is what is your delivery format, because that will dictate how you should finish your project and what codecs to go to, what software to use, and whether you can do it yourself or need to go to a post house for delivery.
So are you going to tape (HDCAM-SR), film, DCI, or what. You're going to have to do some processing to get out to any of those formats, and the format you are going to will determine where in the pipeline you need to do your processing and what format you should output to as to avoid quality loss.
The thing you have to remember is that in 99% of cases a practical workflow for you is more important than avoiding quality loss at some point - there is ALWAYS some lost quality from acquisition/creation to a distribution format. You can work very hard to minimize it, but currently there is no such thing as an affordable, simple, visually lossless production/post production pipeline - and certainly no distribution method that is readily available that allows for a completely lossless process.
For what it's worth - my recommendation would be to render out to PRORES HQ, or PRORES4444 if you are running FCS3 and what the absolute best quality - PRORES4444 is about as generationally lossless as you possibly can get using your current apps, handles up to 12bits of color data per channel and CAN be RGB instead of YCb'Cr' (athough you may need to use Color as your renderer to ensure true RGB output - I don't believe you can get there using Final Cut's rendering engine).
Animation codec is actually a little archaic as it only supports 8bits per pixel of information, so I would avoid ANIMATION codec if at all possible (assuming you were working in more than 8 bits per channel to begin with, and/or are doing grading etc.)
Josh Bass June 24th, 2010, 08:44 PM Distribution methods/formats will be whatever various folks require. I'm not looking to keep it "perpetually uncompressed", but to avoid doing 'til the output stage.
I'm not real versed in the RGB vs. YC whatever whatever. . .I've always worked in whatever FCP defaults to.
If you say prores HQ is better than animation, than so be it. I'm limited to whatever comes with FCS2, however. Couldn't tell you about 8 bit vs 10 or 12. . .It'd be whatever anime studio (the animation software) generates, and I'm not sure what those specs are (PNG-based image sequences from a vector-based program).
W
William Hohauser June 25th, 2010, 12:14 PM My understanding of the Animation codec is that the bit depth is dependent on the program encoding the file. A program working in 16bit will export an Animation file at 16bit. And if there's an alpha channel in the file the file will be 12bit at the minimum. That's my understanding, perhaps it's wrong. The Animation codec is theoretically good up to 32bit. If the animations don't use alpha channels then ProResHQ is good but if you need an alpha channel for layering in the FCP timeline then ProRes4:4:4 is the way to go otherwise the Animation codec should work.
Josh Bass June 25th, 2010, 12:52 PM No, no alpha channel. Anime studio can do that, but it wasn't working for me when I tried to use it for a few shots. I just put things against a solid green background and keyed it out with the chroma keyer in FCP.
FCP Manual doesn't mention bit depth of the animation codec, just says it is "lossless" but does use compression, as opposed to the uncompressed setting.
Craig Parkes June 26th, 2010, 03:18 AM All the documentation I can find suggests Animation codec is no more than 8 bits per channel, an example of this is here:
Apple QuickTime RLE - MultimediaWiki (http://wiki.multimedia.cx/index.php?title=Apple_QuickTime_RLE)
PNG can handle up to 16 bits per channel, but I am unsure whether Anime Studio is exporting at 16 bit per channel bit depth and whether your animation requires such accuracy.
It sounds like you have some pretty major issues with your workflow already though, if you are chroma keying rather than exporting a clean alpha from your animation program - but not knowing the complexity of your animation it may be more or less irrelevant.
Your Final Cut timeline settings also matter, and if you are not viewing the final work on an external video monitor and are rendering in YUV rather than RGB you will not be seeing the exact same color rendition as what you would get on a monitor (excluding broadcast safe issues etc.)
But the main point being, without a known deliverable format, none of this really matters. If you have the quicktime reference files already, you can render a sequence out in ANY format simply by duplicating the sequence and changing the codec to the one you want and hitting render. This rendered sequence will then playback fine as long as your machine is spec'd high enough to play a single stream of it (your machine should handle full HD Prores fine as a single stream).
Then, once you know your delivery format, you can go back and re-export the Quicktime Reference files to the best format (or simply supply them as image sequences) to an online editor and simply reconnect the media in your timeline. The issue that comes in here is that any transitions (dissolves/wipes etc) and grading you have done may need to be recreated in the online - but this is par for the course in terms of professional finishing.
Josh Bass June 26th, 2010, 04:31 AM Yeah, I tried the alpha channel thing, and it was not seeming to work. I'm sure somehow it was my fault, but since I only needed to key things out for one little part, I figured screw it and used the chroma key technique.
My master plan with all this is to make a high quality 1080p movie, I guess in prores HQ, from all these image sequences, etc., and then downconvert as needed from that file for whatever other formats are needed.
Or, more likely, not even make a "master file", but simply make my sequence prores HQ, render everything, and bring a ref file of the whole sequence/project into compressor to make whatever's necessary as those things come. Or like you said, I could simply make new sequences and change the codec, and rerender, etc. Not really worrried about PLAYBACK with these image sequences on my computer (or anyone else's) . .I was worried that my computer couldn't even handle the footage period. But apparently that was just the BMP and PNG sequence settings. . .whatever they are, they're too much.
So either animation codec or this prores HQ (I'm on FCS2 and I don't see a prores 4:4:4 option). The only reason I really worry about needing super uncompression for this is that there are some auras/gradients/transparencies in the movie, not just solid blocks of color. Also fine detail in place like where I have a marble texture on a floor.
Craig Parkes June 26th, 2010, 04:56 AM As you are dealing with gradients definitely stick to 10 bit and above, also make sure that your sequence settings are set to render in High Precision YUV, as that will ensure a 10bit workflow, and render out to ProRes or ProRes HQ. That will create the least chance of introducing banding at this stage.
I just realized in your case not being able to playback the quicktime references to image sequences isn't just a harddrive thing - it could also be a RAM and GPU thing. If they render to another codec on the timeline fine, then go with Prores HQ and High Precision YUV for maximum quality (or at least max quality in a final cut timeline).
Josh Bass June 26th, 2010, 05:01 AM Thanks.
I don't really know much about YUV/RGB. There's no way using YUV could screw me later is there?
This imac has 3GB RAM (its max).
Craig Parkes June 26th, 2010, 03:59 PM Not really, pretty much all standard video is delivered in YUV (also known as YCb'Cr') format on television/bluray etc.RGB is used in computing, and digital cinema projection is delivered in a different colour space altogether.
RGB is more 'true' to your originating format because everything is being generated in a computer, but the Colour Space conversion isn't a big deal at all in terms of delivery. The reason I suggest switching to High Precision YUV is that Final Cut Studio 2 can only handle 10bit rendering this way, it can't do 10bit RGB rendering, so you'll be stuck with 8 bits of colour depth per channel if you stay RGB.
Of course, I haven't been able to find info on Anime Studios export options and what bit depth it's exporting it's images too. You might be able to check this by opening up one of the PNG images in Photoshop etc and checking what it's bit depth is listed as though. If it's only 8 bits per channel (24bits or 32bits total including alpha) then you would be fine with 8 bit RGB and animation codec.
One thing really complicating matters in terms of checking things is that your iMac's screen is only going to show 8 bits worth of colour information, so if that's what you are visually checking it on you may see banding on your screen, where in fact there actually isn't any - it's just your screen doesn't have enough precision to display the image without banding... Increased Bit depth however should not cause banding, so if you are not seeing any banding on the gradients you are probably still safest at the higher bit depth, because it will mean there is more data for later down conversions later on to work with so compression/scaling is less likely to introduce banding, or if it does a more mild dither could be applied than if the entire project was stuck in 8 bit.
Josh Bass June 29th, 2010, 10:03 PM Thanks. I don't know jack about photoshop outside of some tricks, so how do you use it to find bit depth? I tried opening a png in there and going file/file info, but it doesn't mention it there (CS2 by the way), but at the top of the photoshop window, it has the file name, then RGB/8. . .I'm assuming this means RGB 8-bit?
Also, tried changing sequence setting to render all YUV material in high precision YUV, and I get a message about how at this size, with my graphics, card "solid color" cannot be rendered (I use several generated layers for titles and such)
Per Johan Naesje June 30th, 2010, 09:31 AM Josh, first of all have you allocated more ram for your still images by choosing system settings and clicking the memory and cache tab (view attached thumbnails). Itīs recommended to set the still cache to between 15-20%, but no more than 20%!
This could maybe help you in playing the still-sequences better?
Another thing, itīs not recommended to import large numbers of individual images into fcp, even if you adjust the still image cache settings!
You should instead use Quick Time Pro, selecting file - open image sequence, then file - export to a quicktime movie. Set the codec to ProRes 4444 if you are on fcp7 or quicktime animation if you are on a earlier version.
Josh Bass June 30th, 2010, 10:38 AM Have not messed with still cache yet. When rendered, plays back fine.
Yes, I have been making the images sequences into QT ref movies in QT pro. I haven't been "exporting", just doing a save as after "open image sequence" and selecting the first numbered still in the sequence.
As far as codecs, someone above said prores HQ was better than animation, as animation was limited to 8 bits/channel. . .I think the stills are 8 bit anyway but I don't know how to check.
Craig Parkes June 30th, 2010, 04:41 PM Hi Josh, as your PNG's are only being exported as 8 bit per channel (you were correct in your assessment of the RGB/8 info) then Animation is going to be fine in terms of bit depth - although you may run into an issue with the bitrate of Animation at Full HD on your machine - your Hard Drive may not be able to keep up with FULL HD animation codec.
Full HD Uncompressed Animation Codec requires a playback bitrate of about 165 megabytes per second - You can't actually keep a constant playback using Firewire 800 at that bitrate because the maximum pipe size you've got is about 100 megabytes per second (Firewire 800 is 800 megabits/second = 100 megabytes.) and the internal drive on the imac is certainly going to struggle with Animation Codec and keeping the OS running.
Comparatively Apple Prores HQ is about 23 Megabytes per second, which your hard drives will handle fine. So while it's not going to give you an advantage in bit depth, its the best codec in your system in terms of playback.
Josh Bass June 30th, 2010, 05:29 PM Thanks. I went back to RGB, prores 422 HQ. Looks fine to me.
|
|