Brightness and/or Gamma difference calculation

[qyot27]

I ran into this after a scare concerning the North American Blu-ray release of K-ON!! The actual scare ended up being for naught, since I pretty much whittled it down to my TV's noise reduction settings somehow having gone out of whack, but in trying to find an answer for it I stumbled upon this blog post:
http://konfan.blogspot.com/2012/06/k-on-season-2-blu-ray-us-vs-jp-review.html

Toward the bottom, it compares the quality of the Japanese and North American discs (and seeing it there is what reassured me that there wasn't some horrible Warpsharping that'd been done to it). The screenshots illustrate that the North American release is brighter, for instance in this example:
http://img546.imageshack.us/img546/6882/jpscreen05.png
http://img225.imageshack.us/img225/9672/usscreen05.png



So hypothetically, if one wanted to adjust the brightness back down to match what you find in the screenshot from the Japanese release, how would you go about calculating the difference, and is there any specially-targeted filter for AviSynth that can do this or is it just using the Levels or Tweak filter and plugging in the right adjustment values (which goes back to somehow calculating the difference)?

It's not that I can't just play it by eye when messing with those filters, but I'd prefer being able to do it a bit more programmatically.

[Mounir]

yes ylevels can (work on luma only) ex: ylevels(0,1.000,255,0,255)

Try(0,0.850,255,0,255) but i haven't checked

more infos:
http://avisynth.org/mediawiki/Ylevels

[qyot27]

yes ylevels can (work on luma only) ex: ylevels(0,1.000,255,0,255)

Try(0,0.850,255,0,255) but i haven't checked

more infos:
http://avisynth.org/mediawiki/Ylevels
0.900 actually comes a lot closer than 0.850, but that doesn't answer the question I was really asking.

Is there a tool that could take those two example screenshots, compute the difference between them, plot them on a scale between true black and true white (or whatever makes sense in the context of the luma or chroma), and then return either the plot results or the subtracted value between the two clips' plot positions?

In limited tests, it appears that Histogram() can kind of get there: it can display a plot, and what I'm hoping to do is calculate the value by which clip B (the US screenshot) was moved and/or compressed in comparison to clip A (the Japanese screenshot). See below.

The histogram for the original:
http://imageshack.us/a/img43/6815/jphist.png

For the US:
http://imageshack.us/a/img203/8248/ushist.png




While I found that 0.900 gets really really close to the original level of brightness (and the resultant histogram also looks very similar to the original, albeit obviously not exact), my point was that I wanted to be able to get a figure without having to assess the filtered results visually, at least not at first. A method that can be applied to any arbitrary video where I have comparison screenshots. Doing it this way also potentially means more fine-grained values that are more absolute instead of rounded ones that are easier for ballpark estimates (and human error).

[StainlessS]

ColorLike() might be worth a look
http://forum.doom9.org/showthread.php?t=96308&highlight=colorlike

[Didée]

An exact match is somewhat unlikely anyway. You don't know the processing chain in which the difference was caused. If the difference stems from a processing chain in RGB or HSV, then you can do YUV-processing 'til you get blue in the face, but the matching will never be exact.

[qyot27]

ColorLike() might be worth a look
http://forum.doom9.org/showthread.php?t=96308&highlight=colorlike
It does seem to match what I'm looking for, but my attempts at getting it to write a histogram file are resulting in "Avisynth: stack overflow" errors. Maybe because I'm using 2.6? I tried with both the 25Aug05 build and neuron2's build.

An exact match is somewhat unlikely anyway. You don't know the processing chain in which the difference was caused. If the difference stems from a processing chain in RGB or HSV, then you can do YUV-processing 'til you get blue in the face, but the matching will never be exact.
I was afraid it might come down to something like this in how any prior processing might've messed with it. I'm comfortable with sacrificing exactness so long as it can get reasonably close, though.




Now, whether what I describe is at all close to a 'proper' way of doing this, I don't know. But taking those histograms I posted earlier, I took the position of one of the features in the original - the long line - close to the center, and got its x pixel value (it makes it nice that Histogram() outputs a chart that's 256 pixels wide), and since the position of that same feature in the US screenshot is almost dead-center, I just divided the original's position by 128 to get the value of its percentage from center. 0.90625. As I mentioned earlier, turning the US screenshot's value down to 0.900 got it really really close to the original, so that process seems to make sense in how to go about ascertaining a value to shoot for when doing a correction like this.

[zee944]

I know exactly what do you want. That's what I wanted a few years back :)

For the closest match, you should apply a customized luma curve (an .amp file) to your video with GiCoCu(). The problematic part is to find out how the optimal luma curve should look like. You'd have to do pixel to pixel comparsion of the frames for that. Which of course never works, because the geometry never matches. You'd have to this smartly, with threshhold, throwing away the statistically extreme values, averaging etc. I don't know any plugin which can do that. A simpler way is to calculate out by comparing histograms, which is less accurate, but might work, and there's a HistogramAdjust plugin for that too - I've never used it.

You should read this:
http://forum.doom9.org/showthread.php?t=153196

The easiest way is to measure the average luma of both frames (with the runtime functions like LumaDifference, AverageLuma etc.) and tweak the video accordingly, but it's way simpler than what you wanted. However, your two sources seem quite close to each other, like they have a close common print they were both originated from. If a simple Tweak() or Levels() gives you a 95% match and it is consistent throughout the whole video, it really doesn't worth to think about the more complicated methods. They're imperfect too, because of what Didée was saying: you can't reverse the result of a processing chain in one step. And if you'd be willing to do more steps, you don't know what they were...