Forum Replies Created
-
AuthorPosts
-
XavierParticipanteltopo wrote:Wow! I guess the virtualization gossip was true after all.
So for you guys and gals a question,
So if you have a Mac what windows aonly program would you like to run?Digital Fusion.
— Xavier
XavierParticipantI vote for HDCAM-SR.
If you can’t get a decent key from SR, chances are your problems are with lighting or your keying technique, not the tape format.
Good luck.
— Xavier
XavierParticipantSapphire Flicker Remove spark creates a channel that’s derived from the average values of the pixels inside it’s analysis box.
I’m sure you could copy that channel and paste it in action and find a way to use it from there.
Good luck.
— Xavier
XavierParticipantQuote:I don’t see why it would be better than a decent DV camera – all you’re doing is downsampling the higher-res CCD, and many DV cameras have supersampling CCDs anyway.I didn’t do side-by-side comparisons with other SD DV cameras. The tests I had to do were to compare with HDCAM to see how big the quality difference was. (In case you are wondering, with careful camera setup and a little love in post, the HVR-Z1U was really close to HDCAM! I was surprised!) So you might be right, a good quality DV camcorder could in theory equal the HVR-Z1U when downscaled to DV.
However, the HDV camera is high-res for the entire processing pipeline up until the very final step: write to tape in DVCAM (in case you decided to turn on the DVCAM switch). I wonder at what step in signal processing a DV camera with oversampling CCDs bump the signal down to NTSC rez?
Quote:It surely is. Have you edited with it at all? Are there ever issues with the GOP length or do FCP and friends completely cover them up?I haven’t tried editing HDV. I think FCP has to convert to the “Apple Intermediate Codec” prior to editing to work around GOP issues.
The tests I did were using the Miranda HDV->HD SDI converter into Smoke HD.
Quote:That is indeed the way to go but it’s a pain in the ass if you’ve got any decent amount of media.Hey, I didn’t say that it was quick! Cheap. Fast. Reliable. Pick any two.
— Xavier
XavierParticipantloops wrote:If you’re doing SD work you’d be better looking at DVCPRO 25 or 50 – HDV is HD-only.Not true. HDV is converted to regular DV on the fly by the HVR-Z1U (Sony’s pro HDV camcorder) if you want to. You just need to flick the switch on the camera. The camera can also record straight to DVCAM if needed. Downscaled HDV gives excellent DV.
The HDV MPEG2 codec is much nicer than the DV codec.
For best results, you can shoot HDV, import HDV in your computer and resize to NTSC with good a good software rescale in a codec that won’t destroy the chroma information like uncompressed, JPEG 90% quality, etc…
Of course, the camera plays a big role. I was impressed with the HVR-Z1U (I guess the FX1 — the prosumer model — should be equally impressive) but was dissapointed with JVC’s camera (a few months ago… they seemed to have replaced it with a new 3CCD model since then).
— Xavier
XavierParticipantClips will become [E]dited for legitimate reasons (like using the Batch timeline). This is normal.
However, one annoying bug is that if you have a clip selected in Batch, and you go to the player while the clip is selected, it will become [E]dited for no reason. You can go to the player through the “Play” button that appears after a render, or you can go to “Reels”, then play a clip from the “crippled” Desktop. Either way, your clip that was meaning no harm to anybody just got [E]dited.
Another way to [E]dit clips by mistake is to click in the clip’s name and hit enter (either by mistake or to put the name in the “arrow up/down” buffer). Even if the name is unchanged the clip will become [E]dited.
I don’t know if these bugs were fixed in later realeases, but they are there in Inferno 5.5.6.
— Xavier
XavierParticipantJohn,
About permissions vs. creative tools: Right now Toxik is a shiny new toolbox, but with very little tools in there! So yes, adding creative tools should be a no-brainer. I mean no curves, regrain/degrain, limited gmasks, no decent keyers, no paint and no plug-ins. Yes, I think all of this is very important to get Toxik off the ground.
But these tools are already there in some shape or form in FFI, Fusion, Combustion, Shake or others. So why should I get Toxik then? AME says: collaboration. In my mind, permissions are as critical as paint or keyers.
About the UNIX permissions model: UNIX permissions have a bad wrap because the output of “ls -l” is definitely not user friendly, and few artists know how to use chmod and chown.
But the model is actually quite simple. Every file is owned by somebody, and every file has 3 sets of read/write permissions. One for the owner of the file, one for the people belonging to the same group of users as the owner (say, compositors, supervsiors, assistants, IO people, etc…) and one for everybody else.
Only people with “write” access can change the permissions, or change the owner of the file. You want to hide clips to other people, just turn off “read” access. I have yet to see a more elegant approach to permissions.
To “grant” permissions, simply give read/write access to the owner of the file, and read only access to everybody else, until the owner says otherwise (through a popup in the library perhaps). Of course, users belonging to the “Administrator” group act as God and can do whatever they want.
Having wide open permissions might be fun for a small team of carefully selected artists, but it becomes a huge liability with a team of 50 people with, huh, varying levels of profesionalism (let’s call it that for now). 🙂
About framestore cache management: lets agree to disagree on that one. Having to sit through slow network playback just to cache a clip is not my idea of fun. Especially coming from FFI, where everything is “cached” all the time. There should be a way to trigger caching in the background, even if the clip is already in the Library. Plus when you move a clip while it is being “import/cached” it breaks the cache. Plus when you render a composition (typically to network) it’s not cached automatically, plus there’s no way to see at a glance what clips are cached which aren’t in the library. To me, caching in Toxik 1.0 is quite crude and I feel it still needs attention devoted to it.
— Xavier
XavierParticipantnanuk wrote:What a post! Thank you Xavier.I didn´t realized danger of “that guy”. But you are right. I thought, there are the different users to handle that. Like Admin and so on. And that you can configure users and their rights. Our reseller told me, that you can even build a user, that only handles the data. Like an assistant. But I didn´t get into that deep enought i guess.
Since there are users already, and one of them is called “Administrator”, I’m sure proper permissions will make it into Toxik very soon. So my point about “that guy” will be moot soon. I was just a bit uneasy when I realized that Toxik, who prides itself with collaboration features, didn’t have permissions built-in from day 1.
Xavier
XavierParticipantnanuk wrote:I fully agree with you Xavier! What do you think about the workflow in the program. With it´s´libraries desktops, working in a compostion?Greetz Nanuk
Nanuk,
I didn’t fall in love with the whole folder/desktop/composition metaphor. But maybe I’m just too used to the FFI way of working.
Basically, after a few days of playing with Toxik, we stopped using desktops altogether. The main reason is because you cannot put any kind of container inside the desktop (the word reel comes to mind!). Even worse, you can’t put desktops inside a folder hierarchy. Also, being an inferno guy, having smoke-style desktops with loose clips everywhere makes me want to take a shower a curled up in a ball like Ace Ventura did when he realized the sargeant was packing an extra weapon.
So we just ended up not using desktops at all and building hierarchies like this:
Folder (… for the scene)
Folder (… for the shot)
Folder (… for the elements)
Clip
Clip
…
Folder (… for the compositions)
Composition
Composition
…We just used the browser to get to our clips/compositions. Since the desktop has no redeeming features (like editing, or reels) we didn’t feel we lost anything by not using the desktop.
Actually, once we started working like that, I was glad I could finally see the *entire* clip names for once, instead of truncated names like the FFI desktop. Plus you can turn on the thumbnails for easy visual access. And everything is nice and tidy, sorted alphabetically, etc…
As for working inside a composition “container” instead of rendering a clip, I liked the idea at first, because I thought I could build one composition, then keep adding versions to it and being able to switch back and forth between setups AND results of the different versions of the same comp. It’s been a few months since I played with Toxik, so I don’t remember the specifics, but it didn’t work exactly as I had hoped; a bit too complicated for my taste. Plus Toxik kept adding ridiculous suffixes to my versions like mycomp_200508051134.sgi or something like that. I would have liked mycomp_v1.sgi, followed by mycomp_v2.sgi etc…
Anyways, these details can be ironed out by AME, but …
This what I understood before Toxik came out:
“OK guys, Toxik is really meant as a collaboration tool, with powerful versioning and clip/setup sharing between artists. However, this is version 1, so all the cool tools you need to deliver shots aren’t there yet. Be patient, we’re discreet, we have the cool tools, they’ll make it in there soon.”
In that light, I was expecting *stellar* collaboration, versionning and media/setup sharing with bullet proof users and permissions handling (but no cool tools). After all, if the R&D didn’t go into the image processing, it must have gone into the workflow.
But instead of being blown away, what I got is the weird feeling in my stomach that the problem of working with “that guy” (you know, the guy who pollutes your framestore with hundreds of loose clips, that has entire reels of untitled clips, that overwrote one of your desktops by mistake — sorry dude! — etc…), well just got bumped to a facility wide problem! It’s “that guy” that will be the demise of Toxik unless AME makes it A LOT MORE dummy proof than it is right now.
For what it’s worth, I like Toxik’s design spec much better that FFI’s for the type of job I do daily, mainly:
RGBA architecture (hooray no double clips!)
Floating-point support (welcome to the 21 century!)
Local high-speed storage handled out of the box (no scripts to create local proxies)
Full screen from disk player (flipbooks are so 1999!)
Clips contain the setups that created them.
Windows based. (I hate windows, but I have to admit that switching to other popular apps without switching boxes is cool)
Designed with high-rez, high bit depth images in mind.
100% node based — no mismatch between desktop tools and “batch” tools.But I do wonder, by the time Toxik is ready for prime-time, where will Digital Fusion (an underestimated contender, IMHO), Shake and Nuke be?
I guess I’m eager to see how big a change will be 1.1 vs. 1.0 to see the pace of development of Toxik. If it’s fast enough, they might have a chance to get a chunk of the high-end feature-film market. If it’s too slow, Shake will stay the popular kid in school for a little while longer.
Anybody knows what made it into 1.1 that wasn’t there in 1.0?
— Xavier
XavierParticipantHi,
We had a look at Toxik 1.0 release and although I was quite aware that there would still be a lot of rough edges, I was expecting a little more meat around the bone. I don’t know about the new stuff that will make it into version 1.1 and beyond, but as of version 1.0, here is a list of showstoppers for us. (By the way, if we did get Toxik, it could have been used in a large-ish team (10-20 compositors), on 2K or HD feature-film work. So we “fit the profile” so to speak).
1. Permissions and users management.
The whole collaborative environement isn’t quite ready for prime-time because it’s lacking UNIX-style permissions for footage and compositions. As of 1.0, everybody can move, rename and delete anything in the (facility wide!) library.2.Chroma keyers.
Discreet should move the 3D keyer, master keyer and “regular” keyer to Toxik ASAP. The “diamond keyer” cannot be used seriously for a wide wide range of keying jobs.3. Garbage masks.
Flame has them. Smoke has them. Combustion has them. Why did they reinvent the wheel for Toxik? Toxik needs tracer-style tangent softness and multiple shapes per gmask nodes and host of other tweaks for it’s gmasks to be taken seriously.4. Deformation tools
Toxik needs bicubics, extended bicubics, warper and deform type tools.5. Paint.
Toxik needs a decent paint system, vector-based or otherwise.6. Plug-ins.
As of version 1.0, no commercial plug-ins are available for Toxik. We need Sapphire, Furnace, Speedsix, RevisionFX and all the other stuff to deliver shots! Come on AME, surprise us with AfterEffects plug-in compatibility like Digital Fusion did!7. Curves.
Even though the color corrector is probably one of the more mature tools in Toxik 1.0, it is mysteriously lacking curves, an essential part of a balanced breakfast!8. File Format compatibility
No support for QuickTime and Softimage .PIC files.9. Frame index slipping.
Toxik should steal a page out of Shake’s book and automatically slip clips according to their frame index. (For instance an image sequence numbered myclip.0050.sgi to myclip.0100.sgi would start at frame 50 in the composition, not frame 1).10. Macros.
Shake wouldn’t be on anybody’s radar if it weren’t for it’s macros. Don’t have the *right* tool built-in? No problem I’ll make it myself. Toxik needs macros pronto.11. Cache (framestore) management.
Toxik 1.0 doesn’t tell you if a clip is cached to local disk or not, nor does it let you cache a clip if it has already been imported to library without specifying “import/cache”.— Xavier
XavierParticipantjohnmont wrote:No…its actually not a limitation of marketing, but a hardware issue. As much as I have issues with product marketing decisions (like no MK in flint, for instance)…can’t put the blame there this instance.How do you explain that Burn renders 12bits just fine on Linux then?
— Xavier
XavierParticipantamilkis wrote:If you try to copy 10 or 12bit material from another discreet system, or filesystem to a linux product, it is reduced to 8bit. That is a limitation of the hardware — the NVidia board used for graphics is 8bit only.-Andy
I think this is a limitation of marketing. Octane and Onyx2 have 8 bit graphics too and they render 12bits just fine.
Shake, After Effects and Fusion can all render at 16 or 32 bits on hardware similar to Flinux.
— Xavier
XavierParticipantI doubt that running flame remotely will give you a good user experience. Remote graphics (VNC, rdesktop, etc…) isn’t very good quality (color depth) or very snappy (sluggish refreshes).
Why don’t you want to sit at the Octane?
Because you don’t want to have to teach IRIX?I wouldn’t worry about that. All the students need to know is one command: flame. Everything else (well… everything you would teach in a begginner’s class) is taken care of within the software.
— Xavier
XavierParticipanthttp://www.apple.com/pr/library/2005/jun/06intel.html
http://www.intel.com/pressroom/archive/releases/20050606corp.htm
Hear it from Steve-o himself: http://stream.apple.akadns.net/
Lots of coverage here: http://www.macrumors.com/
— Xavier
XavierParticipantThanks!
This is exactly what I was looking for!
— Xavier
-
AuthorPosts
