search

ilia3101 / MLV-App

All in one MLV processing app.
https://mlv.app/
GNU General Public License v3.0
283 stars 29 forks source link

AMaZE not working right?? #47

Closed ilia3101 closed 6 years ago

ilia3101 commented 6 years ago

Compare MLV App with amaze and bilinear:

AMaZE bilinear
mlvappamaze mlvappbilinear

You can see amount of colour artifacts increases!!! ...or at least doesn't decrease

Now look at MLRawViewer amaze vs bilinear:

AMaZE bilinear
mlrvamaze mlrvbilinear

Artifacts of colour are reduced.

What might be wrong? I have had this suspicion for such a long time, but MLRawViewer really pointed it out to me today.

bouncyball-git commented 6 years ago

You mean AMaZE artifacts are less in mlrawviewer and it's opposite in mlvapp right?

bouncyball-git commented 6 years ago

I've been also thinking about it all the time from the beginning. I have no any idea why it's wrong though :(

masc4ii commented 6 years ago

Same for my clip: MLV App: pic

MlRawViewer: pic

None of these cyan edges on the water is present.

masc4ii commented 6 years ago

One more thing: with saturation full right, these stripes are a very light cyan. With saturation full left (b&w), this are dark lines (see on the water, switch between the pics in tabs): pic pic

bouncyball-git commented 6 years ago

In mlrawviewer use srgb or re709 for comparison with mlv app, not og space as you both did :)

btw exactly what color space we observing in the player of mlv app?

masc4ii commented 6 years ago

I uploaded a short version of the clip for you to test: Download1 And another one with so nice moiree...: Download2

ilia3101 commented 6 years ago

thanks for the clips :)

@bouncyball-git I found the 'HDR' mode in MLRawViewer was almost the same as MLV App's default tonemapped profile, so I did a direct comparison, tried to match them a bit: screen shot 2017-11-19 at 13 59 49 Still clearly shows a difference. As for what colour space MLV App uses or is, well that's still a mystery, though it is being treated as rec709 by ffmpeg, so we could probably think of it as rec709 for now, until we get it figured out a little better. I think it is also being displayed as rec709 (or maybe just the display's native values, but that should be approximate to rec709 on most good screens).. not 100% sure what the Qt display widget is doing. I was going to add an option where the user can specify what colour space their screen is most close to, so it can be output correctly for the screen. That will probably be coming with the planned colour management stuff.

bouncyball-git commented 6 years ago

I always dreamed to use OpenColorIO for color management of my future application ;) now I can say "for our cutest MLV App".

bouncyball-git commented 6 years ago

As for the images above: YES ugly artifacts are there and we have to understand why.

masc4ii commented 6 years ago

It comes not from the processing. I disabled processing, exported a PNG and tried to process with another image tool. The artefacts are the same.

ilia3101 commented 6 years ago

OpenColourIO is worth looking at. Maybe will come to MLV App 😉

Who might know about how to fix this issue? Is there someone on the magic lantern forum who knows about this kind of thing? I really wish this could just get fixed already.

bouncyball-git commented 6 years ago

We should ask there :)

DeafEyeJedi commented 6 years ago

OpenColorIO would indeed be amazing to have it built in within the app. Seems like a long shot and shouldn’t be a priority while in this stage.

Though I can totally see/feel this one coming...

Sent from my iPhone 5s

On Nov 19, 2017, at 10:11 AM, Ilia Sibiryakov notifications@github.com wrote:

OpenColourIO is worth looking at. Maybe will come to MLV App 😉

Who might know about how to fix this issue? Is there someone on the magic lantern forum who knows about this kind of thing? I really wish this could just get fixed already.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

bouncyball-git commented 6 years ago

Yeah, we need to sort out the quality of the AMaZE debayerer first.

ilia3101 commented 6 years ago

http://www.magiclantern.fm/forum/index.php?topic=20995.msg193416#msg193416 Asked a1ex, suggestion is to try white balancing the image before AMaZE. If it works well, I'll add some kind of channel equalizing during the demosaic (and of course reset after to not ruin processing).

bouncyball-git commented 6 years ago

Hmm.. iunteresting how to apply WB (matrix?) to the bayered data. Is it done during normalization?

masc4ii commented 6 years ago

Hm... don't know if that is the reason. If I comment out WB, I would then expect a picture with wrong colors, but without artefacts. I commented the WB+exposure part out: The colors are wrong (okay), but the artefacts are still there. Or was it wrong what I thought? EDIT: or do the artefact go away by doing some WB on the bayered data?!

bouncyball-git commented 6 years ago

I dug into darktable's related code today, it's pure C and source is huge, OpenCL is used all over there for image processing and matrix applying. AMaZE is CPU based thought and works fantastic. If I switch WB off in the interface then greenesh familiar debayered unprocessed look appears on the screen and small aliasing artifacts can be seen on the edges (almos exactly like on our mlv app with processing object wholly disabled). After turning WB on in darktabe aliasing is almost gone even when sharpening is applied.

ilia3101 commented 6 years ago

No, it shouldn't be a matrix, as there's no way to blend the channels, just increase the value of red/blue pixels or decrease the green to get them equalised. I'll show what the results are soon.

ilia3101 commented 6 years ago

I'll try and put it right in to the AMaZE demosaic() function.

ilia3101 commented 6 years ago

Comment inside AMaZE seems to confirm the theory: screen shot 2017-11-21 at 16 19 57

ilia3101 commented 6 years ago

Apologies for the years of bad AMaZE. screen shot 2017-11-21 at 17 31 04 https://github.com/ilia3101/MLV-App/commit/6ed7e00ed9c8223cee4697491f547533667611df seems to have improved it. Up next: automatic multiplier generation within AMaZE for even better channel balance.

Please try it out @masc4ii masc and see if its still worse than MLRawViewer on your clips

masc4ii commented 6 years ago

WOW! I am impressed! Congratulations! This is so much better, also with my other clips!

ilia3101 commented 6 years ago

maybe I'll leave this issue open for a little bit until I get the multipliers automated, as currently its most optimal for daytime white balance.

masc4ii commented 6 years ago

I am still impressed and AMaZEd!!! This difference is unbelievable! Before: pic After: pic You made me really happy today! :-) Now the results with my files are better than with Resolve.

ilia3101 commented 6 years ago

Wow that's a great difference!!! Many shots will be saved. I was beginning to think that the 5D2 is completely doomed every time I used MLV App, but now that feeling will finally disappear :)

bouncyball-git commented 6 years ago

Hey fantastic! I IS A REAL AMAZE!!! Hahaha I feel so better now too! :-D

bouncyball-git commented 6 years ago

Before amaze_no_wb

After amaze_fixed_wb

bouncyball-git commented 6 years ago

GREAT!

Uhm... Can it be tuned little bit more? :P

masc4ii commented 6 years ago

I had to play around with the new version... sry for that :-) youtube Uploaded in 4K, but youtube knows even then how to crush the quality, hehe. Edit: still not perfect, but way better than youtube: https://vimeo.com/244015087

bouncyball-git commented 6 years ago

@ilia3101

Ни как не нарадуюсь как хорошо работает подлеченный AMaZE :-D. Спасибо!