Messages

You're on Windows? Meh... hm, then we have to wait for Bouncyball, I only could compile a 32bit version for you, but don't know exactly what was changed for this force dual iso... my success here was not at 100%. I thought you know what Bouncyball changed there.

@Bouncyball: I think I found it... it works nice now! I changed scale_bits_for_diso in dualiso.c. The problem is 12bit lossless seems to bring to high values and the sh** happens. I inserted two lines for limiting the shifted values and voilà... but maybe you have a better idea to correct it

Code Select Expand

int scale_bits_for_diso(struct raw_info * raw_info, uint16_t * image_data, int lossless_bpp)
{
    ...
    else if(lossless_bpp < 14)
    {
        ...
        for(int i = 0; i < pixel_count; ++i)
        {
            uint32_t temp = (((uint32_t)image_data[i] - raw_info->black_level) << shift_bits) + raw_info->black_level;
            if( temp > 16383 ) temp = 16383;
            image_data[i] = temp;
        }

        return 1; // scaled for losless dualiso
    }
    ...
}

You shift by 2, that multiplies by 4. Whitelevel is 5586. 5586*4=22344 ... that is more than 14bits, so all over 16383 is cut.

@Kanakori: you can compile? Change these few lines and you can render your clips for now...

@Kanakori: download is finished for me and I watched into the MLV. For me it looks like both channels - the dark and the bright one are overexposed in the defect areas. Look here, first picture is dualIso=Off + HighlightReconstruction=On + Exposure=-3, second picture dualIso=On (highlightReconstruction don't cares, because there are no more highlights to detect after wrong dualIso rendering):


@Bouncyball: do you have an idea what happens in complicated dualIso rendering here? For me it looks like something in the 16bit to 20bit to 16bit is going wrong... but can't figure out where. Like very bright areas are cutted and become black (or other nice modern color).

Edit: hmmm... preview mode is working...

But converting in Cineform or Lagarith as you suggested requires an extra passage, am I right? Anyway do you think ProRess 4444 is a good codec in terms of quality?

Cineform and Lagarith is not supported by MLVApp, so you need an extra passage, right. I like the quality of ProRes 4444, but it always depends on your workflow and what you want to get if it is enough.

Ok I can send you a clip as an example through private messaging

Thanks, I'll download and take a look!

@Rogan Thoerson: thanks for sharing. I can reproduce it in v0.16, but in latest revision from our repository it works fine. So the issue seems to be fixed already. We changed a lot in terms of black and white level - there was a very tiny bug in MLVApp, but also ML for 7D is not correct here. But with latest revision you can correct the wrong levels of 7D clips (whitelevel is stored as 16200 @ ISO100 but is somewhere around 14300 on the 7D I tested and somewhere at 15500 on yours). With correct whitelevel highlight reconstruction for 7D clips also works fine.

So if you are on Mac, Danne wrote a compiler app and you could build the latest revision, or you would have to wait some days until we release v0.17.



Edit: The blacklevel is also wrong: it is 2414 in this file (uncorrected) and with 2048 all is fine. Maybe here was the problem, because the RAW-Correction part was working with the wrong uncorrected blacklevel until last week. That is fixed since some days.

Is it correct you filmed the clip with a 1/0sec shutter?! For me that seems wrong too.

A button for loading video to RAM is not there, but a submenu: "AMaZE Cached" can load the debayered clip into the RAM until a memory limit is reached, only processing is done when being played.

@feureau: thanks for reporting, but I need more information about your system, all versions and what you do else. What resolution has the darkframe, what resolution have your clips (are these resolutions always the same?)
I can't reproduce the error you reported.

I believe I used that option... on mlvproducer that doesnt happen even with dual iso option activated, but I don't like the workflow on there and I can't get the same results. However the fact that these spots don't show up in mlvproducer might mean the problem doesn't come from the clips?

I can't tell you if it comes from the clip - I don't have it And I never saw such artifacts on highlights in any clip. MLVProducer has a different highlight reconstruction, maybe this one is more effective against such extremly crushed highlights. I can't tell how it works, because I never saw the source code, but I know from my tests it works different
Please upload some frames (cut it and export as MLV), so I could have a look what happens...

@Danne! NICE! 5x???

@masc
Retested and refined/pushed the "last resort" setting to this instead:

Code Select Expand

        QString pass3 = QString( "-filter_complex \"[0:v] boxblur=1:cr=5:ar=5 [tmp]; [0:v][tmp] blend=all_mode='normal':all_opacity=0.7\" -c:v
Thanks again for fixing all quirks around ffmpeg in your code.

Looks good! Thanks for your work and your tests! 

@Danne: I added your changings to the repos. Where is the difference between -crf 0 and 10? Both looks way sharper than before! The blurbox indeed is very blurry...

@Danne: really nice! Do you want me to add "boxblur=1:cr=4:ar=4" or better "boxblur=2:cr=5:ar=5"?

@Kanakori & 50mm1200s: Yes, this are very crushed highlights. Normally they get pink only (because the green channel clips only mostly)... here it seems all channels are clipped, so they have any color. Maybe also dualIso makes it more strange. Blown highlights are no problem in non-dual-iso, but are a huge problem in dual-iso-clips. Highlight reconstruction will work only slightly (if it works at all in this special case). So the only way is to raise light strengh. But I am not sure if that works, because the artifacts are very dark.

@olofen: from the quality side lossless and uncompressed cdng is the same, lossless is compressed without quality-loss (as the name tells). So uncompressed could be a little faster (don't needs to be uncompressed when used), lossless is smaller on your harddisk.

[Edit]

@Danne: Look this: slightly more blurred and correct color:

Code Select Expand

ffmpeg -i M05-0608.mov -filter_complex "[0:v] boxblur=1 [tmp]; [0:v][tmp] blend=all_mode='normal':all_opacity=0.5" -f matroska - | \
ffmpeg -i - -vf minterpolate=50,tblend=all_mode=average,framestep=2 -f matroska - | \
ffmpeg -i - -vf minterpolate=50,tblend=all_mode=average,framestep=2 -f matroska - | \
ffmpeg -i - -c:a copy -c:v prores_ks -profile:v 2 -pix_fmt yuv422p10 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -vf minterpolate=50,tblend=all_mode=average,framestep=2,unsharp=7:7:0.8:7:7:0 out.mov
The higher the opactiy value, the sharper the result.

Edit: it is commited to the MLVApp repos, so you can try it out. To play with the values, look at line 1472 in MainWindow.cpp. I think we have to raise opacity in order to get a sharper image.

[Edit]

@Danne: is it bad to do it this way:

Code Select Expand

ffmpeg -i M05-0608.mov -filter_complex "[0:v] boxblur=1 [tmp]; [0:v][tmp] blend=all_mode='overlay':all_opacity=0.5" -f matroska - | \
ffmpeg -i - -vf minterpolate=50,tblend=all_mode=average,framestep=2 -f matroska - | \
ffmpeg -i - -vf minterpolate=50,tblend=all_mode=average,framestep=2 -f matroska - | \
ffmpeg -i - -c:a copy -c:v prores_ks -profile:v 2 -pix_fmt yuv422p10 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -vf minterpolate=50,tblend=all_mode=average,framestep=2,unsharp=7:7:0.8:7:7:0 out.mov
For me that works. Looks slightly more blurred than without the blur box (so for me as expected), but a lot brighter... is it because I use the wrong stream, or is it the same in your tests?
Edit: tested again your command with ...[1]... and it looks the same for me as the above command. So the blending seems to be not right.
Edit2: color looks right, when changing overlay mode to this, but it looks very blurred, and there is a boarder:

Code Select Expand

ffmpeg -i M05-0608.mov -filter_complex "[0:v] boxblur=1 [tmp]; [0:v][tmp] overlay=50:50" -f matroska - | \
ffmpeg -i - -vf minterpolate=50,tblend=all_mode=average,framestep=2 -f matroska - | \
ffmpeg -i - -vf minterpolate=50,tblend=all_mode=average,framestep=2 -f matroska - | \
ffmpeg -i - -c:a copy -c:v prores_ks -profile:v 2 -pix_fmt yuv422p10 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -vf minterpolate=50,tblend=all_mode=average,framestep=2,unsharp=7:7:0.8:7:7:0 out.mov

@Kanakori: good to know it works! Have fun!

So far as I understood, a double stream is impossible with our solution - we would need a platform specific special solution... (not good)
The command in your last post crashes (ffmpeg brings error and MLV App does not like it).

I think we need another way to come to the 2nd stream. If I add the pipe twice very strange things happen (looks like modern art) ... is there a way to copy a stream before doing something with it?

@Danne: ups... double input in the first call? Is that possible via pipe too?
For us the input from MLV App looks like this (EOS 5D Mark II with near-to-FHD):

Code Select Expand

ffmpeg -r 25 -y -f rawvideo -s 1856x1044 -pix_fmt rgb48 -i -
Is it possible to add this twice? I would expect, ffmpeg waits for 2 input pipes then... (but there is only one).

@bouncyball
It seemed to work fine but I can't find the exported files anywhere.
The export is resumed, I go to the chosen directory and nothing's there...

@Kanakori: To what format and options do you export?
@bouncyball: how did you force dualIso in the code?

Really strange...
I downloaded your MacBeth MLV and exported as DNGs w/o a problem, be it lossless or uncompressed. Both are exported fine!

@olofen: same for me. MLV exports fine without any problem - I tried uncompressed and lossless, both with both possible naming schemes. Did you move the file to another folder while it was opened in MLVApp? Or did you try to save it to a location where you don't have writing rights?

It is an 667 MB MLV file - do I send it with WeTransfer and in that case to what adress?

Yes, for example. You can post the link here, or you send it to me via PM.

I tried in vain with both Cinema DNG uncompressed and lossless but got the following answer (see attachment)

Please upload a file which produces this error! We'll search for what is going on there...

For me working as an artist with color and changing A LOT of the content it is almost mandatory to work in 16 bit. Do you have any suggestion how to achieve this with the MLV app? Or ideas?
I work mainly in photoshop.
/olof 

If you work in Photoshop, chose cDNG, this is unprocessed (or at least lossless) and has full raw info availlable.

I am missing one file format...
Instead of the cumbersome but invaluable Tiff sequence with its 16 bits of colour I would like something like the Avi uncompressed (unfortunately still smaller than the original mlv file though...) but with 16 bits of colour and at least the same size as the mlv.
Is this possible to achieve?

Uncompressed avi is not 16bit atm, right. I changed the format to 16bit for a quick test: VLC tells in metadata viewer it is 16bit, but it is impossible to decode. All other player also can't play it back...

@Kanakori: please upload one of the clips where it does not work, so we could analyze what happens. Thx. Does the viewer show it correctly? What OS are you using?

Shameless plug: you might also find this idea useful (WB picker on skin). Back then I've used a hardcoded ratio between R, G and B, from a reference photo with skin tones that looked good to me. Purists will scream, as it's too much of a hack, but I've found it handy.

WTF?!?!?! I added your values in a quick test and it seems to work out of the box. Crazy... cool! I'll think about how adding this to the app! Thx! Hahaha...

Edit: hope you like it? With the new button you can toggle between grey and skin.

[Edit]

Yes, that should be possible. Right now you can also press B, that may be faster than searching the button again. From the function side this is only one single line and it does what you want. But Qt has some predefined function in the graphicsview to show these hand cursors... and after each click the pipette is away... Where do they do that?! I have to find the place...

Edit: found it and commited. Done.