[Bill Burnette]

Can you see it in the control panel “Programs and Features”?

[Bill Burnette]

If ASIO4ALL is really the problem, you can investigate or uninstall it.

The usual reason for installing it is to get ASIO functionality for an audio device that does not have its own ASIO driver. If that is your case, at least make sure asio4all has been configured completely to match up with your sound card. Otherwise, uninstall it.

Vegas does not need any ASIO driver.

[Bill Burnette]

Malware protector, was there already some malware on the machine?

Might as well have a look in the task manager to see if something other than Vegas is using up your CPU.

[Bill Burnette]

The problem was notorious and the error message about closing other programs is misleading (see a google search). The new version (Sony movie studio 13) comes with a 64-bit version for your 64-bit OS, so no memory problems. One thing that might help with your current version is to turn off all thumbnail displays on the timeline.

[Bill Burnette]

The .tmp file is an intermediate. The render is not complete. I believe it has finished the timeline but needs to do some post-process. For longer mp4s, it can take a while sitting at 100%, with [open] greyed out and the .tmp file sitting there. Wait a while longer. It’s likely that your renaming the file would mess something up.

[Bill Burnette]

One possibility is file system corruption, which you can check for using the Windows check disk utility (“check now” under [tools] of the drive’s properties).

Another possible candidate is the .sfk & .sfap0 (and some other .sf suffixes) files that vegas creates when it sees an audio track for the first time. Removing the .sfk/.sfap0 files will force vegas to recreate them. How could they go bad? Sometimes, renaming or replacing the original filenames causes vegas not to update the corresponding .sf files (because of file timestamp confusion). The .sf files appear in the same folders as the files containing the audio. Note, video files contain audio, and have .sf files.

[Bill Burnette]

A plain way to look at it is that the S-video and composite analog outputs are meant to be plugged into a TV, which is (for historical reasons) not supposed to be fed signals below 7.5 IRE. You are looking at these images on a computer, which can display the full range of RGB, 0-255. The Canopus converter is giving you the choice by using the 7.5 vs 0 switch of whether you intend your analog capture to be carried through a DV workflow to a DV tape to be played back on a TV versus for final display on a computer. As you have discovered, viewing an image coded in DV for TV without any correction on your computer, it is lighter (milky), and the variation of shades of black is greater (not crushed).

Your histograms show that the total range of (digitized) color from black to white is less with the DV (and 7.5) capture than the 0 IRE capture. So it looks like less contrast on a computer. It’s an interesting thought whether you could find a more satisfying correction (e.g. curves or levels in Vegas) from DV/7.5 than the simple IRE transformation done by the Canopus.

[Bill Burnette]

Here’s a simple-minded take on LUTs:

In the post production environment, it is important to create a final render that looks right when delivered from a chosen standard color space. A standard color space is a mapping of the digital (R+G+B) values of an image to objective (measurable) color perception (like CIE RGB). Why there should be more than one standard is another story.

One big problem that an LUT solves is that monitors need color correction to display a standard color space in the way that color space intends. Without a proper display, the operator might be inclined to make the wrong decisions about color.

A 3-dimensional LUT can map every color from a given standard color space into an appropriate display color on a monitor. The LUT is matched to the particular monitor; i.e. it is the digital result of calibrating the monitor (after setting whatever controls are built into the monitor hardware). Of course it is (or “should be”) important that the monitor is capable of displaying all the colors included in the standard color space (gamut), otherwise the LUT can only approximate the colors. Sometimes an approximation can preserve the perception of relative colors, but that is another whole story.

Single-dimensional hardware LUTs are part of virtually every PC video adapter, and are supported by the Windows display system. They consist of three rows of 256 numbers, one for red, green, and blue. Those numbers are loaded into the hardware in the video card. The R, G, and B values of each pixel are separately mapped from the image’s value to a value suited for the monitor.

The monitor’s manufacturer probably delivers a standard profile for that model that approximates what the average unit might display when it is new. It is generic for that model and does not address individual differences and aging. Or a profile can be created by a calibration process, like Spyder or ColorMunki, along with a new monitor profile that matches that one monitor (until it ages).

Single-dimensional LUTs can make sure that the monitor displays the right gamma (the curve that relates digital values to relative “brightness”) in R, G, and B. They can also correct color cast in the greys (all the way from the blackest to the whitest that the the monitor can display). But they can’t correct every color, and are sometimes not considered adequate for high-end professional post-production.

There are other uses for LUTs, like mapping from one color space to another, but these are not associated with monitors.

[Bill Burnette]

The “milky” description sounds like reduced contrast, which could also be vaguely perceived as less sharp. DV records with safe color range. Is the canopus converter expanding the color range? Just guessing.
Posting a screen grab might help someone diagnose it.

[Bill Burnette]

I’m having a look at differences between individual pixels of your screen shots. You can do this in photoshop by differencing two layers, then increasing the contrast of the result to visualize the difference.

Yes, the new one is slightly darker, and there is also a color shift toward blues and greens. Also, there does not seem to be a uniform stretching. Different pixels of the same color are converted to two or more different colors. Overall, it gives the impression of artifacts of recompression, which is always at the mercy of the particular software.

Another observation is that some of the lower-valued RGB components in the original are quantized. For example, whenever I see an ‘R’ component of 15 or less, it is either 15, 10, or 0, maybe because the whole image was computer-generated. Or it may indicate some stretching during the original production or quantizing during compression.

Also, all my observations could be completely invalid due to the jpg compression of the screen shots.