Filter: ColourLike

[mg262]

This was mentioned in a recent thread (http://forum.doom9.org/showthread.php?t=95574) -- thanks to @communist + everyone else who fed me with ideas, pointers & encouragement.
___________________________________________

ColourLike (http://people.pwf.cam.ac.uk/mg262/posts/colour/ColourLike_230505.dll)

Brief description: Makes a clip look like a 'reference' clip by adjusting each colour channel.

Search keywords: colour, color, ColorLike, curve, gamma, levels, channel.

Full description:

WriteHistogram(clip, string outputFile, int every = 1) - computes histograms for each channel of the YV12 clip and stores the results in outputFile. If e.g. every=3 is specified, only every 3rd frame of clip is sampled.

ColourLike(clip source, string sourceHistogramFile, string referenceHistogramFile) - takes a YV12 clip source and histogram files for this clip and a reference clip, and applies curves to each channel, chosen to make source look as much like the reference as possible.

Examples:
Here are some examples from a case where the same clip is present in (unrelated) DVD and VHS sources.

First generate the histograms:

dvd.WriteHistogram("dvd hist 100.txt", 100)
vhs.WriteHistogram("vhs hist 100.txt", 100)

Then, say, adjust the VHS to look as much like the DVD as possible:
vhs.colourlike("vhs hist.txt", "dvd hist.txt")

Or adjust the DVD to look as much like the VHS as possible
dvd.colourlike("dvd hist.txt", "vhs hist.txt")

Here are some screenshot showing the results of both of the above, in the following format:

http://people.pwf.cam.ac.uk/mg262/posts/colour/format.jpg

i.e. the top two pictures are original and the bottom two have been passed through the filter; bottom left is the DVD passed through a curve chosen to make it look as much like the VHS as possible, etc.

YUV colour space
http://people.pwf.cam.ac.uk/mg262/posts/colour/yuv global 1.jpg http://people.pwf.cam.ac.uk/mg262/posts/colour/yuv global 2.jpg http://people.pwf.cam.ac.uk/mg262/posts/colour/yuv global 3.jpg

Notes:
- Generating histograms runs at about 75fps on DVD source on my PC (and I think most of that time is MPEG decoding), but this still seems slow because the entire file needs to be scanned. As in the example, you can specify quite a large value of every without affecting the results too much.

- You only need to generate the histograms once, so you probably want the WriteHistogram calls in a separate AVS to ColourLike.

- This filter can be used on completely unrelated clips (which I haven't tried yet); I don't actually think that is a particularly meaningful thing to do, so I'm pretty pessimistic about the results -- but if you do happen to try it, see what the results look like when you just use it on the Y channel, and also when you just use it on the U&V channels. (Use MergeLuma or MergeChroma with source and the output of this filter.)

- For the record, I'm not terribly happy with the results of the filter overall -- as I noted in that other thread, I think there is 'crosstalk' between the colour channels that this process does not account for. So I think a proper colour matching function will have to use something more sophisticated than channel-curves.

[AS]

Thanks. I am really interested in trying this on totally unrelated materials, e.g. one is bright and other one is very very dark. ^_^

[joshbm]

Ooooo.... Ahhhh....

Time to do some tests with this. Could one supposedly get a "film" look with this by tricking it?

Ex. Take the DVD footage of a desired film and your DV Cameras footage?

Regards,
joshbm

[unskinnyboy]

@mg262, Shouldn't the name of the file be ColourLike_230506.dll rather than ColourLike_230505.dll? This is June you know, not May. ;)

[mg262]

@AS, @joshbm

When you're applying it to unrelated material, the difference in content can cause a problem. For example think about using The Sound of Music as a reference clip (or even a football game). There's lots of grass and outdoor scenes, so a lot of the video is green -- so the clip you're adjusting will become quite green in places, regardless of it's content. So try to keep the content of the clips as similar as possible. (Also don't make them too short.) Plus as I said try original.colourlike(...).mergechroma(original) (that applies particularly to your case, @AS!)

The first histogram (sourceHistogramFile) doesn't actually have to come from the clip you're using the filter on (a.k.a. source). The curve is generated from the pair of histograms(sourceHistogramFile and referenceHistogramFile), so if you find a pair that work nicely, try using them on other clips. In particular, if you can find a couple of clips with very similar content, one DV and one film, you can try this:

dv.WriteHistogram("dv hist.txt", 100)
film.WriteHistogram("film hist.txt", 100)

Then, on any DV clip:

someotherDVclip.colourlike("dv hist.txt", "film hist.txt")

This is all a bit theoretical as my only sources are DVDs or taped from TV... at the end of the day, try stuff and see if it works -- and put up some screenshots so we can bounce ideas off each other!

@unskinnyboy

Oops. You're totally right, although I would have called it 230605, that being the format we use in England. Maybe I should switch to 23Jun05 to avoid confusion...

[ac-chan123]

Hello,

I have a question aboiut your source. This was "Bell und Sebastian" in germany. But it was only one or two times in TV and never releaed on VHS or DVD. But you have a DVD. Where was that released? Have you the Name of the release and the Company?

[AS]

@mg262

I understand exactly what you mean but that's also precisely reason why I want to do it.

[mg262]

@ac-chan123 - I've PMed you with all the information.

@AS - in that case, go for it!

[Mug Funky]

the crosstalk issue could be helped by working in HSV space, but there still may be things that it misses. colour-grading (especially digital) can involve some bizarre mixing of channels that would be tremendously difficult to reverse-engineer. as long as the channel mixing is uniform it should be okay, but if for example saturation is increased by subtracting RGB channels, all with different matrices, things could get difficult. also those photoshop colour adjustments that work on lows, mids and highs could be hard to pick from a yuv or rgb histogram.

[mg262]

I did think about implementing HSV (or HSB, HSL, etc.) but Poynton was so rude (http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC36) about them that I was put off.

What I was thinking of doing was adding a RGB mode to this filter (tedious but straightforward) and implementing a ConvertToHSV which stuffed H into the R channel, S into the G channel, etc. -- so all the standard tools could be used on that colour space. It is an unpleasant hack but probably tolerable in a scripting language.

I'd never heard of colour grading before, but as you say anything which applies operations in more than one colour space will be messy to reverse. I think I do know of a way to attack the problem with a bit of maths but I'm probably not going to follow it up now because I don't have suitable data to test it on -- and also I'm working on way too many filters at once!

Edit: I've just read about the ?standard? colour grading tool Lustre and it uses 32-bit/component colour depth :scared:

[HighInBC]

Thanks, this is a great filter, and I intend to use it often.

[trevlac]

@mg262

Great idea ... I have some thoughts that may or may not be helpful.

1st - I couldn't find your source or the source of Alexander Nagiller's test YUV curves fitler ... so I'm not sure how you do curves on the U/V. Not sure my knowledge of this matters since you say processing in RGB is much the same.

But Some Ideas ....

- If you process a clip with it's own histogram ... is it different due to any averaging across the entire clip ? Sorry ... I've had no time to really test. I can't run avs on my work machine. Maybe this is a silly question.

- I looked closely at the image of the boy going from VHS to the DVD look. It looks like there are 'outlying' colors (a green/cyan and a purple) in the DVD that are just not there in the VHS. It would be hard to come up with those.

- For cross channel correlation ... maybe you can do multiple color spaces at once. For example, if you do RGB and add luma in the mix, you have a correlation between the RGB channels with the luma.

- As I understand it, the eye is much more sensative to change in brightness vs changes in hue. You might focus on luma. You could even test on B&W images.

- Have you thought about doing some sort of normalization before you compare the curves? For example, setting black level ... setting white level ... and maybe even converting the gamma adjustment back out.

- How about doing mini adjustments on parts of the spectrum? For example, adjust cyan within the range of cyan ... as far as hue and brightness goes.

--------------------
Just some ideas ... frankly ... i think your results look great right now. :D

[mg262]

@trevlac:

Wow -- lots of ideas :) Thank you!- If you process a clip with it's own histogram ... is it different due to any averaging across the entire clip ? Sorry ... I've had no time to really test. I can't run avs on my work machine. Maybe this is a silly question.Not a silly question at all... I really should have explained how the filter worked earlier... I'll post a proper account in another post, but here are the key points.

1) The method used only considers one colour channel. Each colour channel is treated completely separately. So e.g. the U of the output clip depends only on the U of the input clip and the Us of the two clips used to generate the histograms.

2) (In a single colour channel), given two histograms, there is a unique increasing* curve that makes the first one look like the second one, and that curve is picked. What that really means is that if e.g. 4.3% of the reference pixels have a value of U=120, the source is adjusted so exactly 4.3% of the adjusted pixels have a value of U=120. (Of course there are inaccuracies due to rounding and the too-low 8-bit colour depth.)

*By increasing I mean that higher values are always mapped to higher values -- i.e. the curve always keeps going up. This is IMO a very sensible restriction!

Using a clip's own histogram on itself has no effect, because (following the example in 2), with the same clip as source and reference.) the way to make sure exactly 4.3% of the adjusted pixels have a value of U=120 is to leave them alone.- As I understand it, the eye is much more sensative to change in brightness vs changes in hue. You might focus on luma. You could even test on B&W images.(From 1) above) Y is processed separately to the other channels -- so to the extent that Y is a good representation of luma/brightness, that's kind of happening already. On a B&W clip produced from another B%W clip, the result should be mathematically precise -- i.e. it would reverse any (increasing) curve perfectly. So if you were to take a B&W clip and do any kind of levels/gamma to it, the filter should be able to reverse that perfectly. If it doesn't, either my code is buggy or rounding/condition errors are coming in. - Have you thought about doing some sort of normalization before you compare the curves? For example, setting black level ... setting white level ... and maybe even converting the gamma adjustment back out.That is a good idea... you could presumably do it by applying Levels to the clips before WriteHistogram and ColourLike? Converting gamma adjustment back out is a bit more complex...I need to generate/post some pictures to talk about this which I'll do a bit later.- I looked closely at the image of the boy going from VHS to the DVD look. It looks like there are 'outlying' colors (a green/cyan and a purple) in the DVD that are just not there in the VHS. It would be hard to come up with those.You have very sharp eyes. Outliers are generated in each colour channel to the extent that they exist in the reference (because of 2) above), but I think what's happening here is that those points are outliers in both U and V at once -- and while the filter generates outliers in U and outliers in V, they don't necessarily coincide...

Not sure what to do about this, but this and some of your other points are pointing to words HSB (=HSV) or HSL. (Your other two points I'm still thinking about...)

BTW, The source code is in a state that I would feel a little embarrassed about posting, but you're more than welcome to it -- just drop me an e-mail/FTP.

[trevlac]

Converting gamma adjustment back out is a bit more complex...I need to generate/post some pictures to talk about this which I'll do a bit later.

I really look forward to this. I have been trying to learn this color topic for quite some time. :)



You have very sharp eyes. Outliers are generated in each colour channel to the extent that they exist in the reference (because of 2) above), but I think what's happening here is that those points are outliers in both U and V at once -- and while the filter generates outliers in U and outliers in V, they don't necessarily coincide...

I looked at the pictures on a vectorscope. It was easy to see the different colors there. Below are some pics I made of the boy and the hills. Unfortunately ... because I had to resize things to do a reasonable post ... the 'outliers' are not visible. But in the boy they were actually in the VHS and remained there after your filter. More colors were in the VHS.


Not sure what to do about this, but this and some of your other points are pointing to words HSB (=HSV) or HSL. (Your other two points I'm still thinking about...)


Anyway ... I posted these pics because it shows that the shape of the color distribution does not really change. It shifts around (hue) and changes size (sat) ... but the shape remains the same. I think this points to maybe doing an adjustment targeted to each of the specific areas of the spectrum. This might work best as a 2nd pass.


http://www.trevlac.us/pics/colorlike1.JPG

http://www.trevlac.us/pics/colorlike2.JPG



BTW, The source code is in a state that I would feel a little embarrassed about posting, but you're more than welcome to it -- just drop me an e-mail/FTP.
I will have to ask for this at some time later. Right now I was just looking so I could see exactly what you were doing. You've been kind enough to explain. I hope to have some time in the future to devote to this. :D

[mg262]

@trevlac, that the vectorscope of yours is awesome. It's going straight into my AVS autoload directory. I missed it when I first came out because I didn't know what a vectorscope was... may be worth putting screenshots on the plug-in's thread?

More soon...

Edit: Okay, I can see Poynton's point:

Y is calculated as 21% red + 72% green + 7% blue

and this is a pretty good measure of luma, i.e. corresponds to what we intuitively think of as luma. In other words, the blue level has hardly any effect on how bright something seems.

Now HSB, HSV, HSL, etc all calculate the brightness/saturation/lightness as

33% red + 33% Green + 33% blue

and this is a horrible measure of luma, because it assumes blue has as much effect as green. So using one of these spaces would throw away all the 'focus on luma' that @trevlac mentions.

Poynton suggests* instead that we hold on to Y as it is, but replace U and V with the angle and length of the vector (U,V). I.e. we use the angle and distance from centre of the coloured points on @trevlac's vectorscope pictures above. This make sense, because you can see that each line going out from the centre (corresponding to an angle) seems to correspond to an intuitive 'colour', and that the further from the centre you get the more vivid colours become.

*Actually Poynton suggests doing this in a colour space called CIELab -- but leave that for now.

[joshbm]

How do I generate the histogram? I've put in "writeHistogram" and dragged it into VDub it writes an empty file... Please don't tell me I have to render it. I've also tried playing the file in WMP 6 and it gives an exception error to the line where writeHistogram is (but generates a blank file).

Regards,
joshbm

[mg262]

You don't have to render it, although should be some delay as it scans through the source file. I'm really sorry it's messing up... could you post the script and if possible e-mail me a short section of the source file (I'll PM you with an e-mail address)?

[joshbm]

AVISource("G:\uvs050630-001.AVI",fourCC="CDVC")

FixBrokenChromaUpsampling()
ReInterpolate411()

WriteHistogram("3ccd.txt", 100)


That is my code. Short and simple.

Regards,
joshbm

[mg262]

Oops... we sorted this out by PM just after that last post, but I've been useless about updating the thread. It was a colour space problem -- I had carelessly omitted the warning message from the version I released and also my note in the original post that it needed to be YV12 can easily be missed. So - YV12 !

I know I said I wasn't going to keep developing this, but after all the positive comments (thank you!), I did anyway. I added RGB32 support and optional parameters so you can select which planes are processed (and also proper error messages ;) ). I had almost finished adding polar UV support -- essentially using luma, colour and saturation as channels but still working in YV12. I've got a bit tied up but hopefully things will calm down after the weekend...

[mg262]

I'm really sorry this has taken so long -- I put this down and had a mind block on picking it up again.

ColourLike, 31 Jul 05 (http://people.pwf.cam.ac.uk/mg262/posts/colour/ColourLike_31Jul05.dll)

It now has RGB32 support and also you can write this sort of thing:

vhs.colourlike("vhs hist.txt", "dvd hist.txt", true, false, false)

which means: just process Y (respectively R) but ignore U and V (respectively G and B).

It also has a polar-YUV mode, which as its 3 channels has Y, length of the UV-vector and angle of the UV-vector. Currently the angle is not changed by the filter (see below).

You can use that like this:

dvd
WritePolarHistogram("dvd polar hist 1.txt", 1)
vhs
WritePolarHistogram("vhs polar hist 1.txt", 1)

dvd.polarcolourlike("dvd polar hist 1.txt", "vhs polar hist 1.txt", true, true, true) #last 'true' is ignored

This should in theory change the brightness, contrast, saturation, etc but not affect hue. I haven't found this to be very useful in practice. I think a variant which changed hue would be more useful, but this is ill-defined... or more precisely, because you is represented by a circle rather than a line, there is a whole family of 'hue-equalising' filters...

Be careful to feed the filter with the right kind of histogram... YUV, RGB and Polar-YUV are three different kinds.

[mg262]

This should in theory change the brightness, contrast, saturation, etc but not affect hue. I haven't found this to be very useful in practice. And that would have something to do with the fact that I forgot to centre the polar colour space at (U=128, V=128) rather than (U=0, V=0)... :o :stupid: :stupid: :stupid: . It now works:


ColourLike, 25 Aug 05 (http://people.pwf.cam.ac.uk/mg262/posts/colour/ColourLike_25Aug05.dll)

http://people.pwf.cam.ac.uk/mg262/posts/colour/polar_saturation.jpg

I've also added a saturation gamma function. The idea is this. A normal gamma operation can brighten or darken midtones while (approximately) leaving highlights and shadows alone. The saturation Gamma can increase or decrease the saturation of areas with medium saturation, while leaving greys and very saturated areas alone. I will some screenshots at a later date, but here is the syntax:

SaturationGamma(clip, float gamma, float fixed = 127.0)

The fixed parameter gives a "very saturated" saturation level [measured as a distance from (128,128)] that will be left alone by the function... but it will work fine if you leave this number at default. When I have a bit more time I will generate some screenshots that will make the use of the function clearer...but the results are (in my view) quite interesting, so do give it a go!

(Incidentally, I haven't forgotten that I promised to write something about Gamma, I'm just being rubbish and have taken on too much... I will get round to it.)

Edit, to recap:

dvd.polarcolourlike("dvd polar hist 1.txt", "vhs polar hist 1.txt", true, true)

The first true tells the filter to affect luma, and the second true tells it to affect saturation.

[mgh]

Works well for both luma and chroma correction, but only with latest virtualdub.
I have some vcds with wrong color and either too dark or too bright. Have tried correction using a video file with visually OK color and luma balance .
Script
loadplugin("C:\Program Files\dgindex\\DGDecode.dll")
mpeg2source("C:\Program Files\vcds\video.d2v",cpu=6).lanczosresize(400,300)
FFT3DFilter(OH=16,OW=16,BH=48,BW=48,BT=3,Sigma=1,Sharpen=1)
vid=RemoveGrain(last,mode=12).autocrop(mode=0,wmultof=16,hmultof=16,samples=16,Aspect=0,threshold=50,samplestartframe=0,leftadd=0,rightadd=0,topadd=2,bottomadd=2).aSharp(0.4,0,0).aWarpsharp(3,1,bm=3,cm=0,thresh=0.99)
WriteHistogram(vid, "C:\Program Files\vcds\video.d2v.txt", 100)
vid1=avisource("D:\videos\good.avs")
WriteHistogram(vid1, "E:\capture\good.txt",100)
vid=vid.colourlike("C:\Program Files\vcds\video.d2v.txt", "E:\capture\good.txt", true, true,true)
return vid
Works very well with virtaualdub 1.6.10-a total mess with virtualdubmod 1.5.10 and avs2avi 139.
Do not know why. Have asked the question in virtualdub forum
http://forum.doom9.org/showthread.php?p=705594#post705594
which has samples.

[mg262]

Sorry to hear about the problem; it's much more likely to be a problem at my end than in VDM -- but I use VirtualDubMod 1.5.10 all the time, so it's not a blanket incompatiiblity. When I am back at my own PC (some time from now) I will download the samples + investigate -- but in the meantime, if you can, please post a minimal problem-causing script, i.e. remove as many other filters as possible. Also, once the text files are wriiten once, you don't need to write them again -- so this sort of thing should do:

loadplugin("C:\Program Files\dgindex\\DGDecode.dll")
mpeg2source("C:\Program iles\vcds\video.d2v",cpu=6)
colourlike("C:\Program Files\vcds\video.d2v.txt", E:\capture\good.txt", true, true,true)


Edit: the AVI is YV12, yes?

[mgh]

The avs is yv12.
From the virtualdub forum, it looks like the difference maybe because vdub 1.6.10 uses its own internal yv12 decoder. The problem does not occur with all videos. With the particular video, this script solved the problem
loadplugin("C:\Program Files\dgindex\\DGDecode.dll")
mpeg2source("C:\Program iles\vcds\video.d2v",cpu=6)
colourlike("C:\Program Files\vcds\video.d2v.txt", E:\capture\good.txt", false, true,true)
LumaYV12(lumoff=-10)

[mg262]

Would you mind trying the following?

Take a video on which the problem occurs -- preferably a very short clip. Open up the video in the latest version of VirtualDub (so you get the correct results) and save the results to an AVI file using direct stream copy.

Now open up the resulting file in any of the programs that cause a problem. How does it look?

[mgh]

Have been doing some trials. Problem occurs only with videos which contain large dark areas or large bright areas-a known problem for encoders;maybe also problem for some decoders sometimes.
Basically, I am trying it with VCDs and my initial attempts at TV captures with bad encoding/capture-to correct color balance and levels. With luma disabled, the color balance correction has worked with everything I have tried. With luma enabled it works with all vids except of the type I have mentioned.
DVDs do not have the problem-these days i just load in avi.NET and encode at default settings to get standalone compatible divx/xvid files or use DVDShrink to get the size down to fit single layer DVD-using error correction. Either way is totally painless.
Vcds tend to have blockiness and color/levels problem-blockiness because of limited bitrate and overbright or overdark to reduce bitrate requirement. DGIndex/DGDecode is excellent at deblocking and decoding. Your filter takes care of color problems with all and levels with most vids painlessly.
The problematic videos are best tackled to my eye by the LUMAYV12 filter built into DGIndex/DGDecode-the lumoff parameter is the most useful.

will try out your suggestion and let you know.
Thanx

[mg262]

@mgh,

From the last post, I'm not sure whether you've given up on diagnosing the problem. There are some things I was going to say after you had run the tests I suggested... but I may as well say them now. The first is that if you start with a very dark or very bright video, you are effectively using a very low colour depth -- and applying any sort of per-pixel operation, as ColourLike does, will result in artefacts due to the low colour depth. That is not a bug in the filter. Simply applying levels would have resulted in similar problems.

In your case, because the material is compressed using a block by block method, the artefacts that show up most clearly are blocks. Applying a deblocking filter as you have done is the correct approach to this.

Second, the curious feature about this problem is that different decoders are producing different outputs. If I had produced the filter as a standalone program, I think there would be a fair chance that I had included some sort of bug in the output method which accounted for this -- but in this case, almost all the interface work is being done by AVISynth and so I'm more inclined to think that one of your decoders is doing something unexpected. This may simply be a matter of how it is configured -- for example, FFDshow has a built in deblocking filter that can be used on material as it is played back.

Third, it's not difficult to isolate the cause of the difference. The AVI file that you would obtain by using a direct stream copy should be identical to the frameserve output of the AVISynth script. So if you were to generate this file, and find that the difference persisted when opening it in different programs, it would be certain that it was the decoders that caused the difference. You could then try to understand why one of the decoders altered the output... and if I were in your place, I would certainly try to do this as it might be that one of your decoders was altering every file opened on your system (although generally in a way that was less obvious than in this case).

[mgh]

Sorry for delay in reply. Have been experimenting. Unable to reproduce problem with the same or other sources. May be some mixup on my part somewhere.
I am now using this as template.xls with dgindex

loadplugin("C:\Program Files\dgindex\DGDecode.dll")
Function correctcolor( clip clp, bool c) {
c==true ?writehistogram(clp,"histo.txt",100):NOP
c==false ?NOP:colourlike("histo.txt","C:\Program Files\dgindex\good.txt",false,true,true)
}
mpeg2source("__vid__",cpu=6)
aud="__aud__"
f=framerate()
f ==29.97 ?separatefields().doubleweave().pulldown(0,2):NOP
w=width()
w==352 ? lanczosresize(352,264):fielddeinterlace().lanczosresize(640,480)
RemoveGrain(mode=12).autocrop(mode=0,wmultof=16,hmultof=16,samples=16,Aspect=0,threshold=50,samplestartframe=0,leftadd=0,rightadd=0,topadd=0,bottomadd=0).aSharp(0.4,0,0).aWarpsharp(3,1,bm=3,cm=0,thresh=0.99)
w==352 ?correctcolor(true):NOP
FFT3DFilter(plane=0,OH=16,OW=16,BH=48,BW=48,BT=3,Sigma=1,Sharpen=1).FFT3DFilter(plane=1,OH=16,OW=16,BH=48,BW=48,BT=3,Sigma=1,Sharpen=1).FFT3DFilter(plane=2,OH=16,OW=16,BH=48,BW=48,BT=3,Sigma=1,Sharpen=1).removedirt()
a=rightstr(aud,3)
b=rightstr(aud,10)
c=leftstr(b,4)
d=value(c)
e=d/1000
a=="ac3" ?audiodub(last,nicac3source(aud,2)).delayaudio(e):NOP
a=="mpa" ?audiodub(last,nicmpasource(aud)).delayaudio(e):NOP
return last

Using it with virtualdub 1.6.10 for both mpgs from vcds and dvd rips.
Best color correction tool for my use especially mpgs from vcds.Generally disable the fft3d line for DVD rips.
Thanx

[mg262]

As promised, screenshots (the middle column contains the original):

http://people.pwf.cam.ac.uk/mg262/posts/colour/SaturationGamma_12741.jpg

____________

Incidentally, every function in this filter should be compatible with @tsp's multithreading support in mode 1 (fastest mode). (But there's no point in multithreading the histogram writing functions as they do all their work at load time.)

[tranfa]

Is this plugin still available/usable?

[ChiDragon]

Huh? The links still work fine...

BTW, I want to thank you for bumping this up, I never knew about it before.

[tranfa]

Huh? The links still work fine...

BTW, I want to thank you for bumping this up, I never knew about it before.

...I get this message:

----------------------------------------------------
Forbidden
You don't have permission to access /mg262/posts/colour/ColourLike_230505.dll on this server.

--------------------------------------------------------------------------------

people.pwf.cam.ac.uk on PWF-HOME3

:confused:

[tranfa]

...I get this message:

----------------------------------------------------
Forbidden
You don't have permission to access /mg262/posts/colour/ColourLike_230505.dll on this server.

--------------------------------------------------------------------------------

people.pwf.cam.ac.uk on PWF-HOME3

:confused:


Unresolved also downloading from Firefox.

[Alain2]

Unresolved also downloading from Firefox.
Same for me :(
Forbidden
You don't have permission to access /mg262/posts/colour/ColourLike_25Aug05.dll on this server.

people.pwf.cam.ac.uk on PWF-HOME3

[Wilbert]

http://forum.doom9.org/showthread.php?t=118430

[tranfa]

http://forum.doom9.org/showthread.php?t=118430

Thank you Wilbert!!

[ChiDragon]

Oh weird, Save Target As saved the 403 error HTML as a .dll file. Thanks Wilbert. :)

[StainlessS]

Updated (some time ago) docs for Colorlike:


ColourLike: http://forum.doom9.org/showthread.php?t=96308

by mg262,

Search keywords: colour, color, ColorLike, curve, gamma, levels, channel.

Brief description: Makes a clip look like a 'reference' clip by adjusting each colour channel.

Full description:

YV12 and it now has RGB32 support.

It also has a polar-YUV mode, which as its 3 channels has
1) Y,
2) Length of the UV-vector (saturation)
3) Angle of the UV-vector. (hue)
Currently the angle is not changed by the filter (ie does not change hue).

Be careful to feed the filter with the right kind of histogram... YUV, RGB and Polar-YUV are three different kinds.


Functions:


WriteHistogram(clip,string outputfile, int "every"=1)
YV12, RGB32
Computes histograms for each channel of the clip and stores the results in outputFile.
If e.g. every=3 is specified, only every 3rd frame of clip is sampled.
# Returns original clip (No Constructor)


#CopyHistogram(string InputFilename, string OutputFilename)
# Copy a histogram ie make duplicate file.
# Not Implemented (Implememted in source but commented out)


WritePolarHistogram(clip,string outputfile, int "every"=1)
YV12 Only, Emits a "Requires RGB32" message if NOT YV12 ???
Computes polar histograms for each channel of the clip and stores the results in outputFile.
If e.g. every=3 is specified, only every 3rd frame of clip is sampled.
# Returns original clip (No Constructor)


CopyPolarHistogram(string InputFilename, string OutputFilename)
Copy a Polar histogram ie make duplicate file.
# Returns 0


WriteColourLikeCurve(string OutputFilename, string sourceHistogramFile, string referenceHistogramFile)
Writes YUV Equalising curves
# Returns 0


ColourLike(clip source,string sourceHistogramFile,string referenceHistogramFile, \
bool "affectfirst"=true, bool "affectsecond"=true,bool "affectthird"=true)
YV12, RGB32
Takes a clip source and histogram files for this clip and a reference clip, and applies curves to each channel
chosen, to make source look as much like the reference as possible.


PolarColourLike(clip source, string sourceHistogramFile,string referenceHistogramFile, \
bool "affectfirst"=true, bool "affectsecond"=true,bool "affectthird")
YV12 Only # RGB32, Not implemented for RGB32 depite error msg saying YV12 & RGB32 only
Takes a clip source and histogram files for this clip and a reference clip, and applies curves to the clip,
to make source look as much like the reference as possible.
affectfirst, affects Y channel
affectsecond, affects length of the UV-vector (ie SATURATION)
affectthird, if supplied is IGNORED, (angle of the UV-vector) (ie Does not change HUE)
The first true tells the filter to affect luma, and the second true tells it to affect saturation.


ApplyAMP(clip, string CurveFilename)
YV12, RGB32
Affects Y channel only for YV12


SaturationGamma(clip, float gamma, float "fixed"=127.0)
YV12
Affects U & V channels Only (applies gamma to length of the UV-vector [SAT])
Y channel untouched
I've also added a saturation gamma function. The idea is this. A normal gamma operation can brighten or darken
midtones while (approximately) leaving highlights and shadows alone. The saturation Gamma can increase or decrease
the saturation of areas with medium saturation, while leaving greys and very saturated areas alone.
The fixed parameter gives a "very saturated" saturation level [measured as a distance from (128,128)] that will
be left alone by the function... but it will work fine if you leave this number at default.
The results are (in my view) quite interesting, so do give it a go!


----------------

Examples:

Here are some examples from a case where the same clip is present in (unrelated) DVD and VHS sources.

First generate the histograms:

dvd.WriteHistogram("dvd hist 100.txt", 100)
vhs.WriteHistogram("vhs hist 100.txt", 100)

Then, say, adjust the VHS to look as much like the DVD as possible:
vhs.colourlike("vhs hist.txt", "dvd hist.txt")
or
vhs.colourlike("vhs hist.txt", "dvd hist.txt", true, false, false)
which means: just process Y (respectively R) but ignore U and V (respectively G and B).

Or adjust the DVD to look as much like the VHS as possible
dvd.colourlike("dvd hist.txt", "vhs hist.txt")

Polar:
dvd
WritePolarHistogram("dvd polar hist 1.txt", 1)
vhs
WritePolarHistogram("vhs polar hist 1.txt", 1)

dvd.polarcolourlike("dvd polar hist 1.txt", "vhs polar hist 1.txt", true, true, true) #last 'true' is ignored

The first true tells the filter to affect luma, and the second true tells it to affect saturation.
This should in theory change the brightness, contrast, saturation, etc but not affect hue.
I haven't found this to be very useful in practice.
I think a variant which changed hue would be more useful, but this is ill-defined... or more precisely,
because hue is represented by a circle rather than a line, there is a whole family of 'hue-equalising' filters...

------------------------------------------------------------------------------------------------
Notes:
Generating histograms runs at about 75fps on DVD source on my PC (and I think most of that time is MPEG decoding), but
this still seems slow because the entire file needs to be scanned. As in the example, you can specify quite a large
value of 'every' without affecting the results too much.

You only need to generate the histograms once, so you probably want the WriteHistogram calls in a separate AVS to
ColourLike.

This filter can be used on completely unrelated clips (which I haven't tried yet); I don't actually think that is a
particularly meaningful thing to do, so I'm pretty pessimistic about the results -- but if you do happen to try it,
see what the results look like when you just use it on the Y channel, and also when you just use it on the U&V channels.
(Use MergeLuma or MergeChroma with source and the output of this filter.)

For the record, I'm not terribly happy with the results of the filter overall -- as I noted in that other thread, I
think there is 'crosstalk' between the colour channels that this process does not account for. So I think a proper colour
matching function will have to use something more sophisticated than channel-curves.

The 'other thread' mentioned is here:
http://forum.doom9.org/showthread.php?t=95574

------------------------------------------------------------------------------------------------------------------------
Above text, mostly words of author mg262, but edited from various posts on doom9 and had some text inserted to either
clarify or denote usage.

Edited by StainlessS, on doom9


Last available source/dll via Wilberts link above:
http://forum.doom9.org/showthread.php?t=118430

[pila13]

hello, i need help with this plugin, i try to move color setting form original source what in NTSC, in a LQ PAL, i found wathi filter, and at first i thoguht it's working, but.... I just notice this -

http://i46.fastpic.ru/big/2013/0602/1c/ef7d85fcfcdf4808c1ae9c6442860d1c.png

And i have no idead how do i fix this ><;, i hope some one can help me, or propose different filter, what do same job what colorlike, but don't have this problems... thank you ~

[StainlessS]

Pila13,

You have only just posted your problem, be patient, there is no need whatever to PM me on the matter.
I dont claim to be any expert on ColorLike, I only gathered together the documentation (quite some time ago).
There are probably people who could give better advise on this.

EDIT: You might also want to consider creating your own thread in the Avisynth Usage section of the forum.

[pila13]

Well, it's pretty much dead thread.

I reduce % of bad pixels, with "polar" version, but still they present. And how fix this i don't know.

[StainlessS]

Here, re-compile of ColorLike 25 Aug 05, compiled with Avisynth.h Version 3 (current for v2.58, was 2).
Fixed a few 'variable redefinition' errors (Microsoft complier issue with older code, legal in most compilers).

Original and current source in zip.

http://www.mediafire.com/download/m7d75o1497mx5f3/ColorLike_25Aug05-Avisynth-H_Ver3.zip

[JoyBell]

StainlessS
I am wanting to implement this in Stax, it looks like the WriteHistogram part would have to be done in a Stax Script and then then ColorLike as a filter in the normal stax encode. Yes, my example is about color correcting HDR vs SDR and I have Hable conversion working, just the tint adjustments are always lacking on the output. Never quite right. I also think the script will be used in other cases.

hdr.WriteHistogram("hdr hist 100.txt", 100)
sdr.WriteHistogram("sdr hist 100.txt", 100)

sdr.colorlike("sdr hist 100", "hdr hist 100")

[StainlessS]

Joybell,
mg262 said something like "I am very disappointed with this filter" (In this thread maybe), dont know if its worth bothering with,
I only re-compiled it (fixing a few compiler errors/warnings), main reason was to make some kind of doc for it (as mg262 used to leave it
to every individual user to figure out how to use it by reading the thread.

See here:- https://forum.doom9.org/showthread.php?t=118430
And here:- https://forum.doom9.org/showthread.php?p=1576378#post1576378
From 2nd link
Some years later, lines in text preceded by hash '#' are not quite true, ie may have been written by mg262, but not implemented in source as documented (eg CopyHistogram is I think not implemented at all [edit: think may be implemented but totally commented out, again not sure, not checked], could be wrong. Many of the functions claim to return 0, if I remember correctly, a lot of them return nothing at all, ie void).

EDIT: And appending the doc thing to which above quote refers,

ColourLike: http://forum.doom9.org/showthread.php?t=96308

by mg262,

Search keywords: colour, color, ColorLike, curve, gamma, levels, channel.


Brief description: Makes a clip look like a 'reference' clip by adjusting each colour channel.

Full description:

YV12 and it now has RGB32 support.

It also has a polar-YUV mode, which as its 3 channels has
1) Y,
2) Length of the UV-vector (saturation)
3) Angle of the UV-vector. (hue)
Currently the angle is not changed by the filter (ie does not change hue).

Be careful to feed the filter with the right kind of histogram... YUV, RGB and Polar-YUV are three different kinds.


Functions:


WriteHistogram(clip,string outputfile, int "every"=1)
YV12, RGB32
Computes histograms for each channel of the clip and stores the results in outputFile.
If e.g. every=3 is specified, only every 3rd frame of clip is sampled.
# Returns original clip (No Constructor) # EDIT: 20 Jan 2020, Is not a filter, is ordinary function which scans every frame and returns original clip on completion


#CopyHistogram(string InputFilename, string OutputFilename)
# Copy a histogram ie make duplicate file.
# Not Implemented (Implememted in source but commented out)


WritePolarHistogram(clip,string outputfile, int "every"=1)
YV12 Only, Emits a "Requires RGB32" message if NOT YV12 ???
Computes polar histograms for each channel of the clip and stores the results in outputFile.
If e.g. every=3 is specified, only every 3rd frame of clip is sampled.
# Returns original clip (No Constructor)


CopyPolarHistogram(string InputFilename, string OutputFilename)
Copy a Polar histogram ie make duplicate file.
# Returns 0


WriteColourLikeCurve(string OutputFilename, string sourceHistogramFile, string referenceHistogramFile)
Writes YUV Equalising curves
# Returns 0


ColourLike(clip source,string sourceHistogramFile,string referenceHistogramFile, \
bool "affectfirst"=true, bool "affectsecond"=true,bool "affectthird"=true)
YV12, RGB32
Takes a clip source and histogram files for this clip and a reference clip, and applies curves to each channel
chosen, to make source look as much like the reference as possible.


PolarColourLike(clip source, string sourceHistogramFile,string referenceHistogramFile, \
bool "affectfirst"=true, bool "affectsecond"=true,bool "affectthird")
YV12 Only # RGB32, Not implemented for RGB32 depite error msg saying YV12 & RGB32 only
Takes a clip source and histogram files for this clip and a reference clip, and applies curves to the clip,
to make source look as much like the reference as possible.
affectfirst, affects Y channel
affectsecond, affects length of the UV-vector (ie SATURATION)
affectthird, if supplied is IGNORED, (angle of the UV-vector) (ie Does not change HUE)
The first true tells the filter to affect luma, and the second true tells it to affect saturation.


ApplyAMP(clip, string CurveFilename)
YV12, RGB32
Affects Y channel only for YV12


SaturationGamma(clip, float gamma, float "fixed"=127.0)
YV12
Affects U & V channels Only (applies gamma to length of the UV-vector [SAT])
Y channel untouched
I've also added a saturation gamma function. The idea is this. A normal gamma operation can brighten or darken
midtones while (approximately) leaving highlights and shadows alone. The saturation Gamma can increase or decrease
the saturation of areas with medium saturation, while leaving greys and very saturated areas alone.
The fixed parameter gives a "very saturated" saturation level [measured as a distance from (128,128)] that will
be left alone by the function... but it will work fine if you leave this number at default.
The results are (in my view) quite interesting, so do give it a go!


----------------

Examples:

Here are some examples from a case where the same clip is present in (unrelated) DVD and VHS sources.

First generate the histograms:

dvd.WriteHistogram("dvd hist 100.txt", 100)
vhs.WriteHistogram("vhs hist 100.txt", 100)

Then, say, adjust the VHS to look as much like the DVD as possible:
vhs.colourlike("vhs hist.txt", "dvd hist.txt")
or
vhs.colourlike("vhs hist.txt", "dvd hist.txt", true, false, false)
which means: just process Y (respectively R) but ignore U and V (respectively G and B).

Or adjust the DVD to look as much like the VHS as possible
dvd.colourlike("dvd hist.txt", "vhs hist.txt")

Polar:
dvd
WritePolarHistogram("dvd polar hist 1.txt", 1)
vhs
WritePolarHistogram("vhs polar hist 1.txt", 1)

dvd.polarcolourlike("dvd polar hist 1.txt", "vhs polar hist 1.txt", true, true, true) #last 'true' is ignored

The first true tells the filter to affect luma, and the second true tells it to affect saturation.
This should in theory change the brightness, contrast, saturation, etc but not affect hue.
I haven't found this to be very useful in practice.
I think a variant which changed hue would be more useful, but this is ill-defined... or more precisely,
because hue is represented by a circle rather than a line, there is a whole family of 'hue-equalising' filters...

------------------------------------------------------------------------------------------------
Notes:
Generating histograms runs at about 75fps on DVD source on my PC (and I think most of that time is MPEG decoding), but
this still seems slow because the entire file needs to be scanned. As in the example, you can specify quite a large
value of 'every' without affecting the results too much.

You only need to generate the histograms once, so you probably want the WriteHistogram calls in a separate AVS to
ColourLike.

This filter can be used on completely unrelated clips (which I haven't tried yet); I don't actually think that is a
particularly meaningful thing to do, so I'm pretty pessimistic about the results -- but if you do happen to try it,
see what the results look like when you just use it on the Y channel, and also when you just use it on the U&V channels.
(Use MergeLuma or MergeChroma with source and the output of this filter.)

For the record, I'm not terribly happy with the results of the filter overall -- as I noted in that other thread, I
think there is 'crosstalk' between the colour channels that this process does not account for. So I think a proper colour
matching function will have to use something more sophisticated than channel-curves.

The 'other thread' mentioned is here:
http://forum.doom9.org/showthread.php?t=95574

------------------------------------------------------------------------------------------------------------------------
Above text, mostly words of author mg262, but edited from various posts on doom9 and had some text inserted to either
clarify or denote usage.

Edited by StainlessS, on doom9


I myself dont use it at all [EDIT: basically, its a bit of a mess].

EDIT: This was the original documentation provided with the filter,

description:

http://forum.doom9.org/showthread.php?t=96308

discussion:

http://forum.doom9.org/showthread.php?t=96308

Version:

- Initial release, v1.0


EDIT: Think maybe this is the quote in the assembled doc that I referred to when I rough quoted "I am very disappointed with this filter",
For the record, I'm not terribly happy with the results of the filter overall

CopyHistogram code from cpp, [all commented out]

//
//
//AVSValue __cdecl CopyHistogram(AVSValue args, void *user_data, IScriptEnvironment *env)
//{
// ifstream input(args[0].AsString());++i // EDIT: what is this, "++i"
// ofstream output(args[1].AsString());
// YUVHistogram histogram;
// input >> histogram;
// output << histogram;
// return 0;
//}


from AvisynthPluginInit2

//env->AddFunction("CopyHistogram", "ss", CopyHistogram, 0);

[datphyr]

I'm working on some movie regrade project to match colors of new 4K release to colors of old preremaster release and I found this plugin extremely useful.
At start I got not wonderful results, so I started to dig.
Since I was loosing loads of data on 8bit conversion I started to look for some tricks to increase my accuracy.
I end up averaging results of RGB and YUV matches (and doing this 2 times for 100 and 101 nits tonemaps, so 4 clips total).
I got some 'reddish' of blacks cause of YUV match, so I tried to 'retonemap' it with libplacebo's spline method to HDR and back to SDR at 100 nits.
This moved blackpoint and 'reddish' of blacks disappeared.
So I give it a shot for my preremaster histograms source.
Resulting histograms was MUCH better to match to.
Colors are instantly way closer to original.
My guess it's because colors in retonemapped clip are way more uniform in distribution shadows and highlights.

The only thing bothers me - low precision. Any chance it will work for HBD ?

Also I viewed data in histogram files as graphs and sometimes it's 'noisy', like 'saw' around dark colors (footage dependant).
So I tried to smoothen them with some python scripts and this helped. Denoising footage also helps.

[DTL]

For HBD you need to add 16bit processing (or at least 10bit).

The loops like
for(i = 0; i < 256; ++i)
for(j = 0; j < 256; ++j)
total += v[i][j];
With 256x256=65536 runs of inner operation will be
65536x65536=4.2e9 runs - about 65 000 times slower for 16bit.

[datphyr]

This is for WriteHistogram calls?

What about linearly interpolating existing 8bit histograms to 16bit and then applying them in 16bit space? Can it make a trick?
I made a python script to interpolate them and output is 3-4mb each but that's pretty much all I can do :( Don't have any C++ knowledge.

[DTL]

Yes - interpolation is much faster. C language is also simple and enough. C++ part is only required for plugin connection to AVS environment and it already working.

[datphyr]

I found a workaround - apply ColourLike to LUT HALT file, create a .cube and apply it using DGCube().

[LunaRabbit]

I found a workaround - apply ColourLike to LUT HALT file, create a .cube and apply it using DGCube().

Did you ever find a way to work with 16-bit color space with this filter directly? What is your work flow like? I'm assuming you're using Adobe Premiere, correct?

Is it something like; Write histogram from 8-bit color source in avisynth -> load other source in Adobe Premiere -> create LUT -> apply colourlike histogram to LUT -> export .cube -> load 2nd source in avisynth+convert to 16-bit -> apply .cube using DGCube()

Excuse me. I'm not very familiar with Premiere.

How are the results you're getting with this work around? Can you post any examples of sources you've color corrected using this? What kind of filtering are you applying to these sources before and after exporting/importing the histrogram?

I have a source right now that's really awful. The only source of correct color I have is starved for bitrate and there were several changes between when it was created and when the better source with bad colors was made. So several sections have things like credits overlaid in different portions of the screen or other minor changes were made to correct production errors in the original. Of course this means those frames look awful if you just do a chroma merge. So I've been looking for a way to correct those areas.

Is there a comparable Vapoursynth filter that supports 16-bit colors?

Thanks for your attention.