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.

Messages - Luther

Pages: [1] 2 3 ... 6
Share Your Videos / Re: EOS M, hike day
« on: Yesterday at 06:49:14 AM »
Nice colors in 02m43s. Too much contrast (maybe some highlight compression/rolloff), but it's great. Are you using wide gamut on mlvapp?
Nice shots @ngemu!

Where did all this noise came from? Damn. Did you exposed right? Also, you did any pushing in mlvapp?
1/4 Black pro mist
Have been looking to buy one of these for years now. Seem like a great filter for indoor shooting and portraits.

Oh boy, you're going to have a hard time trying to replicate 70mm Kodak Vision3. That's the dream digital cameras have been pursuing since the beginning.
But, your color palette is surprisingly close. I also like the film grain in there (even though youtube compression fucked it).
Have anyone tried those Cinegrain LUTs yet? They seem neat for film emulation.
I prefer them over my Contax Zeiss (But don't tell anyone ;D).
How dare you said that, Zeiss Planar best lens ever!1!11!! :P

Beautifully rendered @Luther and the contrast looks amazing especially coming from a 50 year old glass... :)
Thanks. Some pixel pipping using mlvapp always helps the low contrast of the lens :p
Maybe I will do a video test, got inspired by what @york824 did.

Share Your Videos / Re: 5D2 2.7K footage, Guangdong China.
« on: October 20, 2019, 03:42:16 PM »
Beautiful @york824! Really liked it. Also, great music choices.

I added ACES AP1 as additional processing gamut to our repository. Thank you.
Nice, thanks @masc!

Handbrake won't encode huge resolutions with nvenc h.264 either btw.
I was talking about CRF values.
-crf replaced by -cq but the quality is different between -crf 18 and -cq 18, need further testing
-qp also works for me. Normally the value ~23 works well for 1080p.

Post-processing Workflow / Re: fastcinemadng
« on: October 19, 2019, 02:00:48 AM »
got a response today:
Heh, they have no clue what "open" means. This is why you can't let marketing guys take care of technical terms.
Blackmagic RAW is defined as an Open Standard because it is cross-platform and open for anybody to include in their products/develop with using our free SDK.

As for Luther's suggestion, he's probably thinking of a simple slider for Constant Quality RF. No parsing required.
Yes, like HandBrake does.

One frame from the tests. Quite nice, considering the lens I'm using is 50 years old :) Also, the iso is 200, there's some noise. Processed with MLVApp.

Click for full-res.

Commandline is no good idea. One single wrong or unexpected symbol brings the whole thing to crash. If you like other options, you could change the numbers in source code and compile. This is the simplest, fastest and safest way to get what you want.
Changing parameter elements dynamically in dependency to codec is extremely overkill IMO.

And who said anything about command line imput? I agree that parsing can go wrong, but the first suggestion I agreed was to add a Qt box to select some common options in h.264. No parsing issues, it's just hardcoded. Particularly the CRF value (from ~18 to ~34) and the Preset option (from 'fast' to 'slow') would be useful. Also, for h.264, ffmpeg has NVENC, which speeds up the encoding using GPU...

I don't even use H.264 while on MLVApp, I export in ProRes. But, these options would be nice for people that want faster exporting times or just a highly-compressed preview of some scene (a "daily", as some people call it).

see here
Wow. That seems good.
Got some pink frames while testing again today with 50D, but nothing too bad. It's working nicely with in 2560x1072px 10-bit.

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

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.
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.
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):
Code: [Select]
 * 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 );

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).

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.

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

Code: [Select]
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!

Share Your Videos / Re: nature video using resolve CST and iso 111
« on: October 15, 2019, 02:11:54 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 :)

General Development Discussion / Re: The MLV format
« on: October 15, 2019, 02:09:44 AM »
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.

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?

@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:
Code: [Select]
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt601:out_color_matrix=bt709%2%3 " ) Instead of bt2020?
Code: [Select]
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:
Code: [Select]
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...

General Development Discussion / Re: The MLV format
« on: 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).

Yeah, too much artificial sharpen, aliasing, contrast and saturation. Also, the shutter speed is too fast.
I 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.

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).

Camera-specific discussion / Re: Canon EOS M
« on: October 05, 2019, 05:45:39 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.

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

ps: This is not a place for self-promotion.

Camera-specific discussion / Re: Canon EOS M
« on: October 05, 2019, 01:10:00 PM »
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.

Hey @reddeercity , thanks for coming back to work on 50D. I will test later your build and report any issues.

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

Pages: [1] 2 3 ... 6