Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - masc

#1626
Quote from: Danne on July 19, 2018, 02:32:43 PM
You are fast @masc.
What is IGV demosaicing doing? Hadn´t had the time to check into reading yet.
Puh... don't ask me... :D "Bayer CFA Demosaicing using Integrated Gaussian Vector on Color Differences". I found an implementation which was not to different from our AMaZE interface, adapted the code and voilà. In hard contrast scenes it looks slightly better than AMaZE, therefor it looks a bit more noisy (specially after sharpening). One disadvantage is a bad 8pix border, where the algorithm is not able to work - in this areas there is an easier border-algorithm working, which produces some artifacts (e.g. on water). Looks a bit like bilinear... but I don't really know... :P
#1627
Raw Video Postprocessing / Re: MLVProducer: [v3200]
July 19, 2018, 01:09:36 PM
Quote from: ArcziPL on July 19, 2018, 12:15:08 PM
I've just checked it out: no, it does not. And indeed, the preview is faster than MLVApp. It offers real-time preview on my machine (25fps) whereas MLVApp achieves ~18fps on the same MLV. Need to have a closer look.
I think that depends on which debayer is used, and what other settings you activate or deactivate! On playback it looks like MLVProducer uses a fast and easy debayer - MLVApp uses bilinear as standard (a faster algorithm comes in next version). On export with the best debayer available the result may look different (on my machine 1.9fps (MLVProducer) vs 5fps (MLVApp)). But I am not sure if it is fair to compare the two algorithms, because they are different - all the realization and concept is completely different! ;) When doing nearly the same: chosing the fastest debayer + a LUT brings on both programs 5fps at playback for me.
#1628
Oh, this site looks interesting... so many algorithms?! Thx! Unfortunatelly CUDA is no solution for me... that works on none of my computers... :D (what is my main reason for developping this app)

BTW: IGV demosaic is available in MLVApp now! ;)
#1629
Quote from: 50mm1200s on July 19, 2018, 11:15:13 AM
Just curious: does MLVApp autodetects white levels or use predefined values?
@a1ex explained why this would be a good idea:
https://www.magiclantern.fm/forum/index.php?topic=10111.msg98298#msg98298
https://www.magiclantern.fm/forum/index.php?topic=10111.msg98359#msg98359
MLVApp reads out the whitelevels which are saved in the MLV by the camera. These values might be wrong (I saw that @ 7D and others already), this is why we implemented RAW white level slider - so you can adjust it manually to the right value.

Quote from: 50mm1200s on July 19, 2018, 11:14:45 AM
Ok, I'm trying.
Great! Feel free to ask if you have problems with it...
#1631
Quote from: olofen on July 18, 2018, 11:49:49 PM
MLV > CinemaDNG > TIFF  versus  MLV > TIFF directly

Do I get the same 14 bits of colour when I export files from the MLV app first as CinemaDNG and then convert them to 16 bit TIFF files as I would get if I export them directly into a TIFF stream from the MLV app?
Someone said that a TIFF stream directly from the MLV app only retains 8 to 10 bits of colour....

No you don't get the same colour. But this is no question of bitdepth. MLVApp exports 16bit TIFF.
If you export TIFF directly you export processed data. If you export cDNG, you export RAW data. The RAW data has to be processed somewhere else. I bet it won't be processed in the exact same way as MLVApp does. So the colour will be different.
#1632
Quote from: 50mm1200s on July 18, 2018, 10:37:33 PM
@masc @bouncyball How can I debug? I'm using the binary from github. Tried to execute from terminal, but it's quiet (no verbose info, even with --debug). The binary seems to use QT 5.9.1. I don't know how to compile on windows, just on linux, and I don't think this issue happens on linux (from what you're saying)...
You need a installed Qt and the source code. You load the .pro into QtCreator, setup the debug mode, press debug, do the crash, and Qt tells you where it crashes. For me it also does not crash on Windows...
#1633
Quote from: 50mm1200s on July 15, 2018, 11:56:15 PM
A proper denoising algo would be better, no? This and this implementations are GPL licensed, maybe it could be adapted. Just an idea.
Yes, totally right. A denoising algo would be best. I could test this algo in MLVApp, because it was easy to adapt to what we need:
http://www.ipol.im/pub/art/2011/bcm_nlm/
It works but it is soooo slow - OMG - some minutes per frame, and only on Win & Linux multithreaded to work correctly. So no real solution for us ;)
#1634
Quote from: 50mm1200s on July 18, 2018, 02:32:41 AM
Last release for Windows is crashing during batch export (ProRes 444), while using darkframe subtraction :(
Darkframe sample (averaged using MLVApp):
https://minfil.com/S8b8tdf3b6/50d_iso_100.MLV

ps: it renders ~3 files on the batch, then crashs.
Yeah... known problem. But I am not able to reproduce it on any of my computers. I can export as many files with darkframe as I like. Do you have Qt installed? We need someone who has this problem and who is able to debug.
#1635
Quote from: bakersdozen on July 15, 2018, 02:55:49 PM
Anyone else having issues with Full-res LV files from 5D3 113 (latest experimental crop build) crashing MLVApp when loading an .mlv file? I've tried both FRSP with intervalometer (output as .mlv) and RAW 14bit lossless with FPS override set at different rates from 7 down to 0.150. As soon as I select the the .mlv it crashes MLVApp.  Tried on latest (OSX) version and with the previous version giving same result. The files work as desired on MLRAWViewer, so they don't seem to be corrupt. I can't seem to find any other mentions of this in the thread, please forgive me if this is a known issue. Not sure if it has anything to do with being 5796x3870 resolution.

Here are the files, there is a FRSP (300MB) version, the RAW Version (1GB +) and the OSX crash log.

https://www.dropbox.com/s/zzd8x93zhs089ck/FRSP.MLV?dl=0
https://www.dropbox.com/s/38ylyldopa0qx9y/M15-1511.MLV?dl=0
https://www.dropbox.com/s/g8s6krnyzhbs15s/crash%20log.rtf?dl=0

Some shots have the sky blown out as I forgot my ND filter.
Thx for the clips. I found the problem very fast: the problem is that these files are <1.0fps. MLVApp was not made for clips with so low fps ... at least I forgot that it might be possible ;)
I made a quickfix - that means: if the clip is <1fps, I set it to 1 fps. Otherwise it is very hard to show a correct timecode... (timecode was the crashing module). So you can compile the latest revision using Dannes compiler tool, or you wait for next release. ;)

Quote from: IDA_ML on July 15, 2018, 05:07:11 PM
1) A crop and rotation/straightening tool - similar to the one in ACR for example;
2) Extention of the chroma separation tool with cleaning also some of the monochromatic noise.  Right now, it does a hell of a job by perfectly removing the color noise.  If one more slider could be added for the monochromatic noise, that would be fantastic! 
1) You really would do this in MLVApp? I always do it in the NLE - each pixel might be good for stabilizing for example... after this I crop it if necessary.
2) That should be possible to add... let's see... but you'll get a very blurred image.

I found an implementation of LMMSE debayer with correct interface in C, so I added it to MLVApp now. Has someone used it in past in any other program? I have the problem that hard contrast lines are getting very green and cyan. Is that normal? Only highiso clips are okay... but AMaZE looks nearly always way better.
#1636
Quote from: Ilia3101 on July 11, 2018, 09:26:52 PM
I will try out integer multiplication + right shift method, maybe will be faster than look up tables.
Sounds good Ilia!

I added two easy debayers to MLVApp! One is monochrome (just copies RAW data to image) and another very simple & stupid colored debayer which looks worse than bilinear. Both are multithreaded and a little faster than bilinear (but not much). So just for viewing motion in a clip it might be okay...
#1637
Quote from: Ilia3101 on July 11, 2018, 06:12:59 PM
wow processing is slow.
Is that 21fps with no processing with no caching too?
Yes. But bilinear has almost the same speed like AMaZE cached for me.
Maybe I should analyse where exactly the time goes by on processing...

Edit: all the matrix operations cost time (white balance & exposure the most)... but no idea how to accelerate this. The concept is fine in my eyes.
#1638
Quote from: 70MM13 on July 11, 2018, 04:08:59 PM
How long would it take to grab the existing library from rawtherapee?

It is open source.
It is not very compatible (C++, we are using C, so has to be adapted) and each algorithm has another undocumented interface. But I don't think that we will get faster with another algorithm. Just for testing I commented debayering out (looks very weird ;) ) but had nearly the identical speed as bilinear. On the other side: switching off processing brings factor 2.5 in terms of speed on my machine. In numbers: 8fps (normal) vs. 8 to 9fps (no debayer) vs 21fps (no processing) on a old notebook @FullHD.
#1639
Hm, okay. But is it really better? For me it looks just more blurred than AMaZE. All artifacts are still there, sometimes with more false colors.
#1640
Quote from: 70MM13 on July 11, 2018, 02:36:20 PM
It would be awesome if you guys added more demosaicing algorithms.  Here's an example of one other from rawtherapee:

https://www.magiclantern.fm/forum/index.php?topic=22483.msg203990#msg203990

And which algorithm did you use in your example? Default in rawtherapee is AMaZE.
https://rawpedia.rawtherapee.com/Demosaicing
#1641
Quote from: feureau on July 11, 2018, 04:42:29 AM
Bugreport: If MLVApp encounters a corrupt MLV, it will crash.

If you have a bunch of MLVs in the Session and you batch export them all, when MLVApp encounters a corrupt MLV, it will spit out an error like this:



If you click cancel, the whole thing will just crash.

Maybe allow an option to abort/retry/ignore(skip) the file?
Thanks for the report - I fixed it two days ago. There was a a little line missing in the code, so the app was running into undefined memory what crashes the app. But I will recheck what happens on export.
#1642
@VGT: thanks for the sample.
@bouncyball: do you have an idea why vertical stripes does nothing for this clip? Could you debug? Something is very different to the 7D I hold in my hands some weeks ago: whitelevel is at 16383, on my sample it was at 15500 (at least highlight reconstruction works for whitelevel slider at full 16bit - very strange). Who knows what else is different here what maybe makes vertical stripes algorithm not working...
For me the stripes themselves are looking 100% the same as on the 7D I was playing with.
#1643
@VGT: have you tried setting "Vertical Stripes" to normal? Should work for exactly what I see in your pictures.

@IDA_ML: Oh yes, the dynamic is huge in your clip! Very nice.
Renderspeed is always the same (for the same settings chosen) because we always give the same series of uncompressed pictures via pipe to ffmpeg or to the AVFoundation class. The codec needs different time to encode this into your video file. But when dual iso is enabled, you won't recognize any difference here, because dual iso processing is so slow. On non dual iso clips ProRes 422 AVFoundation was one of the fastest codecs in my tests.
#1644
Quote from: IDA_ML on July 08, 2018, 08:55:22 PM
Yes, I use the "RAW Correction" functions a lot:  focus pixels, bad pixels and Dual ISO lately.  But I also apply highlight recovery to every overexposed clip, sometimes LUTs as well as sharpening and chroma smoothing to the footage.  The latter cleans chroma noise nicely. ...  I only wish, MLVApp export was faster.

Quote from: Ilia3101 on July 09, 2018, 10:19:38 PM
Some of those algorithms, especially dual ISO will just be slow, they are very complex(also good btw), and I wouldn't even go near them in code as I don't know how they work or how I could make them faster.
Unfortunately it might just be a fact of life that some are slow :(

Yapp, unfortunately dual iso and most of the RAW Corrections are written for single core only atm and I also don't really understand how it works. For most RAW Corrections that is no big deal because they are fast. But dual iso is another story...
All the processing and debayer stuff is multithreaded already... so this part is not sooo slow - we got >20fps on i7 machines for "normal" clips. The good thing of the slower non-OpenCL SW architecture is: it works on nearly every computer instead of many other programs. First OpenCL tests were working on bouncyballs computer, but I got only crashes because I don't have such hardware :D
#1645
Quote from: feureau on July 08, 2018, 01:04:43 PM
I tried reimporting the clips with different order but it still happens.

I never used QT before so I'm not sure if I can get anything useful, but let me see if I can set it up.

Anyway, is it possible that it's caused by having the .mlv darkframes in a separate drive? (regular spinning disk HDD, not SSD)
I can't tell how to setup a 64bit version. 32bit (MinGW) is just downloading and installing. Download repos, open .pro in QtCreator, select Debug toolchain, build, start debugging. Then do what you always do - BAMM - and the debugger should show the line.
#1646
Quote from: IDA_ML on July 08, 2018, 11:27:03 AM
Hello Masc,

Here is one of my 100D test clips that has the pink highlight glitch in the window area after processing with v.017.  All you need to do is open it in MLVApp, activate Dual ISO, make corrections to your liking and export it in H.265.  Then, you should be able to see the pink area. 
Thanks @IDA_ML. This clip is perfect for debuggin... I get other effects on rendering than you... depending on how many cores of the processor are rendering (on dual core it does not blink, but real pink color areas are filtered). I think I have still have to change some things in the highlight recovery algrorithm for dual iso... that is so tricky...

@bouncyball & Danne... 8) do we need some birthday cake? 🎂 🍰 :D
#1647
Quote from: bouncyball on July 08, 2018, 11:19:47 AM
Edit: BTW congrats! you've become a Hero Member :D
LOL... yeah... thanks. In 5 days it is one year ago, when I started programming the GUI with Ilias processing code! ;)
#1648
Quote from: feureau on July 08, 2018, 04:05:36 AM
MLV.App.v0.17.alpha.Win64.static keeps crashing when batch exporting with Dark Frame Subtraction enabled.

Steps to reproduce:

Import multiple MLVs into Session, enable DarkFrame Subtraction Ext with pre-prepared MLVs for each file, batch export all MLVs as prores.

First MLV will complete render just fine, then MLVApp will crash on second or third MLV.
Don't get it reproduced. Can do this with 20 clips and more - no crash, all works fine. Would really like to know what causes this on your PC with your clips... :(
Do you have some coding skills? I think best would be to run MLVApp via debugger on your PC. The debugger tells us in which line it crashes.
#1649
@ArcziPL: when opening a MLV it is very normal if colors a bleak. WB at 6000K is also normal when you recorded in auto mode. With WB picker I had no problem for all files I got from users, also no problem for EOS M and 700D. So best would be you upload a sample file (you can shorten it before to some frames). In different programs it will look different - sure.

@IDA_ML: thanks! Looks great! Could you provide the clip with the blinking highlight? Maybe my chosen recovery-range is to small...
#1650
Quote from: escho on July 07, 2018, 08:27:54 PM
Yes, he will... ;)
Hehe, for you we had the 8bit rawvideo avi... do you use now 10bit V210 avi as well for your astro pictures?