Messages

Omg I lovve you! Great samplels plus I really wanted an ACR comparison. Great to see where we are both at. Soon MLV App will be destroying camera raw in this comparison.

Very nice clip!!! It even has some violet going on in the foreground! Thank you

Oh yes cyan is useful too, thanks for finding that one again.

Still looking for blue/violet samples, especially with blue and violet at the same time

Does anyone have a raw video or photo with blue/violet light that clips in an ugly way when you process it with MLV App or any other software? If you do, I would like to see the file. Any camera make/model will do, preferably large sensor tho.

something that looks like one of these:
https://www.youtube.com/watch?v=1hFBnAGahFM
https://www.youtube.com/watch?v=szxmH09mhsQ
https://www.youtube.com/watch?v=4QYBglZy4jk
https://www.youtube.com/watch?v=ntLlU6U2-zM

And if you have clipping colours other than blue/violet, that would be useful to see as well.

Thank y9ouu!!!

It will need to use the xyY colour model, as it has no limits, that's about all I know so far. This also has the potential to make MLV App really slow, so it needs to be done carefully, maybe with some 2d lookup tables in xy space. I have a nice .c file where I am experimenting with ways to do it. I will share it soon, it's just a bit messy right now.

What exactly does this mean? Bright blue/violet will bring slightly strange colors? Or does this show our problem with cyan tones at WB <4000K?

I think it shows both problems.

On the last picture, the intense cyan tones are appearing, very close to neutral cool white tones. We need to desaturate colours with high luminance, and blue/violet shades always need to be desaturated. Doing those things will fix all problems.

This all needs to be done around the same stage as matrix and tonemapping. It will be difficult to do, but it is the next big MLV App improvement.

Happy new year everyone!

Thanks for the very useful advice on archiving @2blackbar @cmh @IDA_ML @yokashin @Ottoga. It was so nice to read. I think I'll get a big SSD just for copying stuff until it gets close to full. And then I will use the M DISCs for more permanent storage, after reading about it I realise they are amazing. I don't like the idea of tape with the stretching. Cloud is also an interesting thing I've never really considered.

Please watch carefully!  In MLVApp v. 1.10, the "Transcode and Import" option is the 9-th from top in the File menu.

Can we rename it to "Transcode and Import non-MLV Raw" so it is more noticable?

Gotchya! Wow, I wonder how they got away with actually calling it RAW. Anyway, thanks for the awesome work you guys do with MLV App. It has really, really improved over time thanks to the team/developers like yourself. As a further possibility for MLV App, perhaps a Rec 709 Luma Waveform to adjust exposure more accurately..just a suggestion. Cheers and a Happy New Year!

Blackmagic say it's partially debayered, but megapolis (fastcinemadng guy on this forum) found a way to decode it, finding that it's not really partially debayered. It's probably a way of speaking to avoid being sued by rEd. Eventually a open source way to decode it will be created (I hope).

I can also confirm that MLVApp is now so mature and powerful that I am absolutely certain that this is the best RAW processing tool that is available worldwide, at least to my knowledge.  I have been using it not only for video but also for photo (with raw2mlv) lately and I get better results compared to ACR on a regular basis.  Moreover, there are two functions that are of crucial importance to my workflow and are not available in ACR:

1)  Dual ISO that I use quite a lot for landscape work and
2)  Skin tone white balance that solves the natural skin tone problem on a mouse click.

My workflow is now entirely based on MLVApp and all this I owe to the genious work and skills of our developers.  Thank you, guys and keep up this fantastic work also in the New Year and the years to come.

Thank you IDA_ML this is really nice to hear. I agree in some ways. But we still need to sort out camera colour conversion, it's too basic right now.

I have been analyzing the processing a bit more. The whole colour gamut converted with MLV App processing (Y=0.15, Y=0.5, Y=1.0):

They are all supposed to be very even and smooth, but they are not, especially in the blue/violet region. Once it looks smooth, MLV App will be perfect (at least for colours).

And who recognises that light blue colour on the third one

Does anyone know good data recovery companies in the UK? I am scared of getting a shitty one, seems there is a lot of scams.

I recommend Blu-Ray M discs portable writer to store Your data on bluray 25GB M-Discs , theyre one of the most reliable archival method with strong laser and data burned physically that lasts about 1000 years which sounds corny but ill take it, ive seen some tests results, other methods are more expensive like LTO tape to archive hard drives.I mean LTO is not THAT expensive, just a bit more expensive, I might switch to it in near future.

I always heard that blu ray is propreitary technology full of DRM. Does that apply to these discs in any way? I mainly need it to work with Linux. 1000 years sounds wonderful. I need to store my files at least that long.

Also I'm going to invest in a 4TB SSD and boycott hard drives.

[AND]

Those are just facts of life. You can't have a camera this cinamatic AND playback.

Think about film cameras:
1. You can't play back what you shot until you process it
2. You can't format film

As the turnaround time for approving new posts is approaching 2 (two) months, it's probably a sign the current moderators may need some more help. Any new volunteers?

Two months! Sure I could help out.

How does one investigate a message?

wtf! I go to the effort of only embedding the image in my posts without wacky ibb links or javascript, but even my images are hidden, I think they went a bit too far with blocking it. Might as well block all images hosted on amazon or google servers.

The forum used to have an "add image" thing that went to imgbb, can that be added back but with some other upload site?

On macOS and linux file name handling is just UTF8 (compatible with char *) so no problems here?

Hm... but this means having all filename and file interaction standard C code twice inside the processing part of the app.

I think it would only require using a special wchar_t version of fopen on windows, everything else can stay the same. Glad libMLV won't be opening files directly


Sorry been inactive for a bit. Mourning the loss of my hard drive with a lot of recent raw videos. Fuck hard drives.

As MLV App's processing limit when averaging is currently 128 frames, I've added in some feedback to tell you what the estimated number of frames in your LE MLV clip will be.

Isn't there a way to average a whole MLV in to a new single frame MLV? Then process that...

Amazing!!!

I know this is not strictly ML related, but I am glad you came here. This forum is a great place for open source image processing.

Very good! I will make an MSYS2 build folder. Would this work with minGW/cygwin too?

@Ilia3101 Thanks for testing! There's actually some very useful info in that 13min vid – I'd persevere to the end!

Ok I'll watcgh it later.

Also, it seems we are up against the limit of the accuracy of the exposure tools in ML. In the 'clipped' version the histo was telling me -0.2EV to clip! So it gets really hard to judge absolute clipping.

"Clipping" in my opinion is when a channel reaches the raw white level, which with your tweaks is lower, so the zebras think it hasn't clipped, when it actually has.

Highlights are very slightly clipped, but so they are on the iso-200-orig shot! In fact I left that Over a tad just to address this point.

Maybe they are clipped in iso-200-orig, but much less than iso-200-regs, when you compare them, iso-200-orig clearly has more of the original bulb colour still left.

[Iso 200 regs]

I'd say that the lower isos here have (as expected) much more dynamic range, and that all things considered where the reg tweak is applied, have a better quality of shadow noise – less 'glow', and more akin to film grain.

Iso 200 regs


Iso 200 orig

Shadows are better in the "Iso 200 regs", but highlights are more clipped, so it just looks like 1 stop higher exposure to me (or 0.99 as the sliders say). I would like to see it so that the lamp is clipped to the exact same degree in both shots, then compare shadows.

I tried the -44 and -4 register values, canon menu at iso 100, looks like having tweaks reduced overall exposure, but couldn't tell a difference in shadow noise, so maybe the tweaked registers were better but I can't say. Don't want to watch 13 minute tutorial in full, so I don't know.

I was hoping to match both shots in camera so that equal amount of highlights would be clipped (by fine tuning shutter speed), then compare shadow noise, but unfortunately raw zebras do not work with the tweak so I couldn't do that.

(I have no agenda but to get less shadow noise )

This time I used Adobe RGB Gamut and Tonemapping is set to None (don't remember why    )

Ah well this is the main problem. Nothing in the world is better than the Reinhard function.

Looks clean. I actually want to try it out after seeing you posting so much. How do I start? is it compatible with Danne's latest 5D3 builds?

Thanks. You don't need all of Visual Studio, only the "Build Tools for Visual Studio" - I think this is the one: https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2019

I think it's still a few GB. I don't know how to solve windows for you.

I said some time ago, somewhere, to someone (I think @Luther) that MLV App's tint slider is not very good because it is done in final colour gamut -  I was mistaken. It is actually done at the very start, on camera RGB channels. So it is fine, rawtherapee even does all white balance that way, so doing a little part is not harmful. Also I did spend about an hour messing with the white balance function, so this could change soon.


As for the icon. I am thinking, soon will have an answer,.

[All metadata required for correctly decoding any given MLV, will come before its VIDF block.]

Can I consider this a rule of the MLV format:

All metadata required for correctly decoding any given MLV, will come before its VIDF block.

Metadata such as: image parameters/resolution, compression, bitdepth, camera info, camera settings, and aspect ratio (if required, anamorphic modes for example).

The following suggests it may be:

as a consequence, we can start with the minimal subset (file header, raw info and then video frames)

If this is a rule, single frame previews can be fast and safe to do. All MLVs I look at seem to follow this rule, but I only looked at MLVs from 3 cameras with new builds.

Also putting this link here as I keep losing it: https://www.magiclantern.fm/forum/index.php?topic=7122.0

won't do that again

Exactly my feelings (and why I don't feel any rush to get back to coding).

It's probably my fault for spoiling the community with so much free stuff over the years...

I'm very gratufeul for and amazed by what you have done over the years, but you are right.

Also...

- a1ex made clear legal advice is paramount. Potential showstopper.

Working on it.

I still think of this post every now and then, do you have any updates on this?

(I don't want to restart that thread for no reason, so I thought I'd ask here to attract less attention)