Messages

Differences between demosaicing on MLVApp (I will stop flooding now, sorry about that):

@masc, found this bug on clipped highlights while using IGV. Here's the MLV.

[Saturation at 75:]

Comparison between Saturation and the new Vibrance implemented by @masc

Saturation at 75:


Vibrance at 75:


Vibrance at 100:

[trying]

Since I was already compiling MLVApp, thought it would be nice to test the WB branch.

With picker on 18% gray card:



With skin WB picker:



With WhiteBalance branch with the same settings as the 18% picker:



With WhiteBalance branch trying to match 18% picker:

@masc @bouncyball sorry for the late reply. I did not gave up on the darkframe issue, just had some work to do...

Sorry if this post is too 'verbose'. I didn't know what info was relevant, so I copied most of it.
From many tests, the function "getMlvRawFrameDebayered" on video_mlv.c always shows up on all demosaicing algos, except LMMSE. Lines 411 and 435 of video_mlv.c for Bilinear, AMaZE and IGV. See below for details...

I'm using MinGW to compile, not VS.
Tested again, with the change committed.
With AMaZE, it segfaulted on line 1496 of amaze_demosaic.c (reproduced twice):

Code Select Expand


blue[row][col]=65535.0f*(rgbgreen[indx]-Dgrb[1][indx>>1]);


Too many warnings, most of them saying "redundant parenthesis surrouding declarator". So I copied only the ones I've found to be relevant:

Code Select Expand


MLV-App\src\debayer\amaze_demosaic.c:137: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:153: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:331: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:332: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1071: warning: implicit conversion changes signedness: 'int' to 'unsigned int'
MLV-App\src\debayer\amaze_demosaic.c:1364: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1364: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1364: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1365: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1365: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1365: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1366: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1366: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1366: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1367: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1367: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1367: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1394: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1394: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1394: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1402: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1402: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1402: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1549: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1549: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1550: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1550: warning: implicit conversion increases floating-point precision: 'float' to 'double'
MLV-App\src\debayer\amaze_demosaic.c:1551: warning: implicit conversion loses floating-point precision: 'double' to 'float'
MLV-App\src\debayer\amaze_demosaic.c:1551: warning: implicit conversion increases floating-point precision: 'float' to 'double'


On the second and fourth attempt it segfaulted on line 361 of amaze_demosaic.c, same warnings:

Code Select Expand


memset(nyquist, 0, sizeof(char)*TS*TSH);


So I tried again, just to be sure the issue was on line 1496 and 361, but this time it segfaulted on line 432 of video_mlv.c. What the f*ck:

Code Select Expand


uint16_t * unprocessed_frame = malloc( rgb_frame_size * sizeof(uint16_t) );


Tried again, and he segfaulted on line 411 of video_mlv.c:

Code Select Expand


memcpy(outputFrame, video->rgb_raw_current_frame, frame_size)


And 435 of video_mlv.c (same as IGV, see below):

Code Select Expand


getMlvRawFrameDebayered(video, frameIndex, unprocessed_frame);


Using IGV and Bilinear for demosaicing, he crashed on line 388 of igv_demosaic.c:

Code Select Expand


chr[d][indx]=(eg*nv+ng*ev)/(ng+eg);


Also line 489 of video_mlv.c:

Code Select Expand


get_mlv_raw_frame_debayered(video, frameIndex, raw_frame, video->rgb_raw_current_frame, doesMlvAlwaysUseAmaze(video));


And line 435:

Code Select Expand


  getMlvRawFrameDebayered(video, frameIndex, unprocessed_frame);


LMMSE does not show the same issue on video_mlv.c. Instead, it crashes on line 338 of dmzhangwu.c:

Code Select Expand


OutputRed[i+dataOffset] = OutputGreen[i+dataOffset] - DiffGR[i];


Some stuff shows on malloc.h. He repeats many times this warning:

Code Select Expand


warning: macro name is reserved identifier


There's one different warning on first lines of malloc.h:

Code Select Expand


warning: unterminated '#pragma pack (push, ...)' at end of file



I'll boot Debian now and see if I can run some memory debugger...

I need some help here (disclaimer: newbie here). After reading all this thread and making some notes, I flashed a @dfort's build for 50D with the iso_research branch. Basically, from what I understood:
- Take a picture of a light bulb with normal settings. Use raw_diag.
- Enter menu, expand the BL and WL
- Use ADTG gains and SaturateOffset until the WL starts to decrease
- Increase DFE gain a bit
- Take another picture with these settings. Use raw_diag. Probably able to gain >0.5 on DR.

It seems easy, but on the "ADTG Registers" menu, I don't see how to change BL, WL and SaturateOffset you guys talk on this thread. How can I do that? Also, you folks write using EV values (like "decrease adtg to -0.37EV"), but I can only see registers (e.g, 0x344). I have to calculate these values manually? Here is what's on the menu:

Code Select Expand



ADTG1[105f]N
ADTG1[1061]
ADTG1[1172]
ADTG1[1173]
ADTG1[1178]
ADTG1[1179]N
DFE[1d02]
DFE[1d04]
DFE[1d06]
DFE[1d08]
CMOS[0]
CMOS[1]
CMOS[2]
CMOS[3]
CMOS[4]
CMOS[5]
CMOS[6]
ADTG1[9]
ADTG2[9]
ADTG1[b]
ADTG2[b]
ADTG1[13]
ADTG2[13]




I'm sure many people already suggested that, but, wouldn't be possible to create a script to test all the possible values (brutal force)?

I see there's some pressure here about making this feature into mainstream ML, but it's kinda difficult to help the research on the current state. Even people willing to spend hours reading can't easily get into it.
Based on the practical examples from this thread, this feature would have a high impact on the final result.

So they are using PL mount lenses? Seems to be Zeiss Super Primes. That's very nice.

Very cool. Some scenes have too much unsharp, but that is fine for web streaming.
I've been wanting to try these cool sound effects between transitions. Any of you know how to do it?

Are you formatting with a UDMA7 adapter? Had this issue once and after contacting komputerbay they said you should only format it on these UDM7 CompactFlash to USB 3.0 adapters...

Best settings from @Audionut and @a1ex, for 5D3:
https://www.magiclantern.fm/forum/index.php?topic=10111.msg97743#msg97743
https://www.magiclantern.fm/forum/index.php?topic=10111.msg104278#msg104278

"Rules":

ADTG gains and SaturateOffset can be used to recover some more highlight detail.
changing only ADTG gain is enough (because the other one runs out of range much quicker).
At some point, there's no more highlight detail to recover. When this happens, the white level will begin to decrease. Let's call this the sweet spot, and it can be found easily with binary search, for example.

Once you've decreased the gain enough that your white level is dropping, you've already gone too far.

For 5D2:

SaturateOffset (0xc0f0819c) from 0x66f to 0x66f + 32 - 1024 - 624 and B/W offset (0xC0F08034) from 0x1991 to 0x1991 + 624. Also fix the digital gain (0xc0f08030) to 0x1000.
The effect of SaturateOffset is that it expands the recorded range while bringing in more highlight detail. So, if your default range is say 1024...15760 and you increase this range to say 32-16383 without changing digital gain (these are the 5D2 values), this would be equivalent to scaling ADTG gain to (15760-1024) / (16383-32) = 0.9 (that is, -0.15 stops)

[after]

The other where you exploit 'random'  camera-lens movements, eg super resolution techniques, thus the script I wrote could be useful.

This is correct approach, but there's no lens movement. The idea is very different from yours in many ways. First of all, your method basically uses focus stacking and SR and (seems) to act after demosaicing. The Drizzle idea is not to have a bigger resolution image per se, but to have full information for each pixel. As the bayer filter only have one value for each pixel (RGBG) that is then interpolated to generate the image, the demosaicing algorithm introduces many artifacts. This approach has many benefits (mentioned on the github link above).
Also, I think (not sure) your method cannot work with the "ZeroNoise" as handheld photos will require faster shutter speeds to not generate motion blur (so you will have to change sensor sensibility to achieve correct exposure). The Drizzle can work only on tripod, with fixed aperture, focus and ISO, only changing shutter speed for different exposures. Diagram (click to enlarge):




I don't get why this is difficult to understand. I'm not good with English, so that's probably it.

If anyone have any idea to contribute:
https://github.com/jcelaya/hdrmerge/issues/157#issuecomment-407909189

Maybe it's too complex to be done or this idea is just stupid ¯\_(ツ)_/¯

As @Levas said, the file has the information, but if you don't process you won't see it. I suggest you use the "HDR Tonemapping" from Rawtherapee 5.4. It's designed for these cases.
You should expose the lowest ISO to the highlights first and then use higher ISO for shadow details. You can automate the process using AETTR.
Also, if you are doing photographs of static objects and have a tripod, try HDRMerge with 4 different exposures, output a 32-bit DNG and process on Rawtherapee with this "HDR Tonemapping" feature. This gives the best results you can get, as far as I know (unless this could actually be implemented, still reading about this).

Thank you so much for debugging @50mm1200s. But that sounds all very strange. There is another problem on Windows with caching: I did not understand the problem Windows has there... on Unix all is fine. I will create a issue task on GitHub to save all your information. So we can collect all and read it easily. Maybe an idea comes one day...
https://github.com/ilia3101/MLV-App/issues/96

One of the outputs seems to be BS from the debugger:
https://social.msdn.microsoft.com/Forums/en-US/aeb5b9a7-d23a-43bb-a8c7-131b853d05de/loads-of-senseless-debug-info-show-up-in-the-qt-application-output-window-when-i-run-a-simple-test?forum=windbg

So all warnings up to now are related to memory issues. Could Valgrind detect it, perhaps?

For line 409 I changed one parameter type. Maybe that helps. But I really don't understand the other warnings in line 404, 408 and 409. Is that really in video_mlv.c?

Cool, I'll see if I can test with the new parameter and confirm the video_mlv.c issue.

Heh, my bad. I was looking only on github, so I thought it was open source. Again, my fault.
LUTCalc seems just as neat, though.

50mm1200s, what do you mean jpg sequence? I usually just drag a regular 5d .h264 file into an empty timeline to create a sequence.

Well you said that: "I'm importing the 1080 individual jpg files (exported from lightroom) and nesting the frames as one shot."

I was talking to customer service at Eluktroniks computers and they were telling me the models with the option to switch all of the graphic processing the GPU only would be significantly better than the computers with out it. To me it seems like half the people say GPU is the most important and the other half say the processor is more important. Any thoughts on that?

Both are important, as is the RAM and storage speed. GPU is very important for software supporting CUDA or OpenCL (this is the case of Premiere and Resolve).

The "Drizzle" algorithm was originally invented by Andrew Fruchter and Richard Hook for images made by the Hubble Space Telescope. I worked on it a couple of years during studying, it's an amazing algo. Several astronomy software use it, the first on PC's was Iris if I'm not wrong, since a decade or more.

There's some papers on Drizzle, take a look in the Harvard Library for the source : -> http://adsabs.harvard.edu/abs/2002PASP..114..144F

Thanks!
Do you know any open source software implementing this method? From my research I was only able to find commercial/freeware software doing this.

edit: since video have already a motion between frames, maybe it would be possible to implement this for video too (at least on slow moving images, like landscapes, not for sport footages). Just thinking...

edit2: Found this open implementation.

prores raw would be awesome because its like raw and a proxy in the same file (you can play it back with regular hardware). if we could output to prores raw that would be cool. also if i could put my a7sii footage through and have it come out prores raw that would be cool too. no app for that yet on the market. i know the a7s footage wouldn't be raw but it would be the same file format as my eosm footage and that would be awesome. please don't consider this as a request or demand just talking trash.

You cannot convert non-raw data into raw bayer data. I think you folks need to read more about what a Raw image is, so you can understand the process.

Found this neat open source software. Might be useful of everyone working with LUTs:
https://lattice.videovillage.co/

Black Magic is doing some marketing here, uh?

But you could try to make amaze single threaded.

Could you also test, if it happens the same with any other demosaic algorithm? You can now chose between 4 types in the export settings.

Using bilinear demosaicing, it segfaulted on line 411 of video_mlv.c

Code Select Expand


memcpy(outputFrame, video->rgb_raw_current_frame, frame_size);


And warnings on lines 404, 408 and 409:

Code Select Expand


"implicit conversion changes signedness: 'int' to 'unsigned int'"


On line 409 it also says:

Code Select Expand


implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'int'


The same happens using one thread ("if (1)" on debayer.c), with both bilinear and AMaZE.
There's a strage warning on application output, though:

Code Select Expand


ReturnHr(338) tid(23b8) 8007000F The system could not find the specified unit.
onecoreuap\shell\windows.storage\regfldr.cpp(1239)\windows.storage.dll!7666ED09: (caller: 7666C430)


Using LMSSE and IGV, the debugger doesn't seem to be able to find the issue. It just crashs: "The program has unexpectedly finished. The process was ended forcefully". And then points me to the debug folder.

Any idea?

Are you using jpg sequence for video? I wouldn't recommend that. Try using ProRes 444 or DNxHD.
I have a Ryzen 5, 4GB DDR4 and a very old GPU from AMD and it still playback ProRes. I agree with andy kh, get a Nvidia GPU. Adobe has contract with them, so it's optimized for CUDA. Get a Quadro GPU, such as P1000, they are designed for graphics work.

Welcome!

Though, Black Magic Pocket Cinema Camera beats every Canon Camera when it comes to dynamic range.....

I would disagree with you. Dual-ISO reachs 14 f-stop DR. This is near or more than the most expensive cameras out there can do right now (there's lots of other issues, of course, such as aliasing). If this is right, BMPCC is only 0.5 stops better with normal iso. With the ADTG research Canon cameras could supersede that 0.5 stops (current gains on MKIII seems to be around 0.8 stops, so 0.2 better).
Also, BMPCC has a smaller sensor, compared to Full-Frame sensor of 5D's.

Besides high-end cameras from Arri, Red and Sony, I seriously think 5DMKIII is the best choice. Of course, it doesn't have PL mount and other stuff but the quality is very good.

Thx! So it crashes in this line?

Code Select Expand

memset(nyquist, 0, sizeof(char)*TS*TSH);

Yep. Or so does QT tells me, don't know if it's accurate...

No idea what could shut up amaze algorithm... I am lost. And I don't understand why it only crashes on export... preview is running 100% the same code.

Maybe because of multiprocessing? Memory allocation is different on both cases, don't?

@masc QTCreator points me to line 361 of the file amaze_demosaic.c (on debayer folder), after segfaulting. He also has two warnings (line 364 and 366) saying: "use of GNU statement expression extension". If you need more information, just point me where to find it...

Also, IGV implementation is really nice. A Danne said, you're quite fast. Nice job.

edit: this is about the darkframe subtraction issue, BTW...