Star Wars GOUT in HD using super resolution algorithm (* unfinished project *) — Page 47

Thanks! :-)

Here's SRV15, a huge improvement:

Just kidding, this is the bluray adjusted to match the GOUT colors. 

Wow, that is really impressive. Looks very natural.

I have not watched the Blu Ray set, but I assume the consensus was that the colors were over saturated? Or what was the problem regarding the set color wise?

Thanks! Building a color matching model takes quite a long time. About 10 min on my Intel Core i5 laptop. So, if you want to match each frame to a reference, it would take forever. However, if you use 1 reference, and correct between 20-50 frames with this model, it takes 10 min to make the model, and then 5-20 sec for correcting each frame, depending on the resolution. It's about 10 sec for a 1080p frame. On the 3.5GHz 4 core it will probably be a lot faster, especially if you can use parallel computing. 

It would be really great if we could do this with distributed computing power. This matching method really seems like the way forward. Having the whole blu-ray matched to both the GOUT and the IB prints would just be incredibly useful for many projects. 

Zyrother said:

Wow, that is really impressive. Looks very natural.

I have not watched the Blu Ray set, but I assume the consensus was that the colors were over saturated? Or what was the problem regarding the set color wise?

The bluray colors are truly awful. You can see some screenshots in my color matching thread. 

Harmy said:

I know very little about this stuff but would it be possible to connect it to some cut detecting algorithm, so that it references one frame in each shot (or by setting the cut detection to much lower sensitivity possibly just each scene) and then apply that to the corresponding shot/scene in the file you want to correct?

I've made a user interface, that makes it very easy to select, crop frames, and subsequently build a model. You can then select any number of frames, that will be color corrected and saved in a separate directory.

DrDre said:

Here's SRV15, a huge improvement:

 For a second there you had me!  I was like "NO WAY!" and analyzing it and started to think it couldn't be real and then I saw your comment below the pictures.  Good one!

I want to compile the GUI, such that it can be used as a standalone application.

Zyrother said:

Wow, that is really impressive. Looks very natural.

I have not watched the Blu Ray set, but I assume the consensus was that the colors were over saturated? Or what was the problem regarding the set color wise?

 If you've ever watched the the 2004 DVD, it's roughly the same color wise.

camroncamera said:

DrDre said:

Thanks! Building a color matching model takes quite a long time. About 10 min on my Intel Core i5 laptop. So, if you want to match each frame to a reference, it would take forever. However, if you use 1 reference, and correct between 20-50 frames with this model, it takes 10 min to make the model, and then 5-20 sec for correcting each frame, depending on the resolution. It's about 10 sec for a 1080p frame. On the 3.5GHz 4 core it will probably be a lot faster, especially if you can use parallel computing. 

 It sounds to me like this is a full-blown render operation. What about, also/instead, a plug-in for something like DaVinci Resolve? The plug-in could analyze a reference (like your algorithm does) but generates a "correction" or LUT that can be applied in a new node. Basically a filter or "look" that can be cut, copied, pasted, blended to varying strengths, etc. to any clip in the timeline, with live preview. Rendering would take place using the Resolve engine once the project is finalized, as any normal Resolve render job.

There would be quite an advantage to have this tool built-in to an established colorists' workflow. I think you'd have commercial hit on your hands. Perhaps you already have a goal like this in mind.

No goals yet, just did it for the fun of it. 

I'm pretty sure there's nothing left to squeeze out of the GOUT. I think for the final version, I will go for SRV11, since that has the most detail, and less static grain. What do you think?

That gets my vote (as you probably could have guessed) :-).  SRV11 is the best one I think.  Are you planning to do it from the raw GOUT or the cleaned up towne32 version?  I am a bit worried the cleaned up version may cause some detail loss since it is altering the source, but I am not sure. 

I will be using towne32's version. He did a great cleanup job, that does not affect the detail recovery of SR. 

Thanks.

I had concern as well at first, but I sent it to Dre in lossless format and told him not to use it if there was any quality loss in SR comparison tests.

His recent previews use it, I believe. So please do mention if there are suspected problems due to the source! While I was reasonably confident in it, I don't think I would have submitted it to him without more intensive review if I had known the rendering time that would be required for SR.

I would agree, SRV11 has my vote now too.

So after all, the removal of "slowly moving grain" has been canceled? Too much detail loss?

zee944 said:

So after all, the removal of "slowly moving grain" has been canceled? Too much detail loss?

 Some of it was removed for V11, but not to the extent of 12-14. Versions 12-14 removed too much detail in the process.

V11 is the best of both worlds. :)

Zyrother said:

zee944 said:

So after all, the removal of "slowly moving grain" has been canceled? Too much detail loss?

 Some of it was removed for V11, but not to the extent of 12-14. Versions 12-14 removed too much detail in the process.

DrDre was working on SRV13 when he said he'll try to eliminate the slowly moving grain...

zee944 said:

Zyrother said:

zee944 said:

So after all, the removal of "slowly moving grain" has been canceled? Too much detail loss?

 Some of it was removed for V11, but not to the extent of 12-14. Versions 12-14 removed too much detail in the process.

DrDre was working on SRV13 when he said he'll try to eliminate the slowly moving grain...

 My mistake, I thought he started with it earlier. Either way, the removal of the grain was detrimental to the recovered detail.

He did post the scripts, so anyone can edit it and do what they wish!