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 - Luther

#201
Quote from: 2blackbar on October 15, 2019, 10:36:40 PM
I bought better quality monitor and i see that id like to get more control over h.264 and 265 compression besides medium high and low quality, will it ever be possible to have a number so we could input our values for export quality ? Some shots i need more and some less, but gap between high and medium h264 is quite big, 50 seconds is 31mb for medium and 300mb for high.100mb for high quality h265, but id like about 60mb.
I asked this before , is there a way to export with our own h264 quality maybe with some command line ?

Would be nice to be able to choose the --crf value and -preset option. +1
#202
Quote from: masc on October 15, 2019, 08:26:42 PM
This should only be the case for ProRes4444. Anatolyi does not offer this kind of export. Did you had this for other codecs?
That's right, my fault.
Quote
In principle it should be the same interface as for AVIR. But they write it is 8bit only. So we would loose a lot of information. And they write that it is not thread safe. No idea what that means exactly... but if multithreading doesn't work with it, 200% on single core will just be ~50%  on quad core.
I think they mean that it might have racing conditions. Don't think it affects the performance, but it might be buggy.
Quote
I think that input color space = output color space. At least I don't see any difference in color.
Yes, not sure why they do this (from avir.h):

/**
* Function approximately linearizes the sRGB gamma value.
*
* @param s sRGB gamma value, in the range 0 to 1.
* @return Linearized sRGB gamma value, approximated.
*/

template< class T >
inline T convertSRGB2Lin( const T s )
{
const T a = (T) 0.055;

if( s <= (T) 0.04045 )
{
return( s / (T) 12.92 );
}

return( pow24_sRGB(( s + a ) / ( (T) 1 + a )));
}

/**
* Function approximately de-linearizes the linear gamma value.
*
* @param s Linear gamma value, in the range 0 to 1.
* @return sRGB gamma value, approximated.
*/

template< class T >
inline T convertLin2SRGB( const T s )
{
const T a = (T) 0.055;

if( s <= (T) 0.0031308 )
{
return( (T) 12.92 * s );
}

return(( (T) 1 + a ) * pow24i_sRGB( s ) - a );
}


Quote
Yes. Fine. But another user reported a bug on github about that. When resize=off but stretching=on (e.g. anamorphic footage) and using ffmpeg, we exported a 3x3 matrix of the clip. Should be fixed now.

Tested now, it's working (with your last commit).

Quote
ffmpeg interprets all input as bt601. This part of the code tells ffmpeg, that we rendered bt709. You clearly see the difference in color when commenting this part. As the code is, the colors you'll get in your exported clip will be as you saw them in the viewer.
Got it.
#203
Tested now the 50D build. Thanks to the @AF-OFF tip about "GB Allow" and "Preview Auto", I'm not getting pink frames. With other configs there is half-screen glitchs.

Using KomputerBay 64gb 1000x:
- 8 seconds on 10bit 3744x1080px
- 7 seconds on 14bit 2160x1080px
- 16 seconds on 12bit 2160x1080px
- More than 1min on 10bit 2160x1080px

This is awesome!

Don't know if that's expected or not, but it fails to load mlv_play.mo:


tcc: error: undefined symbol 'lossless_decompress_raw'
   [E] failed to link modules
UILock: 00000000 -> 41000000 => 00000000


Will it be possible to have live preview? And the 'anamorphic mode' from Danne's EOS M would be possible, eventually? The crop factor is too big for what I need, unfortunatelly :(
Thanks for all the work @reddeercity and everyone that contributed!
#204
Quote from: 70MM13 on October 15, 2019, 01:29:35 AM
it's really quite simple, and i am only using one node to do all of the processing!

nothing but exposure, gain, and offset! (with my customary saturation and hue curves)

the CST is set as follows:
input colour space: canon cinema gamut
input gamma: bmd extended video gen4
output colour space: bmd wide gamut gen4
output gamma: bmd extended video gen4

simple tonemapping

it's breathtakingly fast and easy.  it took longer to convert the mlvs to cdng than it took to do everything else!

Try ACEScct to Rec.2020 :)
#205
General Development / Re: The MLV format
October 15, 2019, 02:09:44 AM
Quote from: Ilia3101 on October 12, 2019, 03:57:49 PM
Edit: just realised you suggested ISC. What is the advantage over MIT?

Both say basically the same: use how you want, just mention authors name. Legally speaking it is also the same (AFAIK, I'm not a lawyer). The difference is: ISC is very short and has less ambiguity. It's also easier for bigger projects to use, because it doesn't increase the text size too much.

Quote from: Ilia3101 on October 13, 2019, 03:33:47 PM
But I want the library itself to depend on almost nothing. CMAKE seems like a good compiling solution just for the library.

Nice. I think Qt is unnecessary. Even CMAKE is. Why not simply use make?
#206
@masc Tested on Windows 10. Couldn't try all possible "permutations", but I've tested on all codecs. It's working flawlessly, even for 4x resize.
Some notes I took while testing:
- FFmpeg Anatolyi doesn't work (can't be selected)
- Is the "CLancIR class" (Lanczos) difficult to implement? According to the AVIR github, "LANCIR offers up to 200% faster image resizing". Might be useful for some people that need faster conversion.
- The avir.h seems to linearize sRGB gamma... doesn't it conflict with other color conversions?
- Stretch transformation is using AVIR? I've tested and it's working too.
- Why use bt601 in:
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt601:out_color_matrix=bt709%2%3 " )
Instead of bt2020?
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt2020:out_color_matrix=bt709%2%3 " )
This way you're going from a bigger to smaller space, which is the "correct". I've tested and there's a small change in chroma noise from what I could notice...

While testing AVIR, I also changed the AP0 matrix to the AP1 in processing.c:

1.6410233797, -0.3248032942, -0.2364246952
-0.6636628587, 1.6153315917, 0.0167563477
0.0117218943, -0.0082844420, 0.9883948585


This gave me the best color results so far. Please test it too...
#207
General Development / Re: The MLV format
October 12, 2019, 03:55:23 PM
@Ilia3101 will you release under permissive license? If you release under GPL is think MLV will not be adopted by some companies. If we want global support for MLV, the library should be permissive (I suggest ISC license).
#208
Yeah, too much artificial sharpen, aliasing, contrast and saturation. Also, the shutter speed is too fast.
QuoteI have been considering getting one of these lenses for that purpose.
I have the impression that 'normal' wide angle lenses for cinema is bad... unless you require it. These lenses normally have more distortion and this crispy digital-look (which is why I personally like to use old lenses). I have heard good things about about the Rokinon Cine, though. Maybe with a diffusor filter like Black Promist it will render very nice images using crop mode...
I still think some old lenses (the good ones, like Zeiss Planar 50mm) and a speedbooster will give more cinematic images.
#209
I cannot reproduce the crash here on Windows 10. Neither the slowness reported by others.
This happens in any MLV file @visionbyeric ? Or only with MLV file with sound? If you can, send me a file (I don't record audio in MLV).
#210
Quote from: turnlemons2lemonade on October 05, 2019, 03:06:02 PM
Also thx @Zeek for the DNG thing, it's much faster for me now to edit and I don't feel like I'm getting old while doing the export.

For this video I just color corrected and converted to Rec709, exported to DNG and cut into FCPX and that's it.
You just ignored the reply of a main MLVApp developer. Not just ignored, but also ironized it ("feel like I'm getting old"). That's quite disrespectful, sir.
We are not selling you anything, btw. MLVApp is open source and free software. Everybody using it is encouraged to report bugs.

Quote
Any other suggestions?
You won't get anything from me anymore.

ps: This is not a place for self-promotion.
#211
I can confirm what @masc is saying. I have a AMD Ryzen 5 and 10s of MLV takes less than 2min (sometimes it takes less than 1min - from MLV to ProRes444).
@turnlemons2lemonade if you want, send me one 10s MLV. I can export and measure the time it takes, so you can compare. 8min for 10s is just not correct.

About the grading: what tools you have on FCPX that you can't find on MLVApp? Grading directly on MLVApp (with wide-gamut) is much better than grading on FCPX. It's not a matter of opinion on this, it is just technically better.
#212
Hey @reddeercity , thanks for coming back to work on 50D. I will test later your build and report any issues.
#213
If you have access to other 5D3 with ML, there's the "card benchmarking". It will measure R/W speed. Put the same card on both cameras and then compare the values...
#214
Not sure if I'm following you guys. Isn't ML just reducing the amount of possible tones per channel from 16.384 (14-bit) to 1024 (10-bit)? How could you apply "log" into this if it's an absolute value?
#215
Quote from: Johnny Yul on October 01, 2019, 03:41:36 PM
10bit raw is a great solution, but there is a problem, 10bit is linear right? so it does not contain enough data for mid tone and shadow area, worse than 10bit log (not raw file), i think it should be recorded in log profile, not in post-production in MLVApp (data has already lost at that time), it should be done within the progress something like cmos data to 10 bit.
i think 10bit log profiled raw is the perfect solution, it can replace 14bit linear raw in most cases, 10bit linear raw has a obvious gap to 14bit linear, especially when grading mid tone an dark area, mid tone is so important!
Raw data is raw data. There's no "log" in raw. I think you have a reading to do. As Danne said, you can use 12-14bit if you need more dynamic range.
#216
Quote from: masc on September 28, 2019, 06:23:44 PM
But I would only use it with DNG, otherwise you just super-scale your compression artifacts.  ;D
Only true for lossy codecs. ProRes is technically lossy, but there's no visual artifacts, so I think it's fine too.
#217
Quote from: Dmytro_ua on September 28, 2019, 10:45:21 AM
What about Davinci?
DaVinci has a super-resolution algorithm. Better quality than Lanczos.
#218
Quote from: HHH456 on September 27, 2019, 10:43:44 PM
flat LUT later in editor?
This will probably create banding issues. Always apply Log-C first and then do other processing.

Quote
(Also, the same concept except upscaling in MLV vs. in editor?)
It depends on your editor's interpolation algorithm. MLVApp has some pretty good ones, like Lanczos. I suggest you do that on MLVApp too, as Premiere Pro only has bilinear/bicubic interpolation (which is worse than Lanczos).
#219
Quote from: Danne on September 26, 2019, 10:10:01 AM
Nice digging. Did you test these numbers and compiled, compared?

Tested now. Doesn't seem to have any difference at all ¯\_(ツ)_/¯
Where did you got the original matrix @Ilia3101 ?
#220
@Ilia3101 I think the Rec.709 matrix is wrong. According to the ACES github, the XYZ>Rec.709 matrix is this:
Quote
R_out =  3.2409699419 * R_in + -1.5373831776 * G_in + -0.4986107603 * B_in;
G_out = -0.9692436363 * R_in +  1.8759675015 * G_in +  0.0415550574 * B_in;
B_out =  0.0556300797 * R_in + -0.2039769589 * G_in +  1.0569715142 * B_in;
But on MLVAPP processing.c it is:
Quote
/* GAMUT_Rec709 */
         3.2404542, -1.5371385, -0.4985314,
        -0.9692660,  1.8760108,  0.0415560,
         0.0556434, -0.2040259,  1.0572252
Not sure which one is correct.

Also, I have a request. Can you add AP1 to the Gamuts? This seems to be the matrix:
Quote
R_out =  1.6410233797 * R_in + -0.3248032942 * G_in + -0.2364246952 * B_in;
G_out = -0.6636628587 * R_in +  1.6153315917 * G_in +  0.0167563477 * B_in;
B_out =  0.0117218943 * R_in + -0.0082844420 * G_in +  0.9883948585 * B_in;
#221
Nice find @masc and @Danne:
Quote
Piccante is a header-only C++11 open-source (MPL license v2.0) imaging library, specifically designed for High Dynamic Range (HDR) processing. Piccante is modular; this means new filters, algorithms, etc. can be added in a straightforward way to its core. Piccante is easy to use and to integrate in existing projects; to use Piccante you just need to include "piccante.hpp" in your project.
http://vcg.isti.cnr.it/piccante/index.php

Might be a better/faster solution than using ffmpeg blending...
#222
General Development / Re: Apertus MLV Format Discussion
September 25, 2019, 07:13:10 AM
I think these links might be of interest for you Ilia or someone from Apertus, so I'll just leave here just in case we come back to this discussion in the future.

"Adventures in Spectrometry" - by Roger Cicala:
https://www.lensrentals.com/blog/2018/03/a-geek-of-many-colors-adventures-in-spectrometry/

"Looking at Cine Lens Color Shifts Using Spectrometry" - by Roger Cicala:
https://wordpress.lensrentals.com/blog/2018/04/looking-at-cine-lens-color-shifts-using-spectrometry/

"The absolute sensitivity of digital colour cameras" (PDF):
https://www.osapublishing.org/oe/abstract.cfm?uri=oe-17-22-20211

Spectron:
Quote
Spectron - an open source project for measuring and obtaining digital devices spectral sensitivity curves
Initially this was conceived with the goal of constructing an automated device with an aid to accurately measure spectral sensitivity curves for digital camera sensors. The project has a broader use though and can be used to measure spectral sensitivity curves of various light sensitive sensors (not just camera sensors) - for example spectral sensitivity curves of photodiodes.
https://github.com/Alexey-Danilchenko/Spectron

Spectral Data Analysis:
https://github.com/brandondube/raynbow
http://brucelindbloom.com/SpectCalcSpreadsheets.html
#223
Quote from: DeafEyeJedi on September 24, 2019, 07:48:31 PM
Thanks for acknowledging this. However, does it matter which file type we can export the 3D LUT format as?

No difference, it will only generate platform specific formats (3dmesh, clut, .vf, .cube, etc). MLVApp only supports .cube format, so you can choose either "Adobe" or "DaVinci Resolve" (both will have the same result)...
#224
Danne, try a Log-C to Rec.709 LUT from Arri:
https://www.arri.com/en/learn-help/learn-help-camera-system/tools/lut-generator

Might be easier than doing a S-curve...
edit: you're clipping your shadows. This was already discussed on rawtherapee github.
But I agree with you:
QuoteMight be an idea to zeroe dark strength when a log is selected and maybe lower gamma accordingly?
#225
Beautiful images @zen_nudist !
Have anyone here tried a red filter (wratten number 23A) such as this one from Tiffen? I think this would give better results than any post production color correction. I have this filter, but I don't really do underwater images. Or a warm polarizer. Something like ExpoDisc for correct WB would also be nice.
The new "Haze Removal" tool on Rawtherapee might really help for photography. Maybe that's a nice tool to be implemented in MLVApp in the future.

This research seems cool too:
http://csms.haifa.ac.il/profiles/tTreibitz/datasets/sea_thru/index.html

Some python implementations here:
https://github.com/wangyanckxx/Single-Underwater-Image-Enhancement-and-Color-Restoration