Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Have a Scratch on a Mac

I don't understand how you would even know that you had to do that, seeing as how there's no way to compare a timeline with an offline reference. It amazes me that people use it for DPX conforms with this limitation, as I've never seen a DPX conform that was "perfect" without some frame manipulations here and there - but you need to actually be able to compare it, frame by frame, to the offline to determine that.

Well in this case it was reconforming against edit changes I made myself. I've only very briefly experimented with a DPX conform in Color, and it didn't look that pretty to be honest. There were certainly offline clips where I'm fairly sure there shouldn't have been. As best as I could tell there is basically no reliable way to fix those problems in Color. You'd have to go back and massage the EDL in a text editor I suspect.

It's certainly not well suited to that. I think the value of Color when not being the last step in a FCP edit is pretty minimal (even then there are a lot of hoops to jump through with 'baking' speed changes and many effects).
 
As a color grader, Color seems pretty good. There are some really annoying things that people seem to bitch about consistently, but that is true with any program!

I would agree with that. If you feed it in a data-centric version of how you feed a DaVinci - in other words, load an already conformed sequence or QT movie and an assembly EDL to provide notches - it works fine. It's when you try to make it a full DI-type system, and try to instill it with conforming capabilities that you quickly hit the limitations.

That, and the inability to play the material in real time. And the slow renders. And.....

But it **is** a nice color corrector. ;-)
 
Darren,

Thanks for the kind words... but Color supports the CP-200 series as well. ;)

Lucas

I thought that Color requires that you use LAN base interfaces. I not completely keen yet on the CP-200 series yet but does the CP-200 support LAN. Maybe its the wave i am thinking about.

-posted via mobile phone....
 
No Wave support on Color yet, although they've said they would. It should be trivial to make a virtual LAN interface to run on the host computer and interface with the USB (I think) Wave.
 
It's a little odd, but the workflow between FCP and SCRATCH is worlds easier than the workflow between FCP and Color.
I totally agree with you Lucas, especially if you work with DPX and R3D files.
I've test it for myself.


As a color grader, Color seems pretty good. There are some really annoying things that people seem to bitch about consistently, but that is true with any program!
Color's tools are great, every colorist (I've met) that have used it mostly said "it's a great software".
But when it comes to workflow and stability, it is :angry03:

I really hope someone will buy Color from Apple and make it a powerfull stand-alone DI software :shiftyph34r:
 
I really hope someone will buy Color from Apple and make it a powerfull stand-alone DI software

You are aware that Apple themselves bought this program from a company that was attempting to do just that and couldn't quite pull it off (at least on Apple hardware)?
 
You are aware that Apple themselves bought this program from a company that was attempting to do just that and couldn't quite pull it off (at least on Apple hardware)?
Yes, I was using FT HD couple years ago.

At first, I was very happy when Apple bought FT from Silicon Color.
But then... it was a drama :sad:
 
Ok, so...

This is my opinion, and keep in mind that I work for a manufacturer. ;)

The main issues that I see people running into with Color are all about workflow. The process of Publishing to color and going back leaves a lot to be desired.

Since Color has *no* editorial capability, if the list is anything less than perfect going from FCP to Color, then the only way to fix that is by going back to FCP, re-editing, and re-publishing. If you have already done some grading in Color, then you have to export out of Color to FCP, cut in the exported sequence from Color, re-edit, then publish back out of FCP.

With R3D material, these problems are compounded because Color does not yet natively support R3D, and FCP does via QT Ref. So if the list is wrong, there are the problems of publish/import/export/re-import/re-publish, etc. Keeping editorial changes coherent over a long show with typical editorial turnaround times becomes very difficult. But beyond that, there is also the transcode between R3D, Quicktime, and DPX. Keeping color spaces coherent, and making sure that colors stay the same through that process is not easy.

It's a little odd, but the workflow between FCP and SCRATCH is worlds easier than the workflow between FCP and Color.

To go from FCP -> SCRATCH, it's a list export and relink to R3D files. Bring in a Quicktime for offline reference. And if there are editorial errors, they can usually be corrected in the Edit timeline in SCRATCH. Re-conforms from editorial are easy, and color grades and animations keep track with editorial changes and reconforms.

As a color grader, Color seems pretty good. There are some really annoying things that people seem to bitch about consistently, but that is true with any program!

I'd welcome any other opinions. Someone drag Roland out here and let him rebut this or lend his opninio! This is the sort of discussion that I'd like to see a lot more of on Reduser!

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA


Lucas- This is your best written argument of Scratch over Color to date. And it's gone a long way toward convincing me of Scratch's advantages. But I speak from years (nearly decades now) of experience trying to integrate PCs into Mac workflows, and it's never worked out long term. Just too many complications, inconveniences and incompatibilities (lack of equality in QuickTime codecs, inconsistent networking and employee dissatisfaction of dealing with Windows being the largest problems today).

In most of your sales pitches for Scratch you've emphasized speed. I'm sure the speed of Scratch is great. But all of the advantages you mentioned above are software, not hardware or speed related. All I want is a software-only (less-than-realtime is okay) Scratch for Mac that's fully compatible with all the Mac QuickTime codecs and doesn't require XP to be anywhere near my machine.

I know porting isn't easy, but these days, it doesn't seem all that hard either. Like I've said before, you'd have my money.

When I've gone on this rant in the past, you've been good about replying, so feel free to ignore my persistent requests from here on out, but I'm going to keep asking... Just like I did for Lightwave on Mac. And eventually it happened, much to the boosting of NewTek's bottom line, I might add.
 
Just to put some more personal experiences into this thread.

On a bootcamped MacPro the 5600fx does work nicely with the Windows Nvidia drivers. I'm using this kind of setup for Speedgrade wich relies entirely on the same hardware as Scratch does.

Actually even the Nvidida SDI board does work in a bootcamped Mac. The big downside is that you have to pull the card when booting OSX...

The problem with Red's SDK is you need a fast, really fast CPU power to make a full 2K /1080p or half 4K debayer in real time happen. MacPros are to slow for that. And I'm sure that only a (safely) overclocked PC can accomplish that.

Although Scratch claims that they don't need to work with Red's SDk they still need extreme high power to debayer 4K R3D in half in 24/25 fps RT. MacPros won't cut it - yet.

All the colour manipulation is done by the Nvidia board anyway. And those boards are amazingly fast. Also in the Mac - but you need the support of the app. Only very few OSX apps. take advantage of the power of the Nvidia 5600fx (Maya might be one and of course SpeedGrade). This is the reason why a 5600fx is so rarely sold for the MacPro. And because only a very few 5600fx were sold, Apple sees no reason to develope a driver for the SDI board. No SDI board, no DI suite.

This might change in the future when the new 10 bit DisplayPort will become the new standard for high-end DVI monitoring. But for RT lay-off to tape and proper level monitoring you will still need a SDI board - or a least a not yet existing DisplayPort to HDSDI converter.

I would hold my breath until NAB, wait what the new MacPros are like, wether Mac will finally (doubt it) support Nvidida SDI and make my decision from this future knowlede.

If you need a DI suite now, you need to go the PC route.


Hans
 
Back
Top