Color Correcting the Dragon Box - 3 Part Spectacular

[Gonstead]

You should get into contact with Funimation about using these color corrections for the Blu-Ray release. This would be the cost-saving measure that Funimation were searching for.

Dub and Japanese tracks synched perfectly? Even better since all Funimation would need to do then would be to scan the footage into 1080 HD and burn them onto the Blu-Ray disks themselves.

[MarcFBR]

You should get into contact with Funimation about using these color corrections for the Blu-Ray release. This would be the cost-saving measure that Funimation were searching for.

Dub and Japanese tracks synched perfectly? Even better since all Funimation would need to do then would be to scan the footage into 1080 HD and burn them onto the Blu-Ray disks themselves.

That shows a heavy misunderstanding of the situation as we know it to be.

Sending these to Funimation would not equate to getting us the Blu-rays.

[kei17]

You should get into contact with Funimation about using these color corrections for the Blu-Ray release.

I'm pretty sure that'd be preaching to the choir.

[Gonstead]

*shrugs* No harm in trying. Was merely just a suggestion.

[xekon]

I love this! I have been reading about ways to do this without the conversion to rgb.

I have also read that you only suffer a noticeable quality loss if you convert back and forth many times, and that just once to rgb and back to yv12 shouldnt suffer much quality loss.

I have found one way of doing it so far.
I used the Gradation Curves Filter: http://members.chello.at/~nagiller/vdub/
to load yv12 into vdub without converttorgb I used Helix codecs: http://forum.doom9.org/showthread.php?t=56972

index your .vob with dgindex and make an .avs file:

Code: Select all

LoadPlugin("F:\AviSynth\plugins\DGDecode.dll")
MPEG2Source("F:\AviSynth\Trunks.d2v")

load the .avs, and open the gradation curves filter in vdub:


with that small adjustment I got this:


Then once you have your curve you can save it into a .amp file and load it with GiCoCu in AviSynth for your final encode.
http://avisynth.org.ru/docs/english/ext ... gicocu.htm
I have read that GiCoCu works with yv12, but the documentation lists rgb, so I am still looking into it.
edit, no look, I am continuing to read for alternatives


Now for my problem. I LOVE how in the guide on the first post, you are targeting the eyes and adjusting back to a grey balance. I am not sure how you would do that using gradation curves/GiCoCu
All I did here was adjust the curve a few times and look at the result, it was total guess work. Anyone have any ideas?

[ect5150]

Now for my problem. I LOVE how in the guide on the first post, you are targeting the eyes and adjusting back to a grey balance. I am not sure how you would do that using gradation curves/GiCoCu
All I did here was adjust the curve a few times and look at the result, it was total guess work. Anyone have any ideas?

AVISynth will convert for you with something like ConvertToRGB32() or ConvertToRGB24()... whatever the need is. And likewise using something like ConvertToYV12() if you need to go back. Put that line before GiCoCu to have it feed it the RGB32 bit video stream it needs.

As far as targeting the eyes, if there is too much blue/red/green, the gradation curves are adding in the other colors that are missing to make it white - affecting the whole picture (in a positive fashion 99% of the time it seems).

I've not seen GiCoCu, I'll have to see if we can add anything additional using some additional Photoshop settings - nice find on that for us to play around with.

[xekon]

I was hoping to get through the entire color correcting process without converting to rgb, but I am still reading more threads because there might be something else I missed.

here is a thread I just started, for an idea I came up with, for those that are familiar with avisynth: http://forum.doom9.org/showthread.php?t=167027 (not a complete idea, its a works in progress, but using colorYUV would prevent the need to convert to rgb.)

[ect5150]

Just for everyone's knowledge with AVISynth, I found this little blurb in the documentation---

Conversion back and forth is not lossless, so use as few conversions as possible. If multiple conversions are necessary, use ConvertBackToYUY2() to convert back to YUY2, when you applied a YUY2->RGB conversion prior to that in your script. This will reduce color-blurring, but there are still some precision lost

[xekon]

It also depends on what the original colorspace was. My R2 dragonboxes are originally YV12, so this is what I have been using to convert back: ConvertToYV12()
but that is what I have read about converting as well, is that you do lose some information.
However I have also read that it is much easier and reliable to do color corrections in RGB, so the small loss in precision is justified.

[xekon]

I wrote a small autoit script to speed up the process of using Ashura's color cast removal guide.

here is a youtube link of it in action: http://youtu.be/tjEjxamglS4

You follow the guide as outlined by Ashura, the only difference is you use ruler guides in photoshop to box in a section of white.

then when you get to the step in Ashura's guide where you check all of those pixels for the one with the highest R, G, or B value, instead you just press "F1" and my script automatically compares the RGB values of the pixels within the guides and automatically selects the one with the highest value and then applies it.

I actually was a little curious about something, because I do not have a background in color theory.
My script will find the pixel with the highest value in either R,G, or B.
I was wondering if it would be even more accurate to get the highest value, and then look at the second highest value.

Lets say my script finds the highest value pixel out of a block of pixels and it has a 0-255 value of 249

Well suppose there are 10 different pixels that all have a value of 249? obviously we cant pick them all since they are all at 249.
should I start looking at secondary values? or perhaps an average of the two extra values?
like take all the pixels with a value of 249 and then average the remaining two values(if the highest is R at 249 then average G & B) and pick the 249 pixel with the highest secondary value or average of values.

Anyway I hope others find this useful, I know it sure is saving me a lot of time.
Also I wrote it so that it should work on any system, but there is a small chance it could have an issue if photoshop displays the guides as a different color on your system, also a multi monitor setup could possibly be a problem. I have only tested it on my system.

There is an exe for those that dont have autoit instaled, but I also included the source .au3 files for those that have autoit installed and would rather run it as a script or compile it themselves.
http://www.mediafire.com/?t178xr2jopbe6oy

EDIT: Also if you zoom in photoshop to set your guides, after you set your guides set the zoom back to 100% (before pressing "F1"), the script will work better/faster this way.

[ect5150]

Lets say my script finds the highest value pixel out of a block of pixels and it has a 0-255 value of 249

Well suppose there are 10 different pixels that all have a value of 249? obviously we cant pick them all since they are all at 249.
should I start looking at secondary values? or perhaps an average of the two extra values?
like take all the pixels with a value of 249 and then average the remaining two values(if the highest is R at 249 then average G & B) and pick the 249 pixel with the highest secondary value or average of values.

Excellent work and excellent question.

I'll have to try out the script later this weekend.

As to the question, if you have 10 pixels all with a high value of 249 (lets just say in the red channel). The difference would then lie in what the other channels were, correct? Say 3 of the pixels had a green at 215, another 3 pixels at 224 and another 4 pixels at 239. The how much we increase the green channel would depend on which of those initial 10 pixels we selected. With the 1st three, we would increase the green channel by 34, but the last 4 pixels, the increase is only by 10. I think it makes more sense to take a weighted average of the secondary values (green values in my example). So, the red is at 249... but we'll arrive at a green average of 227.3 ( 227.3 = (3*215 + 3*224 + 4*239)/10 )... therefore we increase the green by 21.7 (or just round to 22). I think the same thing should be applied then to the blue channel as well.

(Other thoughts, the more and more I think this through, the more and more I think the average of the greens, should be brought up to the average of the reds -- and likewise the average of the blues should be brought up to the average of the reds --- assuming the average of the reds is highest within the block of pixels selected... some variation of a grainy source would be expected).

Now that I re-read your post, it may appear as if you mean something slightly different. Looking again at your logic, if you were to average the G+B values, you should select the pixel that is closet to the average, not the highest. The selection of the highest would be selecting the pixel furthest away from the values representing the group as a whole (essentially picking the outlier, correct?). I think that might over-correct/under-correct the colors.

I don't know if you can apply my logic above to your script, but maybe I'll look into your script later in the week and see if I can code any of it myself (right now work is taking up too much of my time). Either way, the ultimate way to do this is to try a few different versions and look at the results... potentially measure them (if we can easily do it) and see if we obtain - on average - a white block of pixels. Then present the results to the forums and show screen shots and get feedback. There are some people that have a good eye for color issues on here and others have better/worse monitors, etc...

-----------------------------------------
EDIT: After investigating Autoit (which looks to be very useful) -- I wonder if it ultimately wouldn't be easier to use this It might be fun to try and might make part of the process easier to anyone that wants to use it.
-----------------------------------------

[xekon]

A native photoshop plugin would without a doubt be better. you would have direct access to controls instead of using coordinates and it would be faster too.

I actually looked into exactly what you are thinking. I have never created a photoshop plugin before, so it would have taken more time.

I am familiar with autoit so I was able to whip that script up in less than an hour. If this is a good way to do color corrections and I like the results then I will probably create a photoshop plugin to do the same thing.

So far however I am getting inconsistent results. On some frames the results are excellent, but if I use a different frame to create the curve I get a yellowish green tint still on whites/greys. I think it has to do with looking for only the highest value pixel (lets say 249 in the red channel) and not looking at the other two color channels. B/G

I was discussing something similar at doom9 and it was suggested that using an RGB parade would be a better way of correcting the color cast.

I think both ways could work, but my script needs to be doing something different to take into account the values of all three color channels.

Also if you look at the histogram after applying the curve for the color cast removal, notice there are some gaps in the two color channels that were adjusted, that didn't seem correct to me, that means there is a complete loss of color information for that color channel in that tone. (If you didn't know, a histogram shows darks on the left and brights on the right, with midtones inbetween, and the height is the amount of information at that tone.)

[ect5150]

I was discussing something similar at doom9 and it was suggested that using an RGB parade would be a better way of correcting the color cast.

I trust those guys, but what the hell is an RGB parade? (apparently I'll have some reading to do this week) EDIT: Those guys didn't do much for my trust there...

I also agree about not taking into account all color values, because the color of the caste might vary from episode to episode.

SUPER EDIT:

So, while Googling for more info I ran across this (http://forum.doom9.org/showthread.php?p ... ost1612676) --

I think that guy is making a few mistakes - especially claiming we are making blind guesses when we have explicitly stated that we are targeting areas of the image that are known to be white. (he also doesn't seem to know the different between the DVD's, Kai Sets or FUNI BluRays... and I'll give him slack here. Most probably don't know the difference unless you are a hardcore DBZ fan -- he seems to think all 4 versions are the same from the link to the video he provided.

I will say that his ultimate suggestion is what I proposed as well (lining up that RGB parade vertically). That means making the means of each channel equal to each other (which is what I said a few posts up above).

Also, I'll note something else that fellow did I've been thinking about we should address. To obtain white, so far we have been bringing the lower two channels up to match the third. Why not reverse it and take the higher two and lower them to the lowest (so instead of having R=245, G=210, B=204... and making that R=245, G=245, B=245... we could make it R=204, G=204, B=204). We achieve the same effect, except for the fact that we are altering the luminosity. In his screen shots, he is lowering the luminosity... our guide actually increases it. I use the increased luminosity since I use the R2 Dboxes, and it is known they roughly 10% less in brightness. Or should we target the same luminosity (target an average value between the 3 sampled which is probably a better approach).

Either way, I'll start fooling around the photoshop scripting soon -- but given my PC situation currently, I wouldn't have anything up and running soon I would imagine (unless I can get work to install Photoshop on my office PC and work on this during some breaks -- which is a possibility)

[xekon]

well I have done a bit more experimenting.

After reading this: http://www.larryjordan.biz/ppro6-fast-color-correction/

this paragraph in particular:

NOTE: Her black vest is also gray (the color), but when it comes to color correction, we have the greatest latitude when we correct mid-tone (50%) gray values, rather than shades very close to white, or very close to black. And, never try to color correct over-exposed sections of the frame or speculars – these are very unreliable for use in color correction.

so selecting the pixel with the highest value in R,G, or B is the pixel closest to white... according the above paragraph I think the pixel that has r,g,b values close to the average of all pixels in an area that should be white, would be best. I will keep experimenting, and reading.

I am hoping to adjust my script so that it more or less always produces accurate results. sometimes I pick the pixel with the highest value and still end up with a curve that does not remove the color cast completely.

[ect5150]

so selecting the pixel with the highest value in R,G, or B is the pixel closest to white... according the above paragraph I think the pixel that has r,g,b values close to the average of all pixels in an area that should be white, would be best. I will keep experimenting, and reading.

I'll have to read the link you posted later, but in general I agree with the logic there. Assuming the block of pixels to select from is large enough, the idea would be to pick a pixel that best represents all pixels from that block. Picking the one that is closest to the average would be best. If you can implement that in your script and post some DBox before and after shots, that would be great (I won't get a chance to work on this until the weekend at the earliest).

That still leaves the issue brought up by one of your previous posts. After this is done, does that mean the RGB parade then lines up for that block of pixels (horizontally speaking)? I'm referring to the sample you did that zoomed in on just the white section of pixels.

EDIT: I'm referring to this--



The end result still needs that to line up as perfectly as we can get it. To be honest, I prefer a measurement approach if we are scripting the stuff, not a visual approach and saying "yeah, it looks close enough."

[xekon]

Yeah, I plan to modify the script to try an average pixel approach. I modified it yesterday so that it would work with CS6 in addition to CS5. (colorpicker has different dimensions, and window title)

[ect5150]

Yeah, I plan to modify the script to try an average pixel approach. I modified it yesterday so that it would work with CS6 in addition to CS5. (colorpicker has different dimensions, and window title)

Does that autoit depend on window size of the aplication and therefore desktop resolution too?

[xekon]

It depends on how your write it, but the overall answer is yes.

instead of using absolute coordinates, I tried to use relative coordinates which should make it work on most systems.

IE:
$middlescreenw = @DesktopWidth/2
$middlescreenh = @DesktopHeight/2

and finding target windows position and using an offset of that for a controls position:

$size = WinGetPos("Color Picker (Target Highlight Color)");cs6

MouseClick("left",($size[0]+372),($size[1]+253),2)
MouseClick("left",($size[0]+372),($size[1]+277),2)
MouseClick("left",($size[0]+372),($size[1]+301),2)

so above i get the position of the color picker window, and the click into the R,G,B text fields using an offset of that windows position.

I think I am just about finished with the new script that targets the average pixel, then I will have to do some testing to see if it gives more reliable/consistent results. Once I do a little testing I will post it.

[ect5150]

I think I am just about finished with the new script that targets the average pixel, then I will have to do some testing to see if it gives more reliable/consistent results. Once I do a little testing I will post it.

cool, if we. Get overall results desired, ill see if I can make the code into an Adobe plugin ( if I can pull it off, I've never tried it)

[xekon]

yes, I was planning to do the same. My idea was to use a square selector type tool instead of guides and then have it do the calculations on the pixels within the selection.

If you wanted to get really fancy you could have several options for the selector type tool, square, circle, and something like the Polygonal lasso tool. This would allow you to include more pixels into the averaging, since you wouldn't be constrained by the square shape.

If I get consistent results after trying this I will be very happy. If not I will probably look into different methods of removing the color cast.
You are more than welcome to take a crack at making the Photoshop plugin first, because I actually have a lot of projects going on for quite a while. (don't have the time to setup the work environment and familiarize myself with their API)