I dropped contrast according to the pattern on the Lagom site, as well as shifting to limited color range, and blacks now actually look black, instead of grey. That also gets me full grey on the viewing angle test, which had previously given me entirely red.

-- merged --

So I have an i7-6700K. That five-minute encode I was suffering through on my old machine? 46 seconds.

lordsmurf, can you help me out with that script of yours?

This thread is 4 months old now. Which script for what? :laugh:

This one: Actually now that I think about it, you may have shared it previously. Hang on (or don't, I'll be done looking before I post this anyway, so you can just keep reading). Is this it?
It's longer, I just pulled the first few lines. If that is it, what do I need to know about using it (interlacing, color space/format/whatever they're called, etc)?

The bottom right corner of my monitor looks really blue if it's showing a dark enough grey/black. Is that normal? It seems to affect the whole monitor when viewed from too far toward the left, but the same angle from the right seems fine.

I'm also still not sure what my brightness/contrast/range settings should be. It seems to only produce 16-235 regardless of what I do; I have to set it to 'limited' range in the monitor settings to make anything black, and it clips below 16 on the AVSHD brightness pattern that's on YouTube. My previous monitor displayed all the bars.

Bright whites aren't so much slightly pink as actually pink...it's not even subtle towards the top of the range. Light greys go pink when f.lux is active, but only on limited range. On full range they look okay, but I don't get blacks.

I'm obviously not too fussed about accuracy when f.lux is active; I disable it for any color work. But I'd like it to not look this ugly.

What you describe is typical for older TFT panels, so no surprises there.

Did 't you calibrate with X-Rite? Why mess around with the calibration and try to make that old monitor behave like a brand new IPS job?

I'm talking about the new ViewSonic.

I calibrated the ViewSonic with X-Rite and it looked like garbage. I've switched the HDMI cable for a VGA cable and it seems to have solved the problem. Still a bit bright in the lower left corner, although it's not as blue and the pink brights are gone.

Everybody knows that VGA is faster than HDMI.

It's difficult to respond in this thread because so much information is missing from the respondent. Also it seems that techniques, software, and hardware that work for the rest of the world don't work here. It's not just frustrati9ng, it's totally mysterious. I have no explanation for any of it.

I had no idea what the differences between the cables are. The new monitor doesn't have a connector for the type of cable that went to my old monitor, HDMI is obviously less hassle to plug in, so I went that way. Evidently for some reason my graphics card is only outputting limited range RGB over HDMI. Now that I've calibrated over VGA with the X-Rite software, it's looking much better. Certainly an improvement on the 8yo Samsung TFT. Very bright in a completely dark room, but bias lights will have to wait a while.

What information is missing?

Clearly I've had some hardware issues, hopefully with my new CPU and motherboard that's all cleared up now.

Yes. That's not the first few lines, and it's a long script. But that's the one.

I was just trying to pull a portion that would enable you to answer without being too long, so I cut off the fairly pedestrian opening.

I tried it out, and got an error saying "DePanInterleave: input must be planar YUV or YUY2". It's a YUY2 source file and the second line of the script converts to YV12, which I assume is planar YUV (the DePan site says it supports YUY2 and YV12)? It must be there for a reason, and I assume you know what you're doing...

Can anyone help out with that color space mismatch error?

Would you mind posting the relevant lines of your script? It took several minutes of cruising through this thread to locate the script you're apparently talking about, which I assume comes from the two scripts lordsmurf posted here: (http://www.digitalfaq.com/forum/vide...html#post45915 (if you don't know how to find the URL of a post, right-click on the post # and copy the link). Note: No one knows the first 4 lines of your script or the lines leading up to the DePan statement in question.

It's literally just that script with the AVISource path changed.

It works for me:

Other than any changes you might have made, note that conversion from<>to YV12 require "interlaced=true" or "interlaced=false", whichever applies.

The interlaced line doesn't actually stop it from working though, does it? It just means the result will look bad (which is irrelevant at the can-I-open-this-in-VDub step).

I tried it with my Studio avi, rather than a full game, just in case something was off with the source...same result. Adding an interlacing flag to the color space conversion makes no difference, whether it's true or false.

Plugin issue, maybe? I think I had to find and install DePan myself, might have screwed something up there?

I have:
DePan.dll v1.10.1
DePanEstimate.dll v1.9.2.0

Unless something has changed in the script, I had no problem with it. It does leave a lot of work to be done on that clip, though, but gets rid of the horizontal dropouts.

I have v2 of both of those (assuming right click -> properties -> details -> file/product version). 2.13.1.1 for DePan, 2.10.0.0 for DePanEstimate.

There's also a DePan-old.dll, which is version 1.10.1. Renaming DePan.dll to DePan-new.dll and DePan-old.dll to DePan.dll fixes the problem.

Never heard of V2 of either of those and don't see them listed anywhere.

Glad it's working now.

I thought I'd had to download it myself but I must have merely been looking at documentation for it because it's in the lordsmurf plugin pack. I had a look after seeing DePan-old, because that's how a few of the filters in there are named and I've never done that, and it's in there. So that's where v2 came from.

-- merged --

What's the best place to use this script?

I'm working on a different tape that has some serious dropout issues, and my process was levels, colors, StabMod(), QTGMC, SmoothUV(), chroma sharpening, export. Import, ReplaceFramesMC(), reinterlace, separate fields, RemoveSpots(), reinterlace, sharpen, process through VDub for CCD and ColorMill.

Is this right? I'm not quite sure whether to use ReplaceFramesMC() while deinterlaced or while field-separated. I exported the second script without any frame replacements, and I'm watching that through and adding the frame replacements into the script as I find anything RemoveSpots() missed (which is a lot, even in the couple of minutes I've done).

If I wanted to run the Studio script with this, where should it run? How much room for modification is there for each source? Is it pretty much just letting it run, or should it be looked through? When I've got some time later I'll Google as much of it as possible to try and understand what's going on, then come here with more specific questions than 'explain the whole thing to me', at this stage it's more just a question of whether that will be practical or theoretical research.

On any given day, I may look at a half dozen scripts. You're probably just working on one, so it's easy to keep track of. But my question is always: What script? To avoid this, attach it. They're tiny, and we added .avs attachment extensions for a reason. Between posts, you may alter it anyway, and we're suddenly talking about different things.

So ... attach it. :)

FYI: There's no rule that you must have "a script", singular. I often run video through 2-3 passes, each with its own Avisynth work and VirtualDub filter chaining. Some purists have these silly ideas about one-pass, but it's not what professionals do. It's why we have uncompressed or lossless intermediaries, after all!

If "this script" that you refer to is my powerful NR, then I don't do anything BUT the NR in the script. I may do a prep script, and run a first pass. Then the powerful NR. Then another pass or two with more filters. Sometimes you can only attack one error at a time. It's just not feasible to cram everything into one script.

Right, and the 'export, import' is a shift between two different passes. With yours being apparently so intensive, I've never thought of it as anything other than its own pass. The question is where in the chain to insert it. Run it first, run it while progressive after QTGMC, or run it after reinterlacing (I notice at present it field-separates as a first step)?

I remember there being advice earlier in the thread to run RemoveSpots() after QTGMC() to prevent noise confusing RemoveSpots(). I've always thought of this as similar to RS, but it seems it's actually NR as well so that isn't a concern.

I know the intermediates themselves are lossless, but I've been under the impression deinterlacing and reinterlacing isn't, so I've been trying to keep that to a minimum. Do I have that wrong?