Scripts and filters for an Opera (sample videos included)

[jairovital]

sanlynn

Of course we are here, keeping track of your hard work. Actually beautiful work. We are just reading and learning too much.

The problems that you're pointing are so deep inside video-bits that I prefer just to read and see other people's opinions.

Found many VirtualDub/AviSYnth solutions to various noise problems. But the biggest hurdle is color. Big hurdle!

May you post what solution you've found?

Keep the monster alive. It's showing your good job.

[sanlyn]

sanlynn

Of course we are here, keeping track of your hard work.

Yup, jairo, I see the view counts. The first work file of 10 minutes of video (4-GB) is being rebuilt for the 3rd time, with several problems solved. Sorry, those opening titles are a mess, way beyond my equipment. No sense holding up everything just for that. The rebuild will take a spell, so I'll let it run while I go nighty-night watching and listening to your original disc. Will take a look in the A.M.

[sanlyn]

Just burned up half a day looking into the color problem. And I mean, problem! Histogram below is the clue. Think you can just move Red/Green to left a bit, then move move Blue to the right and stretch it a little? Dream on. Low-blue color is lost, period. But worse...I just figured out that this was a PAL VHS recorded to an NTSC DVD. Simple? Not with home gear and (likely) cheap PAl->NTSC adapters.

PAL is EBU color standard, but SD-DVD/VCD is SMPTE color. Similar, but not alike. PAL chroma/luma don't transfer as you'd expect. You lose chroma and luma info, and you get shot in the head at RGB below 15 and above 235. Yes, I already did the AviSynth "matrix" route, etc., etc., and lots of other stuff. The histogram (and vectorscopes, etc.) all show the same problem.



The image was captured running original YV12 video with AviSynth.

[sanlyn]

I have to get down to going more deeply into colorspaces and AviSynth. Looking for a way to extract the Blue channel, correct it properly, and replace the original Blue with the new channel. It's apparent that the copy-protection scheme is in the "U" channel, crimping Blue and raising Green. No idea (yet) how to do this. SImply using a YUV filter and pushing the U channel forward doesn't retrieve compacted Blue properly. Any ideas?

[poisondeathray]

I have to get down to going more deeply into colorspaces and AviSynth. Looking for a way to extract the Blue channel, correct it properly, and replace the original Blue with the new channel. It's apparent that the copy-protection scheme is in the "U" channel, crimping Blue and raising Green. No idea (yet) how to do this. SImply using a YUV filter and pushing the U channel forward doesn't retrieve compacted Blue properly.

It's obvious this has to be done in YV12 before any other work can go forward. Any ideas?

I think you were right the first time. You can't fix this green (or blue) problem in YUV colorspace. You can adjust U, and V, by offsetting - but that offsets the other colors screwing them up. You could try coloryuv() for example - but it won't work on this piece

You could try gradation curves in vdub. It has a YUV or CMYK colorspace mode as well as RGB, HSV. But I suspect you will get the same results, corrupting the other colors

You could try secondary color correction, where a range of colors is selectively corrected by masks. Most NLE's or color grading software have this capability. I played with it, and it's still a mess

Where are you going with the replace blue channel strategy? What do you intend to replace it with ?

[sanlyn]

You were right the first time. You can't fix this green (or blue) problem in YUV colorspace. You can adjust U, and V, by offsetting - but that offsets the other colors screwing them up. You could try coloryuv() for example - but it won't work on this piece

You could try secondary color correction, where a range of colors is selectively corrected by masks. Most NLE's or color grading software have this capability. I played with it, and it's still a mess

Absolutely right, poisondeathray (as usual). See my question about working in YV12, above. I suspect all of the U channel data might really be there, but how to restore or expand it? It's possible something in U was clipped (destroyed???), but how? Just bumping up U works only partially, you can see in Blue histograms that something is clipped.

[poisondeathray]

I see what you mean, the blue channel is clipped . Usually when something is clipped, it's not recoverable - even before RGB conversion

But even shifting the blue channel (increase blue gamma) to make the histogram look more balanced still makes it look bad

I edited my post above - you can play with correction in different colorspaces with gradation curves in vdub

[sanlyn]

I think you were right the first time. You can't fix this green (or blue) problem in YUV colorspace. You can adjust U, and V, by offsetting - but that offsets the other colors screwing them up. You could try coloryuv() for example - but it won't work on this piece

You could try gradation curves in vdub. It has a YUV or CMYK colorspace mode as well as RGB, HSV. But I suspect you will get the same results, corrupting the other colors

You could try secondary color correction, where a range of colors is selectively corrected by masks. Most NLE's or color grading software have this capability. I played with it, and it's still a mess

Where are you going with the replace blue channel strategy? What do you intend to replace it with ?

(Sorry for the delay, I put off some of my PC repair clients for a few days, but I've had to get back to them if I wanna get paid!).

I previously tried what you suggest, poinsondeathray. They go only so far, so you might be right saying some data is just "gone". I found I could nudge blue up, which brought green down a bit, and with gradation curves filters I managed to concoct a chain of them that got all three colors lined up almosty tolerably well (except Blue seems flattened at the high end). But what that gave me was 16-235. Better color, but everything is clipped. Basically what I got there was the equivalent of AviSynth's PC->TV matrix, so you know how that looks. I didn't have time to expand or fiddling with that yet, but I suspect I'll just end up with 16-235, tho with Blue raised a bit.

Once I managed that 16-235 setup, the odd thing was that no filters could expand Blue. Tell the filter to increase contrast (raise high-end Blue), and the filters have no response at all. So, yeah, brighter Blue data just ain't there. Same with the darker Blues; no response, and dark green as well (!).

I figured I could find a way to work with just the U channel (I might not have to "replace", it was just a possible idea, but thought it might prevent interfering with Red)). I was looking into MaskTool and getting into charts about YV12 pixel mapping when I had to get back to work. The last hour of the video can be "improved", but I use that term very loosely.

What a shame. Very nice production, even if the scenario is super corny, but good stuff anyway. I'll keep looking around.

BTW, I tuned your ChubbyRain by adding Coloryuv() and refining Tweak in the routine. Added just a tad more desaturation (0.5%), and made the green stripe just a tad more Red, then made the side red mask just a tad more blue. An almost miniscule change, but at times the original problems seem to almost completely disappear. Thanks again.

Further note: When first watching the whole video, I stopped when the end credits started rolling. A couple days ago I kept going to the very end. The histograms look horrible until the final frame. Then the tape stops rolling and there are a few frames of plain middle gray (that's right, just plain gray -- not green). The red garbage disappears, but the green striping is still there. Then the player displays a bluish "Aiwa" icon. The green's still there. But on the gray screen and the Aiwa logo, after the tape stops, the histograms look normal -- all 3 colors centered perfectly. Shucks. So, the green stripe is not on the tape; it's coming from the player, a copy adapter(?), or the recorder.

[poisondeathray]

Regarding your swapping channels: you can do this in after effects or nuke. Basically you can replace the blue channel from data derived from other channels, so the resulting histogram is more balanced. You don't have to work in RGB space, you can derive data from Y' luminance , for example

In this case, it's not as simple. In some frames, there is uneveness - parts of the frames are colored differently. For example in test.mpg, in the beginning sequence, the background curtain is both blue and green - how can this be? It's the same friggen curtain! So color correcting it will fix the green and make the blue parts a way too saturated blue. You would need masks and rotoscoping to do differential treatment if you wanted it "perfect." When you do the channel swap, it does make the curtain more "even", so you probably don't have to do as much mask work

[sanlyn]

You ain't seen nothin' yet. Gets worse. I assembled 1-min 47-sec from the vid's suitably climactic mid-Victorian finish. By that time the noise level is evil, highlights are fried, blue nearly gone, etc. I cut most of the applause and then dissolved to the last curtain call, and cut some rolling credits and some lead-out. At the end you see the tape stop and then Aiwa's logo; the right-side red stain ends and histograms look normal. But the top border stripe turns pink and persists, with many pink rainbows (from the player? the recorder? Cheap copy adapter? Crummy composite wire?)

The "Fin.mpg" I made has AC3 audio. Maybe it's me, but in AVI/PCM the sound creeps gradually to the right, but in AC3 I get 2-channel mono. Must check that later.

9.6 seconds into this clip (frame 288) there's a harsh blip from damage that doesn't fade for 400 frames (11 seconds). It briefly breaks copy protection timing and you get a mere 3-frame blink of what the color might be like. I added a startup fade-in and ending fade-out in AviSynth, and a dissolve about midway (NOTE: The climactic dissolve-to-white is in the original! Not my idea).

This link http://www.4shared.com/video/BTebgpzS/Fin.html goes to that tiny yoo-toob type player where you watch a mini version or download the real one. The mini player blows up full screen but it's really really really blurry and actually hides the problems.

This link http://dc192.4shared.com/download/BTebgpzS/Fin.mpg goes directly to the file. A left-click loads it into your MPEG player (takes about 5-min, though). Right-click, then tell the popup menu to save it. 61-MB.

One of many speed bumps. This one's in the worst of all moments, right at the Big Finish. Histograms thru the opera show brights crushed even worse than darks. The tape's owner really loved that fast-rewind-and-replay feature.


Climactic dissolve to white (uh, I mean yellow). Blue really suppressed here. What's stops one from bumping Blue forward? It's shaped like Green and Red, but nudge it ahead and it shrinks to a skinny triangle.

[2Bdecided]

You need slightly more flexible control of R, G and B. Sadly I don't have any great suggestions. I often end up splitting channels in AVIsynth, using the various advanced levels commands (or just basic "levels"!) on each one separately, and then putting the channels back together again - but I can't remember making this work with R, G and B.

I don't think your colour woes have anything to do with copy protection. It's filmed in France (SECAM, 625-line 50Hz) and ended up as M-PAL (525-line 60Hz), probably via NTSC. It's a wonder there's any colour left at all!

Shame about the loss of sync, but to be honest, if there's tape damage that bad, there was little that could be done at capture time.

btw, the "perfect grey" near the end is just because the capture device, whatever it was, stopped decoding chroma at that point. It doesn't mean that the chroma (that wasn't captured) was any better or worse - though there was probably none!

As you say, even the aiwa logo at the end is a mess (though not as bad). It's either a terrible RF connection, or else that too is on a tape - i.e. even at that point you're watching VHS, and previously you were watching 2nd generation (at least) VHS.

Cheers,
David.

[sanlyn]

I don't think your colour woes have anything to do with copy protection. It's filmed in France (SECAM, 625-line 50Hz) and ended up as M-PAL (525-line 60Hz), probably via NTSC. It's a wonder there's any colour left at all!

Some good info, 2B. GSpot info on the CVD disc sez it's NTSC/YV12. But, yes the decoder is either a schizo copy adapter or the Phillips itself. I keep asking, couldn't the person making this copy see what was happening?

Shame about the loss of sync, but to be honest, if there's tape damage that bad, there was little that could be done at capture time.

Correct, 2BH, no way to "restore" that break. There are several more, earlier. But after the tape stabilized there was no problem with audio sync.

As you say, even the aiwa logo at the end is a mess (though not as bad). It's either a terrible RF connection, or else that too is on a tape - i.e. even at that point you're watching VHS, and previously you were watching 2nd generation (at least) VHS.

Mm, but you can see the tape stop running. The brief blink of gray comes after the usual flurry of diagonal striping I've seen on most VCRs when the tape leader runs out. And there's an audio blip, the kind you hear when a player shuts off audio playback. Remember, I cut nearly a minute of tape lead-out and Aiwa logo, but I kept the tape shutoff and gray sequence. I'm guessing the gray frames are from the Aiwa (see the very first monochrome frame on the startup "Opera_A" I posted earlier). The "REW" + "CH--" commands at the end are coming from the player, even if the tape has stopped. So no one can really tell where the "Aiwa" image noise is coming from. In any case, I'd delete that whole lead-out from the final video.

Thanks again for taking a peep, and good color tips. Yep, SECAM/PAL etc. to NTSC has different color standards. If what's coming into the Phillips is playing correctly, the Phillips would just record what's "there" into NTSC (with NTSC YUV limitations, of course). But anyone can look at a recorder's monitor output and see what's going in, and some let you read the recorded video during record. In any case, after the recording finished the person must surely have checked to see what they had (!@?#).

I'll have to work in unmodified YV12. Look at the histogram in my last post. That blue is obviously way below 0 RGB at least numerically, in storage in one of those channels somewhere(?). In RGB if Blue is maxed at RGB 216 as a "number", then is storage info actually a "minus 35" to 216? The thingie with audio shifting in PCM but not in AC3 is another puzzle; In PCM you can hear that the left channel has some faint (and slightly different) output. Encode into AC3 and both channels are exactly alike!. Audio graphs in Audacity look one way in the original PCM (I don't combine .wav with audio until the last steps), but different in AC3 with restricted dynamics and range. In PCM the sound shifts spatial balance, but it's fuller and richer. Something, somewhere, is doing that.

Now I gotta get into some cryptic research and try to find what's going on. How can you have RGB lines placed as they are and still have a histogram read "MIN 0" for all 3 colors? Of course the ColorTools histogram and vectorscope are programmed to display only 0-255 numbers. By the time the video goes YV12->RGB, the original luma/chroma is converted to something else, and too late to transform the info. That histogram was taken from AviSynth/YV12. AviSynth's own histogram displays similar anomalies with YUV. So I just keep going back to try to find what's really in the original YV12. AViSynth has a command for displaying actual min/max values each channel, I'm going to run it again in the original YV12 and see what numbers I get. But later. Right now I have NeatVideo running a 6-hour job again.

Thanks again, 2B.

[sanlyn]

Gotta go pick up parts for my PC customers. Microcenter near here has a huge bookstore. Research time. I'm thinking of these takes on the color issue. (1) What is M-PAL, and which component in the original copy process was running in that mode? Thanks to info from 2BDecided, it appears the Samsung/Aiwa VCR was outputting M-PAL from a PAL VHS. (2) What video data storage problems are related to PAL, M-PAL, NTSC conversions? (3) What kind of copy protection plays with color like this? Never saw it used this way before. (3) How is video data mapped in YV12 (details, please), how to get it, what the hell to do with it?

Meanwhile, I'll just do what I can. Damn nice opera. What a shame. Also have another video project running on PC #2 in the next room.

Why do we do this? Is my wife right? Are we nuts? Probably . . . one of us is, anyway.

[poisondeathray]

How can you have RGB lines placed as they are and still have a histogram read "MIN 0" for all 3 colors? Of course the ColorTools histogram and vectorscope are programmed to display only 0-255 numbers. By the time the video goes YV12->RGB, the original luma/chroma is converted to something else, and too late to transform the info.

It's because you converted YUV=>RGB using rec601 matrix, or let vdub do the conversion (if you use full processsing mode or any vdub filters). So any data less than Y<16 , Y>235 is lost . Y [16,235] is mapped to RGB [0,235] . If you specify the RGB conversion in avisynth to use PC.601 , Y [0,255] will be mapped to RGB [0,255] . This is critical when recovering shadow detail, highlights (maybe not in this example, but in general). But it's important to remember convert back to YV12 with appropriate matrix as well. This was frame 1000 in the "fin.mpg" sample, about the same frame as your last screenshot

[jairovital]

Microcenter near here has a huge bookstore. Research time. I'm thinking of these takes on the color issue. (1) What is M-PAL, and which component in the original copy process was running in that mode? Thanks to info from 2BDecided, it appears the Samsung/Aiwa VCR was outputting M-PAL from a PAL VHS. (2) What video data storage problems are related to PAL, M-PAL, NTSC conversions? (3) What kind of copy protection plays with color like this? Never saw it used this way before. (3) How is video data mapped in YV12 (details, please), how to get it, what the hell to do with it?

sanlynn
This thread brought to my mind The Da Vinci Code, by Don Brown. You are researching and running into a huge labyrinth, solving a misterious puzzle, trying to answer who murdered the king, collecting clues like C.S.I.'s coroners. It is amazing.

But the best is to see that too many people are learning about video's secrets and are following your steps wondering the answers and who is the main guilty of this interesting novel.

Why do we do this? Is my wife right? Are we nuts? Probably . . . one of us is, anyway.

Tell to your wife that you are not going nuts, just solving a misterious case. I'm watching this like a wonderful movie, with limonade and popcorn.

[sanlyn]

How can you have RGB lines placed as they are and still have a histogram read "MIN 0" for all 3 colors? Of course the ColorTools histogram and vectorscope are programmed to display only 0-255 numbers. By the time the video goes YV12->RGB, the original luma/chroma is converted to something else, and too late to transform the info.

It's because you converted YUV=>RGB using rec601 matrix, or let vdub do the conversion (if you use full processsing mode or any vdub filters). So any data less than Y<16 , Y>235 is lost . Y [16,235] is mapped to RGB [0,235] . If you specify the RGB conversion in avisynth to use PC.601 , Y [0,255] will be mapped to RGB [0,255] . This is critical when recovering shadow detail, highlights (maybe not in this example, but in general). But it's important to remember convert back to YV12 with appropriate matrix as well. This was frame 1000 in the "fin.mpg" sample, about the same frame as your last screenshot

poisondeathray, thanks for bringing that up. I'll check it out and get back.

When working "for real" I never let VirtualDub make colorspace conversions. The fin.mpg cuts were processed entirely in original YV12 and AviSynth. It saw VirtualDub only to get its histogram, but VDub was looking at AviSynth working in YV12. But now that you mention it, I think I'll go back to that YV12 work file and use AviSynth's histogram. Thanks for the tip, that would be a good way to double-check things. I always thought VDub's RGB default was PC.601 (why would a PC-only graphics application default to "TV" instead of "PC"?). When I took pixel readings from VirtualDub to make the earlier videos, I was seeing 0>255 pixel values for all colors. But that changes by the end of the opera.

The scene to which you prefer is midway thru the dissolve-to-white sequence. It has no color values below midtones except for RGB 0,0,0 in the black borders. But my own question: why would 16>235 clip Red and Green but not Blue? Anyway, thanks again, I'll re-check.

[sanlyn]

I'm watching this like a wonderful movie, with limonade and popcorn.

At this point I'm just on coffee and automatic pilot.

[sanlyn]

I don't think your colour woes have anything to do with copy protection. It's filmed in France (SECAM, 625-line 50Hz) and ended up as M-PAL (525-line 60Hz), probably via NTSC. It's a wonder there's any colour left at all!

As before, 2BDecided, you led me down a path to enlightenment -- well, to useful info, anyway. My research (such as it is, so far) sez you're partially correct. The original VHS must have been SECAM. But was the player outputting M-PAL, or was that feature just "turned on"? Anyway, according to GSpot data and TMPGEnc Editor, the VOBs are NTSC.

Sources half of Brazil uses NTSC, and half uses PAL-M (aka M-PAL?). It's common to find VCR's there that play NTSC, PAL-M, and SECAM. They play and output NTSC. They play PAL and M-PAL and output M-PAL. But if they play SECAM, they output SECAM. So...even if the player's Auto N-PAL was turned on, the player's output could only be SECAM color from a SECAM source.

So, if SECAM came outta the player, the Phillips sees it on Line 1 and tries to record NTSC. Quelle erreur !!! Phillips expects a halfway compatible M-PAL or NTSC colorspace (they're not that far off) to stuff into YV12. But that's not what it gets. It gets a SECAM YUV colorspace: YDbDr . Looky here, y'all:

You may note that the Y component of YDbDr is the same as the Y component of YUV.
Db and Dr are related to the U and V components of the YUV colour space as follows:
Db = + 3.059U
Dr = − 2.169V

--- http://en.wikipedia.org/wiki/YDbDr

Notice something? In reverse, the formulas say YV12-U is a factor of 3.059-something "darker"(?) than Db, and YV12-V is a factor of 2.169-something "brighter" than Dr. Well, likely it's more complex, but it partially explains the consistent color displacements I keep seeing. The site also has a YDbDr/RGB equivalent chart. But, no. It can't be that easy.

OK. I don't know jack about using that info (yet). It's a start. Thankee, 2BDecided. I don't know why I was blind-sided about SECAM. Must be the strain of creativity(!). There are more formulas and whatnot ahead. I'm already working under information overload, but maybe a glimmer of something useful can seep through via osmosis. The night is young (12:25 AM). I made coffee and watched most of The Day The Earth Stood Still. Made me keep hoping I'd find Klaatu and he'd straighten this out. Now I'm on the 'net again, and in the background I'm running Charlie Chan At The Opera.

Cholly Chan say man with bad video is like man with bad woman. Like bad video, bad woman make man do many dumb things. Fault is not with bad woman. Fault is with man. Like bad video, bad woman not make Man stupid. Man start stupid.

[sanlyn]

It's because you converted YUV=>RGB using rec601 matrix, or let vdub do the conversion (if you use full processsing mode or any vdub filters). So any data less than Y<16 , Y>235 is lost . Y [16,235] is mapped to RGB [0,235] . If you specify the RGB conversion in avisynth to use PC.601 , Y [0,255] will be mapped to RGB [0,255] . This is critical when recovering shadow detail, highlights (maybe not in this example, but in general). But it's important to remember convert back to YV12 with appropriate matrix as well. This was frame 1000 in the "fin.mpg" sample, about the same frame as your last screenshot

Thanks again for checking my work, poisondeathray. In a major respect, you were right ! Originally I did it correctly. Step 1 was to make a 10-minute master AVI converted to RGB32 for NeatVideo. I made that AVI correctly with a PC.601 matrix. Step 2 was NeatVideo. But with Step 3 and later I was copying old scripts I used a while back for a VHS job that used VirtualDub only for display, never for processing. So the old scripts always used the default matrix. For the current project, when I copied those old scripts and updated them, I neglected to update the matrix parameters.

Shucks. Oh, well, last night I decided to start again with Step 3 anyway, so I have only two later scripts to revise. Starting after NeatVideo with Step 3, I pooped-up the matrix.

Matrix problems aside, the Blue/Green displacement from SECAM->NTSC remains. Phooey.

[poisondeathray]

Regarding the matrices, It only matters when you have superwhites/superdarks (ie. Y<16 , Y>235) . It's usually not a big deal, esp. for commercial material - most only have small excursions. It's only a big deal when you have these superbright highlights and shadows in material that you are trying to preserve . In this particular case , the blue channel clips low either way , and is shifted

Regarding the blue channel: you can try the channel swap . Recall how doing linear changes to the blu channel would distort the histogram distribution/shape? Even non linear changes didn't work well because too much of the blue channel was clipped in some scenes. There is a way to do it in avisynth similar to how it's done in after effects, using mergergb. This is just a starting point, so the blue channel data has a new distribution in line with the other channels ; you still have to adjust it with other tools

http://avisynth.org/mediawiki/MergeRGB

vid1=MPEG2Source("Fin.d2v")
vid2=MPEG2Source("Fin.d2v").converttorgb(matrix="p c.601")

vid2
mergergb(vid2,vid2,vid1)

since vid1 is YUV data , it will take the luminance values and use them for the new blue channel . You can preadjust the luminace of vid1 in YUV space (eg using levels or other filters) , to give you different starting curves .

[sanlyn]

Thanks for the MergeRGB notes, poisondeathray. In fact I was just looking at that this morning, and existing AviSynth filters for dealing with the YDbDr formulas. I've read that Y data in SECAM is just like other YUV luma. The difference is the way Db and Dr are calculated from Y. MergeRGB and YUV filtering commands might help me make use of the computation formulas, particularly in "reversing" the SECAM values back to something closer to PAL or NTSC (what the hell, might as well try it).

True, there's no "linear", push-button way to adjust those channels as-is. I'm posting some new caps below this reply to show more clearly what I suspect: the original VHS player was playing SECAM. It would normally output SECAM-only (maybe the Auto M-PAL twisted the output a bit? Can't say). Then the recorder took SECAM YDbDr and made it NTSC/YCbCr with egregious color value and scaling errors.

[sanlyn]

New caps. This time, I'm just reading the original YV12 VOB's in AviSynth. No processing. Here's frame 10454 in YV12 with AviSynth's own YUV histogram. You can see the middle U channel shifted left, with the bottom V channel where it should be. This frame was chosen as one having varied objects and a wide color scale of darks, midtones, brights, whites, flesh tones, etc.


The cap below is the same frame in RGB32 (PC.601, RGB 0-255). ColorTools shows the slow, early slope in Red and Green, making the video look washed out. Blue is displaced left and slopes too late, getting clipped at the low end. On tyhe right side, Blue peaks too early and slows too early, at least for this broad-spectrum scene.


You can play with RGB or YUV filters all you want, in any color space. The colors will never line up properly, and if you try it you'll severely clip either the brights or darks on at least two colors or often all three.

Another problem: the "brightness" or intensity of a color (hue) as you see it is partly related to its RGB value, but also to its Y-luma. The YDbDr spectrum doesn't scale color brightness the same way PAL and NTSC do. If you take pixel readings off this frame you'll see that blue goes all the way out to high RGB numb ers, yet the overall color balance often looks as if Blue is lacking in spots, even where it peaks at the dark end. This is not the forum to get into CIE color spaces, represented as triangles, but a color's position in that triangle has much to do with how we perceive it as "off" or "on" the right color. You see this especially in reds on this video, which tend toward orange or scarlet, but are never really a clean "Red".

So nothing goes forward until I learn to solve this colorspace mismatch.

Another bad sign: AviSynth's info() command says this video is "608x480" pixels, not 640x480 (and not 352x480). If you stretch a frame to 640x480, people look a little fat or squat to me. Oh, well...that's for later.

[poisondeathray]

New caps. This time, I'm just reading the original YV12 VOB's in AviSynth. No processing. Here's frame 10454 in YV12 with AviSynth's own YUV histogram. You can see the middle U channel shifted left, with the bottom V channel where it should be. This frame was chosen as one having varied objects and a wide color scale of darks, midtones, brights, whites, flesh tones, etc.

That's a good selection for a test frames, the girl with skin tones without the (white/grey/blue ?) pastey makeup on . I don't have that exact frame, but similar one from "operaC_original.mpg"

The cap below is the same frame in RGB32 (PC.601, RGB 0-255). ColorTools shows the slow, early slope in Red and Green, making the video look washed out. Blue is displaced left and slopes too late, getting clipped at the low end. On tyhe right side, Blue peaks too early and slows too early, at least for this broad-spectrum scene.

It looks washed out because Y=0 is mapped to RGB 0,0,0 and Y=255 is mapped to RGB 255,255,255 - so there is a contrast stretch compared to using truncated values if you are setup to decode and display as rec601. If you didn't all that data at the ends would be gone. That's about 13-14% of the data gone (assuming you had a source with data in that range). It's a similar idea to using a wider gamut colorspace to do your color corrections in photos, so you don't clip the data. When you export and convert back to YUV data using the PC matrix it will look fine (RGB 0,0,0 will be mapped to Y=16), when that YUV data is decoded for display with a rec601 matrix (YUV data has to be converted back to RGB again for display , and the way you have it setup will vary. Most hardware devices, DVD players will use rec601 for YV12=>RGB). I think there is a way to set it so you see it as if you were converting back to YV12, or you might have to fiddle with the vdub display or graphics card settings (well at least there is in other programs, not sure about vdub)

You can play with RGB or YUV filters all you want, in any color space. The colors will never line up properly, and if you try it you'll severely clip either the brights or darks on at least two colors or often all three.

You can use the channel swap , or coloryuv in YUV space to line up the channels in the histograms.

You can reduce the clipping by working in full range (and doing the full range RGB<=>YUV conversions instead of truncated) for the intermediate color correction.

Screenshots 1 & 2 demonstrate this. This was done in AE, frame 100, "operaC_original.mpg". 1) shows importing with rec601 conversion 2) shows importing with full range. As mentioned earlier, there isn't a lot of superdark Y<16 data, just some blips, but other cases are much more dramatic (especially when you are trying to recover blowouts and shadow detail). Notice the I set it so the preview displays the same (ie. no contrast stretch despite different YUV<=>RGB conversions) , because when I export with the proper matrix, that's how it will look. There might be a way to set it up in vdub as well.

1) Rec601


2) Full Range




Screenshot 3 shows the channel swap (with blue channel "fixed") , plus some minor curves adjustments afterwards, to demonstrate you can roughly line up the histogram. I purposefully crushed the low green values , because even with the channel swap, there was still a nasty green color cast. You can do similar shift with mergeRGB in avisynth

3) AE Channel Shift + curves




Screenshots 4 & 5 show it using coloryuv in avisynth , using off_u for the U channel. (just to demonstrate that you can shift it ; you still have to do color corrections, it's just a new starting point like the RGB blue channel swap).

4) Avisynth YUV histogram


5) Avisynth YUV histogram with coloryuv(off_u=-11)



I didn't bother with the border-color-fix in these examples, they are just to demonstrate fixing blue channel data or U channel data in RGB or YUV colorspace, as a starting point for color correcting (you would also do the color border fix in YUV space first)

Another bad sign: AviSynth's info() command says this video is "608x480" pixels, not 640x480 (and not 352x480). If you stretch a frame to 640x480, people look a little fat or squat to me. Oh, well...that's for later.

I don't have this problem. It works fine for me. What source filter did you use ? Can you post your script ?

[sanlyn]

Another bad sign: AviSynth's info() command says this video is "608x480" pixels, not 640x480 (and not 352x480). If you stretch a frame to 640x480, people look a little fat or squat to me. Oh, well...that's for later.

I don't have this problem. It works fine for me. What source filter did you use ? Can you post your script ?

First I made a .d2v project from the original VOB. Then this:

# original VOB/YUV source
LoadPlugin("C:\Program Files\AviSynth 2.58\plugins\DGDecode.dll")
mpeg2source("N:\Mignon02\Work01\VOB15_Wk1.d2v")
Info()

Good show, poisondeathray, thanks for the caps. I don't have AE, but in VirtualDub/AviSynth we both did pretty much the same thing. My original Opera_C, though, does have my Rec601 error in the final output. Haven't had time to rerun the later steps.

One can stretch and shift and get fairly close to decent colors, until you're an hour into the show. By then you notice Blue has been shrinking into the left-hand corner and audio is shifting right. Even without those oddities, color and brightness change several times, sometimes abruptly, as if someone fiddled with image controls during playback. By the end of the show Blue is severely suppressed; you don't need a histogram, it's obvious when you play the original DVD to a TV.

What we're doing with filters is trying to reconcile two different YUV colorspaces, YDbDr and YCbCr. Remember, our filters are designed to work with RGB and YCbCr, even if YCbCr really is what the Phillips recorded. The U/V formulas I posted earlier are similar to using colorYUV etc. to shift channels. But that simple formula doesn't quite work. One still fiddles for hours, and it changes every few minutes. I've also learned that YDbDr and YCbCr don't scale colors the same way, i.e., there are nonlinear gamma alterations and other minutiae I've been reading about. So there's no simple Add-2-here, subtract-4-there transform.

The methods poisondeathray shows are like those I used, and this just might be as close as we get to a fix. The CIE color gamut is still off (some of that is also due to VHS playback and NTSC hue problems themselves, plus cheap connecting cable, etc., as I've often seen).

If anyone wants to burrow really deeper (or has a/v engineering background) I found some C++ for converting colorspaces, including YDbDr. The "colorspace.m" function posted at this site (http://www.math.ucla.edu/~getreuer/colorspace.html) is for still images. I'm more interested in the general YUV principles, but have trouble translating C++ I haven't used since 1998 - and no way I'm digging up my old Visual Studio 6 and spending days installing, much less weeks learning stuff I never used anyway. The attached .zip has the html page and a subfolder with C++ code as an ".m" file (open it in Notepad). It's the same package you get from the site's download link.

[sanlyn]

An unfiltered cap from 2hrs 48-min, near the end of the tape. This is YV12 from the VOB with AviSYnth's YUV histogram. You can see that Blue has shifted farther left.


A few minutes later, with different colors. This is during curtain calls, so lighting should be more uniform, with more colors. If the previous scene might have been lighted a little warmly, this scene should have a more "neutral" range. It looks as if Red has shifted right. But that could be the red costumes. The guy's white shirt is red-yellow. His tux and shows are green, with red-brown schmutz. Red costumes: either they're red-orange, or the CIE scaling is really screwy. For all we know, they could really be pink.


The Blue shift is gradual, so I suspect it could be copy protection effects. If not, then it's heat damage. The question would then be, why is Blue damaged less at the start and more at the end? Having ruined a few tapes myself, here's my forensic guess:

The red stripe at the right side of this video is kinda uniform throughout the tape. This suggests the tape was stored upright, with one side near a source of direct heat. Either that, or the tape was stored one-side-down near a heat source. Either way, this would affect one edge of the tape more than the entire layer. Further, let's say the tape had been played to the end and then stored upright or face-down near a heat source, with the tape wound onto the right-hand takeup reel instead of the left-hand feed reel. This means that the end-of-show would be wound as the outer layers, and the start-of-show would be the inner layers. Thus the outer layers (ending) would have more exposure to heat.

Anyway, poisondeathray's excellent ChubbyRain2 did a good job cleaning that border.

[jairovital]

The red stripe at the right side of this video is kinda uniform throughout the tape. This suggests the tape was stored upright, with one side near a source of direct heat. Either that, or the tape was stored one-side-down near a heat source. Either way, this would affect one edge of the tape more than the entire layer. Further, let's say the tape had been played to the end and then stored upright or face-down near a heat source, with the tape wound onto the right-hand takeup reel instead of the left-hand feed reel. This means that the end-of-show would be wound as the outer layers, and the start-of-show would be the inner layers. Thus the outer layers (ending) would have more exposure to heat.

Forensic guess? lol. Furher more and you could tell me if the tape's owner is bald, or if he had a dog called Mercy

Just a joke, sanlyn. I'm loving this thread. You are doing an excellent job here. Because of this I was introduce to ColorTools and Avisynth histograms I never heard before.

Beyond this, there are great lesson about color schemas and patterns. Too much material to dive into and study till dawn morning.

Great!

[sanlyn]

When you export and convert back to YUV data using the PC matrix it will look fine (RGB 0,0,0 will be mapped to Y=16), when that YUV data is decoded for display with a rec601 matrix (YUV data has to be converted back to RGB again for display , and the way you have it setup will vary. Most hardware devices, DVD players will use rec601 for YV12=>RGB). I think there is a way to set it so you see it as if you were converting back to YV12, or you might have to fiddle with the vdub display or graphics card settings (well at least there is in other programs, not sure about vdub)

There are several lengthy threads with lordsmurf and jagabo about the way CCE and TMPGenc handle input for rendering to YV12 from other colorspaces. I couldn't find them. Had to stop looking to do chores. I don't recall exactly what CCE does with input, but I remember that one has to be rather careful and check everything twice. The upshot of those discussions was that TMPGenc "expects" RGB32/0-255, but can recognize different spaces and can tell if 16-235 comes in (most of the time, anyway). I always use AviSynth to make sure I'm sending RGB32/PC601 to TMPGenc. By default, TMPGenc works in RGB for its built-in image filters (also has YUV filters, too), and usually figures how to output correct YV12 for DVD on its own. Its defaults can be altered, but the opera's trouble enough as-is.

[sanlyn]

Forensic guess? lol. Furher more and you could tell me if the tape's owner is bald, or if he had a dog called Mercy

Wouldn't know about all that, jairo, but I'm guessing he was color-blind.

[sanlyn]

In some frames, there is uneveness - parts of the frames are colored differently. For example in test.mpg, in the beginning sequence, the background curtain is both blue and green - how can this be?

Oops. Missed this one, poison. The thingie with the big wave isn't a curtain. It's a scrim. Like lightweight canvas. When lighted from the front it appears opaque, though not 100%. When the scene behind it lights up, it looks transparent. Reduce the light in front and power up the lights in back, and you see mostly the scene behind it. It works like a "dissolve" in film. At some point the scrim was raised as the scene progressed, but raising the scrim seems to have been edited from the video. Sometimes when the lights behind are not up, you do see light reflected from objects behind it. We're probably seeing some reflection off all that green scenery behind the scrim.

See, I knew my M.A. in Theater Arts would be useful sooner or later .

[poisondeathray]

sanlyn - thanks I had no idea about the curtain. I don't have much experience with operas . With all the colored makeup, lighting, costumes (not to mention the crazy color cast ), I had no idea how it "supposed" to look like