It sounds like there is no GPU assist for this plug-in. I use the Color Match Fx in Vegas quite often with GPU on. If I render with CPU only, the render times increases dramatically by an order of 13--very slow!!

wwaag

Here's my original post. http://www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=872603

Lots to catch up on, so let me start by saying a few words about the performance:

First of all, the color matching involves three different calculations: 1) analyzing the original and reference frames, 2) computing a color match transformation, and 3) applying that transformation to the input frame. There are different takes on how to best approach an automated color matching, but the way I did it, 2) is by far the most computationally intensive step. At the same time, the complexity of 2) greatly depends on how "different" the two frames are (again, this is "different" in the mathematical terms of the algorithm, which may or may not match our own notion).

Some consequences of this are:
1. Constant mode is much faster than continuous mode because steps 1) and 2) are done only once and only step 3) is done for every input frame.

2. In continuous mode, the only thing that does not depend on the input frame is the reference frame, so all that can be cached is its analysis result. Everything else has to be recomputed for every single input frame, so there's just much more going on in the background than in constant mode. Note that continuous mode isn't "better" than constant mode, it simply solves a different problem.

3. While in constant mode the performance won't vary much for different inputs, continuous mode may perform reasonably well for some parts of a clip while producing a very unhurried slide show in others.

4 a) If you use continuous mode to match a grade, you may get much better performance by first applying that grade to the target clip before adding the color match. Even if the original grade may not produce the results you want for a particular frame, it may reduce the "difference" the color match plugin sees and thus shorten the computation time. BUT (and that's a very important but) if your project is in 8 bit mode and your grade causes highlights or shadows to be clipped, these areas will be lost before they reach the color match effect and thus cannot be restored. To be safe, you'd have to use 32 bit mode and the question would boil down to: Can you save more time in the color matching by making the input images more similar than you lose by switching to 32 bit mode?

4 b) You can also try the reverse method: Color match first to even out variations, then apply the grade. Again, this should be faster because the ungraded frames within the clip should be more similar to each other than to a graded frame. This method has the advantage that you have the option of using the Shadows and Highlights controls in Graide Color Match to create kind of a flat look with reasonable headroom to prevent clipping between the color match and the grade.

About GPU support: Graide Color Match does not currently use the GPU for the correction itself. This is partly due to the fact that the current Sony Plugin SDK framework does not seem to contain any support for GPU acceleration. The documentation, however, says Vegas does support the OFX GPU interface and the internal effects obviously use it, so it may just be a matter of figuring out how to do it. I may look into adding GPU support in the future but I'm not quite sure where to put this priority-wise.

About OFX working with every compatible host: Unfortunately that's only half-true in this particular case, because OFX does not have "image" as a parameter type. That's why RE:Match requires you to use it as a composite effect with two separate tracks if you need two inputs and why Graide Color Match absolutely depends on you using its custom GUI to get those images into the effect. Vegas uses a few custom extensions to the OFX specification and the possibility to create custom GUIs is one of them. This most likely won't work with any other OFX host. The Sony Color Match effect uses another custom and not publicly documented extension that lets it use image parameters, but I haven't found a way to use this feature from a third-party plugin.

About feedback: I appreciate feedback both positive and negative. Coming from a research background, I'm somewhat used to having my work taken apart by reviewers ;) People will certainly need a certain amount of positive feedback or they'll eventually stop what they're doing and just do something else, but negative feedback can help to remain aware of the flaws in your products and plans and, as in this case, point out new opportunities. I think it's a matter of listening to and taking into account as many opinions, wishes, and pieces of advice as you can, while being very aware of the fact that you cannot ever hope to satisfy everyone. Unless your product is free beer, that is.

I updated my post above with continuous times & the average.
Interesting results! So the image used to adjust with can result in wildly different render times. That makes using benchmarks that use different footage pointless. I'll post the footage & images I use once they're uploaded.

40 minutes for rendering 20 seconds does seem a bit excessive, although, as you said, that's hard to judge without knowing the footage and hardware involved.

For comparison, I just rendered out just the "Undo exposure changes" sequence from the trailer after removing the text and the split screen (having Color Match continuous on the full frame). My results:

Sequence duration: 10:04 (= 254 frames)
Format: 1920x1080, 25 fps, 8 bits per channel
CPU: 8 logical cores @ 2.35 GHz
Renderer: MainConcept AVC/AAC (CUDA encoding)

Render time: 1:07 minutes.
(Render time with Graide Color Match bypassed is 45 seconds.)

That's a factor of roughly 7:1. I realize you've got a different CPU and different footage, but I wonder if that alone would account for your factor of 120:1.

Here's my footage & two images: https://onedrive.live.com/redir?resid=87EF11681E021EBF!9997&authkey=!APENX7aq1vzvGCA&ithint=file%2czip[/link

It's HDV 60i footage and I rendered to HDV 60i mpeg-2.

I have to admit it's a bit of a mystery to me why this would run so slow on your system. I loaded your clip into Vegas 13, added the Color Match to it, and rendered it out to HDV 60i.

Constant, Still 1: 0:29 minutes
Continuous, Still 1: 1:42 minutes
Continuous, Still 2: 1:29 minutes
Continuous, Still 1, 32 bit processing: 1:58 minutes

I then fired up Vegas 10 and ran the tests again. While the constant correction still finished quickly, the continuous correction suddenly took 3:22 minutes (for Still 1). I then tried Vegas 11 and got 1:42. I don't have a good answer yet on why it would take twice the time in Vegas 10, but I'll be sure to investigate this a bit further.

Someone with a system similar to mine would confirm if it's my hardware. Not sure if there's many Phenom users on the board here.

EDIT: Vegas 10 doesn't support GPU, 11/12/13 does. Could be it's using GPU in some capacity.

OFX may have been introduced in V10 but was problematic in implementation. This was to be sorted out in later versions. Note the GPU optimization in each implementation.

Okay, so the simple explanation for the doubled render time is that Vegas 10 passes every field through the plugin twice. I'm not yet entirely sure what causes this. If I can find a way around that, I may be able to cut your render time to half.

You mean because it's interlaced?

EDIT: looks like rendering to progressive is rendering a lot faster. Will come back with times in several minutes.

EDIT2: Still 1 continuous mode, 22:07. Granted I was going some 3d work so I used some resources that way, but that's 33% speed increase. just from rendering to progressive vs interlaced.

While you would indeed see a large speed increase in continuous mode for rendering to progressive simply because it halves the number of color matches done per second (once per frame instead of once per field), what I actually meant was that in Vegas 11, the plugin renders like this:

Rendering 540 lines for frame 6, field 0
Rendering 540 lines for frame 6, field 1
Rendering 540 lines for frame 7, field 0
Rendering 540 lines for frame 7, field 1

In Vegas 10, that same project renders as:

Rendering 1080 lines for frame 6, field 0
Rendering 1080 lines for frame 6, field 0
Rendering 1080 lines for frame 6, field 1
Rendering 1080 lines for frame 6, field 1

One minor issue is that while Vegas 11 is aware that the plugin fully supports interlaced rendering and thus only passes 540 lines per field, Vegas 10 seems to upscale every field to 1080p no matter what. What's worse, however, is that Vegas 10 renders every field twice, which means that there are four whole color matchings per frame even though only two would be necessary. My guess at this point is that the plugin does something during rendering that would make Vegas 10 think that plugin parameters have changed and thus the frame needs to be rerendered with the new parameters.

I did a quick test of the Plugin because I'm soon going out of town and have limited time right now.

I used Media Studio 12 because that is where I do most of my long-form editing. My test clips involved scenes with white balance shifts or lighting shifts, which are the main types of clips that cause me problems. If I need to make a day scene look like night I usually just use a color fixer.

Graide Color Match made a very good correction in all the clips I tried. I could have done a better job in Resolve, but it would have required MUCH more effort and time! So, in my estimation the plugin is very good.

I have one comment about your business model. When I was doing commercial travel videos I had a running battle with my Distributor concerning price. I felt a 30 minute DVD should sell for $9.98 and the Distributor wanted to charge $39.95 or more. I feel people will drop $10 without thinking about it, simple because they want to buy something. Having to spend $40 dollars takes real effort, and most people settle on a T-shirt or coffee mug. The same applies to Plugins. People will pay $10 without dwelling on the likelihood or not they will actually need the plugin. To spend $75 dollars makes one stop and think... do I really need this?

Anyway, thanks for your effort in developing the Plugin. This type effort may become even more important as Sony abandons Vegas and Movie Studio.

Jillian

I think I found a way to get every frame rendered only once on Vegas 10. I can now render the sequence in about the same time it takes on Vegas 11. I'll add a few more minor tweaks and fixes from my todo list and then prepare an update.

One more performance tip you can try: I was able to cut the rendering time by another 40% by applying a constant correction towards Still1 before adding the continuous correction.

Jillian, thanks for your feedback. I realize that for someone using Movie Studio Platinum, the cost for the plugin is about the cost for their entire editing system, which must seem very steep. Finding the right price for a product is a difficult thing. I came up with mine by talking to people about how much they would be willing to pay and by looking at what alternative solutions cost. The idea of getting much higher sales by drastically cutting the price is compelling, but I'm not sure the target audience for Vegas plugins is large enough to make such a model work. Having said that, your comment makes me wonder whether there may be demand for a 'light' version of the plugin -- proving a subset of the features at a lower price.

Michael

Thanks for taking the time to create a great plug-in for Vegas. It does significantly increase render time, but that's editing. Neat video, Gaussian Blur, Magic Bullet, etc... all add to the render time. If it's worth it you simply budget the time.

On a side note can you create a "Open File Location" at the end of renders for your SeMW Extensions? It would really help with sorting when we are rendering 5-6 projects overnight to quickly sort.

Looking forward to future updates and your other developments.

Thanks for the feedback, Zelkien69. Adding "Open File Location" would certainly be possible (in those cases where I know the output filename), but you should already be able to get to the output location via Vegas' own render dialog (as long as its not set to close automatically).

I have now completed the 1.0.2 release with the performance fix for Vegas 10. You can find the download at http://www.semw-software.com/colormatch/download.

Other changes:
- When switching to continuous mode with only an original image defined, this image will now automatically be used as the reference image.
- In continuous mode, the analysis area now affects both the reference and the input image.
- Corrected an issue that could cause a crash when passing-through interlaced footage.
- Some tooltips have been improved.

Let me know if you find any issues with this release.

Michael

FYI this plug-in has been updated to 1.0.3 as well as a separate auto levels plug-in has been created. You can find it here.

http://www.semw-software.com/en/extensions/

I had a quick play with the new Auto Levels plugin. It really does stretch signal levels to their full range. i.e. 0-255, which will give lots of clipping in most video delivery scenarios (web, DVD etc.). I'd like it to be able to conform levels to 16-235.

I like the idea of being able to switch between computer rgb and studio rgb output. I'll try to provide an update that can do this soon.

In the meantime, a workaround is, of course, to place a Sony Levels effect after the Auto Levels effect.

I'd say instead of letting the person choose RGB or SRGB, let them type in their own min/max levels. I might was 0 to 100, for example, or 200 to 255. :)

For now, I've added the option to choose between computer RGB and studio RGB. The update is available at http://www.semw-software.com/autolevels/.

Thank you for the update Satevis.

Although the "Studio RGB" setting gives less contrast than the "Computer RGB" setting, it still stretches levels to the full 0-255 range and therefore clipping occurs outside the 16-235 range. Is that behaviour intended? Could you please explain how the plugin makes its calculations?