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 - 70MM13

Pages: 1 ... 18 19 [20] 21 22
476
Fresh identical settings comparison of 10 and 14 bit versions...

The brightness difference is not my doing.
Interestingly, there's more aliasing in the 14 bit version.  Look closely at the modulation lever on the keyboard in the background.






477
Here's the two latest 10 bit versions stress



tested at 22fps override:

V2 definitely has less stripes.  Precisely the same settings and conditions, straight from mlvapp.

478
Good luck!
I hope you succeed, I'm starting to like this!

480
I tried the new version and it's the same.

I hope you can solve this!

Simple test: expose for a light bulb in a dimly lit room just like the scene I did.  You'll know right away!

481
The new version fixed the interlacing issue, but the vertical stripes are very strong, especially if underexposing for highlights.

I did many exposures of this test scene, and even when I exposed exactly for midtones, the stripes are visible on the wall well into the mids...

As for dynamic range, it doesn't beat the ISO experiments yet.  Pretty much the same.

But, if you can eliminate the stripes, it could be a winner!

I still dream of both combined.

The following images are straight from mlvapp with no processing except exposure and shadow strength to match.  No noise reduction nor chroma smoothing applied.

The ISO 109 was shot at 3K and exported at 1080.  BTW, the 3K footage uses less data...

Different framing due to different crop sizes.




482
It was the shutter speed.  Seems like it was somehow set in your version.

Once I set it to 50 in the ml exposure menu, the problem disappeared!

For some reason, when I set FPS override, the camera crashed hard. Display stays on even with the battery door open.  Battery has to be pulled.

This version provides very nice results!  Maybe better than ISO experiments!

I'll do a comparison with this.

EDIT: I can't repeat this.  It must have been a stray neutrino.  But the hard crashing is definitely repeatable :p

483


Much better!

But something strange is happening now.  When I load a clip from the "less stripes" version into mlvapp, as soon as I switch to anything except bilinear demosaicing, the brights lose the dual ISO processing.

I checked by reverting to the prior version and it's fine.

I'm using the 14 bit version.

484
I tried your 14 bit version and it works very well.  Straightforward and easy!

Unfortunately (or fortunately, depending on your point of view) it doesn't seem to provide any benefits compared to the ISO experiments, for me at least...

I will keep watching and playing with any new developments you make, and hopefully you will work some magic!

I think that dual ISO combined with the ISO experiments is the way to get truly incredible results...

If only more people were playing with the ISO experiments, maybe this could happen.

I'll try some more tests with your 14 bit version and see if it beats the ISO experiments in some cases.  The shadows are just so clean in the ISO experiments...

I hope you don't think I'm discouraging you.  Quite the opposite!  Keep up the amazing work!

485
What an excellent idea!

This would be amazing for interesting effects!

If you already captured all this data, it's best to keep it, i.e. rather than exporting one frame out of 25, I believe it's better to average all of them in a way that minimizes temporal aliasing.

Somewhat like this: http://tessive.com/the-time-filter

I have yet to experiment with this, but any of these should give much better results than keeping just one frame out of 25:
- 180-degree averaging (i.e. average half of the frames in each group)
- use variable weights when averaging, such as a Gaussian bell curve

e.g.

- 180-degree averaging: weights = [  0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 ] / 13  # i.e. average 13 frames out of 25
- "Gaussian" weighting (just an example): [ 0.001 0.002 0.004 0.008 0.014 0.023 0.034 0.047 0.061 0.075 0.087 0.095 0.098 0.095 0.087 0.075 0.061 0.047 0.034 0.023 0.014 0.008 0.004 0.002 0.001 ]



To get the above "Gaussian" weights in octave:
Code: [Select]
w0 = [  0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 ] / 5;
w1 = conv(w0,w0)(25-12:25+12);
w2 = conv(w1,w1)(25-12:25+12);
w3 = conv(w2,w2)(25-12:25+12);
printf("%.3f ", w3);

Of course, the processing time will be much higher.

I hope to be able to perform this kind averaging on the camera's image processor at some point...

486
@70MM13

 8) Cool!

It's nothing short of amazing, what we can do with these old cameras thanks to the efforts of the magic lantern community.

It just keeps getting better!

Exciting times.

487
Here's a sample frame from a test shoot for an upcoming video I'm working on.

It is straight from mlvapp, showing that you can indeed do excellent grading with mlvapp.

I'm using the ISO experiments with my 5D3, dropping ISO 200 to 109.  No dual ISO used.  The foreground is full shadow, and the background is all full sun.  Beautiful dynamic range.

Mlvapp rocks!


488
WOW!!!!
Thank you so much!
You rock.

489
I'm sure there are plenty of people like myself with great appreciation for mlvapp!

Yes, resolve can do more for very poor footage, but it's a different beast altogether.

Mlvapp is GREAT.  I have no problems getting fantastic results with it!

Keep up the amazing work!

Many thanks!

490
No worries on the jpeg 2000...  It was just hopeful thinking.

Multiple slots for receipts would be far more important!!!

Thanks!

491
I'm amazed at the results obtainable with mlvapp's elegant and uncluttered controls!

One thing that would come in really handy is being able to store and retrieve receipts quickly from ram with keyboard shortcuts, similar to resolve's "memories".  They use the number keys, plus alt to store or Ctrl to load.

Something like this would be excellent for powerful workflow on grading clips.

Also, any chance of high colour depth jpeg 2000 MOV export?  It is a very nice format in resolve, and maybe it would work well with mlvapp!

Mlvapp is an awesome program!

492
It makes sense...  I can't see any degradation on the 16 bit tiff, so perhaps faststone is just incorrect.

Maybe there's another way to get a clearer answer...  Perhaps gimp has a similar colour count function.

PS: gimp has a colour count function, and according to it, everything is fine!

Test image was approximately 94,000 colours in the 8 bit PNG export, and 101,000 in 16 bit tiff.

In case anyone is interested in the function, it's under colours/info/colourcube analysis

Thanks for the help!

493
I use faststone image viewer to count the colours.  Ctrl-shift-T

Yes, the example values I gave are fairly low, but the scene I'm working on is extremely low light!

Congratulations on the new version!  Keep up the amazing work!

I hope you can solve my mystery!

@70mm13: very interesting. How do you count the colours? The frames are exported in very different ways:
- 8bit: internally convert 16 to 8 bits, use Qt library to save 8bit PNG
- 16bit: directly stream the (processed) rawdata (internally 16bit) to ffmpeg which saves the 16bit TIFF
So if your values are right, there should be a problem with ffmpeg (or our ffmpeg call).
BTW: only 100.000 colours? (3x)8bit has already 16.000.000!

494
I'm really enjoying working with mlvapp, and getting great results from the tests I'm doing.

Something strange I've found, however...

When I export as 16 bit tiff, I'm getting fewer colours than "save an actual frame" as an 8 bit PNG.

On the order of 110,000 vs 98,000.

I'd expect the opposite!

Looking at the tiff file, it says it's 48 bit, so there's a bit of a mystery here...

495
Reverse Engineering / Re: CMOS/ADTG/Digic register investigation on ISO
« on: August 24, 2018, 07:45:18 PM »
Here's a sample frame of the results I'm getting with my current settings, emphasis on highlights and maximum dynamic range.

Based on ISO 200.

It's working well in every scenario so far, from screaming sunlight to dark scenes.


496
Reverse Engineering / Re: CMOS/ADTG/Digic register investigation on ISO
« on: August 03, 2018, 01:19:16 PM »
I find this functionality essential to my work, even though I only use the parameters on the ISO registers GUI.  I'm getting great results from using those, even if it could be better (what couldn't?)

That being said, it's extremely tedious and sometimes very frustrating to change the base ISO and redo the whole process just to be able to get a shot under much different lighting conditions.

All I ask is for information on any possible way to store and retrieve settings for faster setup in use.

Is it possible?

The ideal under current (and seemingly for years to come) circumstances would be "ISO presets" from the GUI, perhaps with the ability to provide a name for each to avoid confusion in the field.

I'm just asking for information.

Please keep it friendly.

497
Reverse Engineering / Re: CMOS/ADTG/Digic register investigation on ISO
« on: August 01, 2018, 12:59:15 AM »
ISO 74 is the lowest I get while keeping the full range without losing highlights.

It's a pleasure to work with when there's lots of light.

My preference is for darker scenes, but the more I'm tinkering with the experimental ISO, the more comfortable I'm getting with a wider variety of conditions...

This frame was saved from mlvapp, in standard mode, no lut, no filters, no noise reduction, etc.  Simple exposure adjustment and low strength to raise the shadows a touch.

Looks good to me!


498
Inspired by this discussion, I have been testing ISO 320 pulled down to 100.

I tried a few other Isos as well and found that 320 is excellent for the cleanest shadows and only a very small loss of highlights in actual usage.

The highlights clip straight to pink, making it very easy to expose exactly at the threshold, and the beautiful shadows are a joy to work with. In the example frame, I exposed for the direct sunlight on the wall. The room was dark otherwise.



I'm using 320 a lot now, except those times I need as much highlight detail as possible at the expense of slightly noisier shadows.  Then it's back to 200!

Excellent stuff.

499
with mlv app's new capabilities, i tried processing this video using only it!

it handled everything except a couple of shots that needed features (currently?) unavailable on it.

i used hyalinejim's excellent magic lantern ektar LUT that he made intended for resolve.  i simply pointed mlv app to the directory with his .cube files, and used slog3.  it worked beautifully!  try it!

thanks to the iso experiments, the shadows are so clean that no noise reduction was required.

when will this capability be available for everyone?

http://drive.google.com/open?id=1OLyW3iQqRa6KgVnc6bg3yKdUA7ktP_Kv

500
My understanding from rawtherapee is that lmmse is primarily for very high ISO shots.  I've never really found it too useful, but who knows, it might work for certain conditions...

Thx for the clips. I found the problem very fast: the problem is that these files are <1.0fps. MLVApp was not made for clips with so low fps ... at least I forgot that it might be possible ;)
I made a quickfix - that means: if the clip is <1fps, I set it to 1 fps. Otherwise it is very hard to show a correct timecode... (timecode was the crashing module). So you can compile the latest revision using Dannes compiler tool, or you wait for next release. ;)
1) You really would do this in MLVApp? I always do it in the NLE - each pixel might be good for stabilizing for example... after this I crop it if necessary.
2) That should be possible to add... let's see... but you'll get a very blurred image.

I found an implementation of LMMSE debayer with correct interface in C, so I added it to MLVApp now. Has someone used it in past in any other program? I have the problem that hard contrast lines are getting very green and cyan. Is that normal? Only highiso clips are okay... but AMaZE looks nearly always way better.

Pages: 1 ... 18 19 [20] 21 22