Auto color a la Photoshop

[poisondeathray]

Off Topic:

Sometimes PNG can look different if a different host application was used to save or view the image. This is a separate, additional issue from the method of Y'CbCr => RGB conversion. PNG can have embedded gamma profiles, and some applications may or may not save them when exporting. Also, some image viewers , browsers and applications may react differently "seeing" the embedded profile, some apply the specified correction , some ignore it

[sanlyn]

True. Profiles have their use, but I avoid them like the plague. Keeping track of them will make you as ditzy as I am.

[2Bdecided]

@jagabo,

My ADVC110 captures are completely different from my HV20 - both outputting DV.

Sharply (single field) flashing lights and extreme amounts of noise will both create blocky artefacts with DV. Easily visible.

But with normal VHS, it's fine. IMO!

More importantly, it's one thing looking at lossless PNG captures of single frames and finding tiny differences between DV and lossless, but how can any expect to spot such differences on a DVD after MPEG-2 encoding and watching in motion?

If you're upscaling and/or encoding to high bitrate MPEG-4 and/or pausing the video and peering at the screen - then you might stand a chance.


I wonder how many people have done single frame A/B comparisons of their content before and after MPEG-2 encoding for DVD? I have. It's enough to make you weep. But doesn't look nearly as bad in motion, thankfully.

Cheers,
David.

[sanlyn]

I wouldn't expect a DV or MPEG render to appear exactly like the uncompressed original, even at high bitrates (that goes for PNG,JPG, etc.). The idea I'm looking into here (and which I maintain) is that cleaning up damaged, rotten-egg video captured to compressed video is much tougher than cleaning up a properly captured lossless AVI. But I know what you mean.

[poisondeathray]

True. Profiles have their use, but I avoid them like the plague. Keeping track of them will make you as ditzy as I am.

I hear you, it can mess up lots of things

But sometimes you get some images from someone else (maybe you're doing a cooperative project) , or even comparisons on various forums, someone posts a png with a gamma profile - it might look different in Safari vs. Firefox vs. IE for example. Just something to be aware of



But sort of on topic:

Different color model / color space other than sRGB can somtimes be useful in recovering data like clipped chroma and imbalances. Many modern day consumer and pro cameras alike clip chroma levels at a different rate than luminance. Everyone has seen "blue" vhs footage, where blue channels is foobar'ed.

Most programs don't deal with other models than sRGB, and the ones that do - they don't necessarily know how to access this unless it's been tagged with a profile. Because sRGB is relatively narrow (even if you use a full range PC matrix vs. a REC matrix, you can still "miss" information from Y'CbCr) , something like a wide gamut RGB (ITU Rec.1361), or Adobe RGB can sometimes be useful to work in so you can access data that would otherwise be out of gamut range and inaccessible. If you look at the sRGB "color model" attached below, all values of sRGB are contained within Y'CbCr, but the reverse isn't true - there is quite a bit of non-overlap


This example is from a canon DSLR (canon's typically clip red channel early) . Units are float in this example (not 8bit 0-255)

1) Rec601 conversion
2) PC601 (full range) conversion - some of the shadow blue channel , and highlight green are salvaged
3) Wide gamut conversion - more of each channel is salvaged, most importantly the red

The thinking is, if you have more data to start out with, you have a better chance of "improving" things

[omnimoeish]

Was this originally shot to VHS or 8mm film? If film, find the original film, and start from that. A modern frame-by-frame pixel-sharp transfer straight from film will be 1000x better than some lousy old dub with a VHS camcorder.

If it was shot to VHS originally, you could re-transfer it with correct levels and a good TBC - either one built into the deck, or the kind built into a few DVD recorders or camcorders with analogue inputs.

DV vs lossless is a fantastically small difference compared to either of these steps. If the destination is DVD, then DV is good enough unless you have more noise than picture (which DV can't cope with) - it's good enough even as the source for extensive restoration. Lossless is better still of course, but I defy anyone to spot the difference once you've encoded the result for DVD.


If this was 8mm film transferred to VHS, and you've lost the original film, then after a TBC transfer, you should look at recovering the original film frames from the video using IVTC, or some of the blend recovery scripts in AVIsynth (e.g. restore24, with appropriate settings for the actual frame rate of the source), probably before doing anything else.

Cheers,
David.

You mean the wedding video of my parents? That was shot directly on VHS in 1980 played on a JVC SVHS HR 4600U through S-video (of course). The main destination is for archiving purposes (although I might throw it on DVD just for some members of the family to have on hand). The Canopus 300 has a built in linear TBC and from what I've heard it's pretty good (granted probably not full frame TBC quality). Very few of my videos have significant noise, just a few scenes at low light levels. I am trying to decide the best way to archive the files. I was thinking of H.264. I'm considering running a bob deinterlacer because I don't think it will ever be viewed on an interlaced TV again (anyone that would ever watch it would have a progressive HDTV). I've heard its better to run a good software deinterlacer when encoding than leave it interlaced and having the hardware deinterlace on the fly.

I do have some VHS copies of film that I have no access to the films so I'll see if I can IVTC it.

[jagabo]

I've heard its better to run a good software deinterlacer when encoding than leave it interlaced and having the hardware deinterlace on the fly.

That's fine for current viewing but wrong for archival purpose. If you deinterlace now you will lock in that quality of deinterlacing forever. In the future there may be much better ways, even in the average TV. Leave your archived sources interlaced.

[omnimoeish]

I've heard its better to run a good software deinterlacer when encoding than leave it interlaced and having the hardware deinterlace on the fly.

That's find for current viewing purposes but wrong for archival purpose. If you deinterlace now you will lock in that quality of deinterlacing you get forever. In the future there may be much better ways, even in the average TV. Leave your archived sources interlaced.

Makes sense but will leaving it interlaced cause problem in converting it to H.264? I came across this but I'm not sure if I understand it all as well as I'd like.

[poisondeathray]

interlace h.264 is fine , if you plan to use sd blu-ray , or pc /htpc playback . DVD-video requires MPEG2

x264 uses MBAFF (it's adaptive now) and there were a bunch of patches implemented a few months ago to make it a complete interlace encoding solution

If these are important , personally , I would use a separate lossless archive, and a bob-deinterlaced version for viewing

[sanlyn]

The Canopus 300 has a built in linear TBC and from what I've heard it's pretty good (granted probably not full frame TBC quality).

Just a quick note: While tbc's come in varying "quality" (meaning precision of operation, stability, etc.,), a line-level TBC and a frame-level TBC differ by type, i.e, by function, not by quality. Some line-levels might be more or less effective than others, but they don't do what frame-level tbc's do. Likewise, frame-levels don't do what line-levels do.

To vastly oversimplify: a line tbc helps maintain the correct rate of line output within a frame. Unstable or irregular output of lines within a frame is usually visible as edges or objects that should be straight but play back with wiggles or kinks, or often with moire patterns. A line tbc ensures correct line output timing. A frame-level tbc ensures that the desired frame rate (for example, 29.972 fps) is maintained; a frame-level tbc has no effect on individual line timing within frames (for that reason, wiggly lines aren't corrected by full-frame tbc's).

[sanlyn]

1) Rec601 conversion
2) PC601 (full range) conversion - some of the shadow blue channel , and highlight green are salvaged
3) Wide gamut conversion - more of each channel is salvaged, most importantly the red

The thinking is, if you have more data to start out with, you have a better chance of "improving" things

The histograms often explain (?) why I make myself convert video to PC601 instead of Rec601, because Avisynth tells me in YUV or YUY2 that one or more colors is extended so far beyond the limits of the histogram that color data at extremes is being lost, even with strong correction attempts using ColorYUV or Tweak. I try to recover all I can, then readjust later for the proper matrix.

There are arguments for and against using wide-gamut hardware. In my case debate is limited: I can't afford wide gamut anyway. But I'm familiar with the info you posted (and my monitors do at least display 100% and a tad more of sRGB). Your presentation is better than most of the godawful complicated stuff I've seen elsewhere.

[sanlyn]

I second the archive tips from jagabo and poisondeathray. I archive at least two versions of the captures I care about most: the original lossless AVI, saved as uncompressed -- and we are talking about breaking that up into a lot of DVD's -- and the huffyuv or lagarith RGB24 working files. I also have backup copies of the final DVD's. But if you're thinking I could never do that with every video I work on, you're right.

[omnimoeish]

I second the archive tips from jagabo and poisondeathray. I archive at least two versions of the captures I care about most: the original lossless AVI, saved as uncompressed -- and we are talking about breaking that up into a lot of DVD's -- and the huffyuv or lagarith RGB24 working files. I also have backup copies of the final DVD's. But if you're thinking I could never do that with every video I work on, you're right.

Sanlyn, no one can accuse you of taking your video archiving lightly. Uncompressed AVI? What is the advantage in that over a lossless compression? Less chance for file corruption? You save your uncompressed AVIs to DVDs? Sounds like someone should've gotten a blu ray burner for Christmas.

By the way, what's the verdict on Lagarith vs Huffyuv?

[2Bdecided]

I don't know how the line TBC of the ADVC300 compares with those in high-end S-VHS VCRs, that in a Panasonic ES15, and those in good DV camcorders. I have a feeling it's not as good, but maybe someone has compared?

I've never found a use for a full-frame TBC. I get no jumping, no lost or dropped frames, and no instance where capturing stops. This is with an S-VHS machine with TBC straight into an ADVC110. Yet some people swear by a full frame TBC. Some people swear at them!


You should keep an interlaced archive copy, and use something like qtgmc for high quality double-rate (bob) de-interlacing for PC viewing copies. x264 is great.

Fix the chroma positioning (it always shifts on VHS). Ensure levels are correct.

Cheers,
David.

[2Bdecided]

@poisondeathray, I'm confused about what you're trying to show from the Canon DSLR - are you showing results from a video, or still? MPEG/JPEG/Raw/?

It looks to me like the levels are simply wrong, and should be fixed before whatever conversion you choose to do. The spikes on your green and blue histograms for Rec601 and PC601 suggest both change the data (histogram spikes are a tell-tale sign of re-quantisation / re-scaling), while the "full range" conversion doesn't.

Cheers,
David.

[sanlyn]

uncompressed AVI: an extra safety measure. Due to what are laughingly referred to as "technical complications", compression support goes thru so many revisions, install problems on various systems, planned obsolescence (e.g., Bill Gates wants you to destroy all your belongings every 18 months, ffdshow decoders are revised every 30 minutes, your brand new Windows-12 Service Pack 25 machine won't recognize your PC's motherboard any more, etc.), I figure uncompressed AVI is universal like a VISA card. I keep my eyes open for signs that engineers might forsake all AVI containers, and am prepared to act accordingly (I don't keep that many videos by this method). A typical AVI archive is 7 to 12 single-sided DVD's. I don't archive on bluray (a whole archive on one media disk: One bad scratch? Bye bye archive). Goes back to the old days as a programmer watching entire systems shut down for one small, stupid reason or another.

Of course, the world will end this year, so these precautions are futile. Or something else will happen. One can only try.

Most of the time I keep a final max-bitrate MPEG2/DVD version and a backup of that disk, then delete the AVI captures and (usually) throw away the old VHS. But family stuff and a few others get the full megilla.

I think just about everyone uses huffyuv and/or lagarith, and has for centuries. Some players (like VLC) can't read one or both. Good stuff, but nothing is perfect.

[sanlyn]

I don't know how the line TBC of the ADVC300 compares with those in high-end S-VHS VCRs, that in a Panasonic ES15, and those in good DV camcorders. I have a feeling it's not as good, but maybe someone has compared?

I haven't used 'em all, but my Toshiba "RD" recorders seem to do a visibly cleaner job than my ES-15 or -20 -- but this is at the nit-picking level.

I've never found a use for a full-frame TBC. I get no jumping, no lost or dropped frames, and no instance where capturing stops. This is with an S-VHS machine with TBC straight into an ADVC110. Yet some people swear by a full frame TBC. Some people swear at them!

Yep. I've had to chain a frame-level after a line-level unit for some copy-protected stuff. Had to use it for some parts on a damaged VHS transfer project. I don't use my AVT-8710 most of the time, but sometimes it comes in handy. Now and then the darn thing balks about showing a clean image, so a few shut-down/turn-on cycles are needed. It's 12 years old. Swearing at it seems to speed things up.

[poisondeathray]

@poisondeathray, I'm confused about what you're trying to show from the Canon DSLR - are you showing results from a video, or still? MPEG/JPEG/Raw/?

It looks to me like the levels are simply wrong, and should be fixed before whatever conversion you choose to do. The spikes on your green and blue histograms for Rec601 and PC601 suggest both change the data (histogram spikes are a tell-tale sign of re-quantisation / re-scaling), while the "full range" conversion doesn't.

Cheers,
David.

DSLR video . Yes, this was an extreme example, under colored lighting. It's normally not that bad, and fixing it in YCbCr before converting to RGB is what you normally would do. But there are cases where there is still clipping despite that. This is showing Rec 1361 allows you to work in a wider space, and can sometimes be beneficial in a workflow

Not sure why the quantization is seen, I think it's from seeing 256 levels per channel distributed over 65526 levels, because it appears "smoother" in 8-bit values 0-255. A true raw source would not have any quantization. I'm not sure why the wider gamut appears to smooth things over.

[poisondeathray]

Lagarith - higher compression, but slower (encoding and decoding). Has a ffmpeg implementation with decoding, but no encoding yet. Having an ffmpeg implementaton and sources available means futureproofing, eg. if developer stops work you don't have to worry that you can't use your video

Huffyuv - beware of multiple variants and versions, sometimes there are incompatiblities between them. There is a ffmpeg variant for encoding and decoding

Both work fine on PC and in NLE's, but problems on a MAC , FCP

[2Bdecided]

HuffYUV doesn't support YV12 in all implementations. I use that for lossless intermediate files except where I need YV12. I mostly need YV12, so I mostly use LAGs.


I share sanlyn's paranoia about what will play in the future, but that pushes me to high bitrate lossy sometimes for a "safe" archive - MPEG isn't going anywhere any time soon. Or ever.

I guess uncompressed AVI is equally safe because at its heart its just raw video which will always be readable. Too much data though - you're never going to remember to re-back-up those 13 DVDs in time. It's getting OK with SD video, but still too much for HD.

Cheers,
David.

[sanlyn]

I share sanlyn's paranoia about what will play in the future, but that pushes me to high bitrate lossy sometimes for a "safe" archive - MPEG isn't going anywhere any time soon. Or ever.

I keep high-bitrate MPEG as well. For less "memorable" stuff, I keep just the MPEGs.

I guess uncompressed AVI is equally safe because at its heart its just raw video which will always be readable. Too much data though - you're never going to remember to re-back-up those 13 DVDs in time. It's getting OK with SD video, but still too much for HD.

I'll have to go HD/BR in the future. Soon. All I need is the usual setback -- ready currency and building another new PC with a Hauppauge HD PVR. I still have about 100 old VHS's of stuff that will never be on the shelves in digital, so the old PC and its backup copy have to keep going for a while.

[omnimoeish]

Fix the chroma positioning (it always shifts on VHS). Ensure levels are correct.

Cheers,
David.

Can you elaborate on a good way to do this? I've got a few videos that are a chroma nightmare.

[omnimoeish]

You mentioned V-cord tapes: you won't find ANY decent used consumer playback devices for those (maybe/possibly/rarely on ebay). I would strongly suggest you leave those to a decent professional transfer house.
Scott

I'm surprised you know about V-cord. I can barely even Google anything about them. I have found exactly 2 places in the WORLD, make that universe (I don't know any aliens that use V-cord either) that transfer them. Prices?... Right around $5,000 for the batch from video interchange. Yikes.

[Cornucopia]

I knew about it from my schooling at UT Austin Radio-TV-Film.

Unfortunately, that's kind of the price one pays if you wait too long to "data migrate". And this will apply to EVERY form of data...

Scott

[2Bdecided]

Fix the chroma positioning (it always shifts on VHS). Ensure levels are correct.

Cheers,
David.

Can you elaborate on a good way to do this? I've got a few videos that are a chroma nightmare.

There's this...

http://avisynth.org.ru/docs/english/externalfilters/chromashift.htm

...but I usually just use something like...

# Fix (S-)VHS chroma shift
Vshift=2 # determine experimentally
Hshift=2 # 2 lines per bobbed-field per tape generation (PAL); original=2; copy=4 etc
mergechroma(last.crop(Hshift,Vshift,0,0).addborder s(0,0,Hshift,Vshift))

...after bobbing. You have to be more careful if you try to do vertical shift without bobbing. You'll need to think about changing the crop and addborders calls if you want to shift in the opposite direction.

Cheers,
David.

[omnimoeish]

I attached a problem chroma screenshot. I'm still working towards being able to use Avisynth (why oh why can't they all just be Virtualdub filters?!) but nothing is quite working so far. I first tried to use Virtualdub mod with no avail. I got a script online that is supposed to employ the qtgmc bob filter but it's putting an overlay on my video saying "Plane Difference: Only planar images (as YV12) supported! ([Conditional Filter, Expresion 1], line 1)". Anyone know how to fix that? The script I have is:

function filldropsI (clip c)
{
even = c.SeparateFields().SelectEven()
super_even=MSuper(even,pel=2)
vfe=manalyse(super_even,truemotion=true,isb=false, delta=1)
vbe=manalyse(super_even,truemotion=true,isb=true,d elta=1)
filldrops_e = mflowinter(even,super_even,vbe,vfe,time=50)

odd = c.SeparateFields().SelectOdd()
super_odd=MSuper(odd,pel=2)
vfo=manalyse(super_odd,truemotion=true,isb=false,d elta=1)
vbo=manalyse(super_odd,truemotion=true,isb=true,de lta=1)
filldrops_o = mflowinter(odd,super_odd,vbo,vfo,time=50)

evenfixed = ConditionalFilter(even, filldrops_e, even, "YDifferenceFromPrevious()", "lessthan", "0.1")
oddfixed = ConditionalFilter(odd, filldrops_o, odd, "YDifferenceFromPrevious()", "lessthan", "0.1")

Interleave(evenfixed,oddfixed)
Weave()
}

objVideoD = AviSource("source.avi")
ConvertToRGB(objVideoD)
filldropsI(objVideoD)

#swap fields
SeparateFields().Trim(1,0).Weave()

#deinterlace
QTGMC( Preset="Placebo", FPSDivisor=2, Sharpness=0.5 )

I was going to worry about getting it to work before I tweaked any of the other settings ie sharpness. Thanks for any help you can offer.

[poisondeathray]

Don't convert to RGB , filldrops requires YV12

AviSource("source.avi")
ConvertToYV12(interlaced=true)
filldropsI()

#swap fields
SeparateFields().Trim(1,0).Weave()

#deinterlace
QTGMC( Preset="Placebo", FPSDivisor=2, Sharpness=0.5 )


function filldropsI (clip c)
{
even = c.SeparateFields().SelectEven()
super_even=MSuper(even,pel=2)
vfe=manalyse(super_even,truemotion=true,isb=false,  delta=1)
vbe=manalyse(super_even,truemotion=true,isb=true,d  elta=1)
filldrops_e = mflowinter(even,super_even,vbe,vfe,time=50)

odd = c.SeparateFields().SelectOdd()
super_odd=MSuper(odd,pel=2)
vfo=manalyse(super_odd,truemotion=true,isb=false,d  elta=1)
vbo=manalyse(super_odd,truemotion=true,isb=true,de  lta=1)
filldrops_o = mflowinter(odd,super_odd,vbo,vfo,time=50)

evenfixed = ConditionalFilter(even, filldrops_e, even, "YDifferenceFromPrevious()", "lessthan", "0.1")
oddfixed = ConditionalFilter(odd, filldrops_o, odd, "YDifferenceFromPrevious()", "lessthan", "0.1")

Interleave(evenfixed,oddfixed)
Weave()
}

Are you sure you need to "swap fields ?" That's for a field shift fix . Or did you just copy that from somewhere ?

[themaster1]

Your caps look great to me omnimoeish except there is a certain amount of chroma noise easily spotable, try fft3d, neat or similar

[jagabo]

The colors of the two fields are different in the wedding dress picture.

[sanlyn]

The colors of the two fields are different in the wedding dress picture.

The top image appears to be shot under overcast (there are no shadows). That image has a similar problem as the earlier ones, blue is shot sky-high and the other colors look crippled. The shot of the flowers really needs work, highlights don't even exist in there. I'd say there's lots of work to do before thinking about "sharpness". Sharpening is the last thing I'd do with those videos.