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

Make AMaZE cached not just be for AMaZE #121

Closed ilia3101 closed 4 years ago

ilia3101 commented 5 years ago

Should just be an option "cached".

This is a reminder for myself.

ilia3101 commented 5 years ago

An idea: could we have amaze as default coz noobs might open it up, see bilinear aliasing and think mlv app has bad quality if they don't know it can be changed.

It's normally the first thing I change (not cached though)

masc4ii commented 5 years ago

Hmm... But then playback is very slow. ... Others like functions like autoplayback (not me). How about an indicator to see easier what debayer is selected? Maybe showing something in statusbar?

bouncyball-git commented 5 years ago

Great idea. I'm not a fan of auto anything too...

ilia3101 commented 5 years ago

Hmm... But then playback is very slow. ... Others like functions like autoplayback (not me). How about an indicator to see easier what debayer is selected? Maybe showing something in statusbar?

In cocoa app, if it was set to bilinear, the first frame when you open an MLV would load as AMaZE. And then if you went to a different frame, it would load the AMaZE once you make an adjustment.

Could we maybe do this? I rarely use playback, maybe this would be a good compromise as a lot of people do.

ilia3101 commented 5 years ago

Yeah no auto playback don't really like that

ilia3101 commented 5 years ago

argh how I started a completely unrelated discussion

edit: it is related actually should stay here

ilia3101 commented 5 years ago

New idea: What about one debayer setting for viewing/editing, and a separate one for playback? So AMaZE by default for viewing, but then switch to bilinear(or whatever the use set) when play button pressed?

bouncyball-git commented 5 years ago

Yes! I think that is how mlrawviewer works.

masc4ii commented 5 years ago

Wait... To come back to the topic: yes, a IGV and LMMSE cached would be a nice thing to have. For others it makes no sense at all, you know.

For the autoswitch: in the end I am very satisfied as it is, because I always see what I set. For my latest video, I rendered with MLVApp, I used 50% AMaZE, 45% IGV and 5% LMMSE. Often AMaZE brings biggest problems with sharp lenses - lots of moirée. IGV is way better here.

This is why I don't like always to have AMaZE as viewing algoritm. I think in a slightly different way, because for me it was really hard to remember which MLV was rendered using which algorithm:

We don't make debayer algorithm globaly switchable, we add that open to Edit dock. So you can set it up for each clip independently. If the playback is stopped, we show the clip with this algorithm. (Bad thing (but same with your idea): MLVApp will be very inresponsive after stop for 0.5sec (at least on my systems)). From menu we select a "Playback debayer" to improve speed on playback. Here you could select between "None, Simple, Bilinear and Cached". For "Cached" we should somehow implemement a progressbar, because really nobody understands how it works, and wonders that it is slower than non-cached (while it is rendering)...

So each clip is saved to session with its optimal debayer setting and can again be exported in batch (for my project I had to export clip by clip in order to get best debayer results).

Edit: for export I would like to have something like: "chosen debayer", "force bilinear", "force LMMSE", "force....",... because for fast proxy I use bilinear debayer in export.

ilia3101 commented 5 years ago

From menu we select a "Playback debayer" to improve speed on playback. Here you could select between "None, Simple, Bilinear and Cached".

This is a good way to implement it!!! Very good idea

For "Cached" we should somehow implemement a progressbar, because really nobody understands how it works, and wonders that it is slower than non-cached (while it is rendering)...

That would also be nice

Edit: for export I would like to have something like: "chosen debayer", "force bilinear", "force LMMSE", "force....",... because for fast proxy I use bilinear debayer in export.

Also a good idea

masc4ii commented 5 years ago

We'll have a little problem with this concept: clip setting and viewer setting may be IGV, while preview setting is AMaZE cached... so we need both debayers in parallel... keep that in mind! 😄 Preview debayer will only be active, if play button is pressed. I think we have no other possiblity to choose a algorithm. Or have we?

masc4ii commented 5 years ago

Please try latest commit: -select preview debayer via menu -select viewer debayer via edit pane -select export debayer via export settings + edit pane

Problems: (best to try with "None" as preview debayer) When hitting stop, 50% the viewer shows right debayer, 50% wrong debayer (maybe multithread problem... have to search).

I made caching invisible for now, because it can't work with this strategy.

masc4ii commented 5 years ago

Bug is solved. For me that runs really fine now. Really easy. Now we only need a kind of second processing channel, where cached pictures are placed in, if caching is enabled...

bouncyball-git commented 5 years ago

When playback is stopped itself at the end the selected debayer is not kicking in. Sometimes selected debayer not kicking in when playback manually stopped.

masc4ii commented 5 years ago

Really? It still happens for you? I was hoping that is solved with latest commit. No idea what still could be the problem...

masc4ii commented 5 years ago

Please try again. Had the same on a slower MBP (first one of your issues).

bouncyball-git commented 5 years ago

Works great!

masc4ii commented 5 years ago

What has to be done next here: we need to split debayer channel to a viewer debayer channel (what we have right now) and a caching debayer channel (works in background, while viewer already shows with any debayer, and loads selected type debayer images in cache (might be different type to viewer)).

bouncyball-git commented 5 years ago

Won't it complicate caching thing further?

Well I personally always thought the caching should be done on 1st access of the particular frame to save the CPU. Not doing this always in the background, but anyway...

masc4ii commented 5 years ago

Yes, sure, it will be more complicated than now. There must be a one frame buffer for actual frame in viewer (lets say e.g. IGV). Then, if preview mode "AMaZE cached" is selected, another thread (or more threads) render in background and save the frames in another buffer. While this time the user can adjust the IGV buffer frame. When user starts playback, we read out the cached AMaZE frames. In the end, playback won't be faster than now. The only benefit will be, to see a better quailty preview, after some waiting time.