Messages

Just a quick 'background' post for those using MUSIC: https://photography.grayheron.net/2021/01/le-photography-benifits-of-simulation.html

@a1ex

Thanks for confirming. For a while I thought I was going mad, then, last night, as I was in bed thinking about it, I wondered if the exposim or expo override was the issue.

May I assume the bug is registered now?

Cheers

Garry

@a1ex

I had a thought and just tested it out and now can trigger the error.

If only ExpSim is enabled all is OK.

If I also enable Expo Override, then the error occurs, ie I can't control ISO via Lua.

I don't under why this is occurring, but at least I can circumvent it by not playing around with ISO if I also need Expo Override!

Bugger: why doesn't the image show!!!!!!

Here is the link: https://ibb.co/G7FXWbF

Fixed 

@a1ex

I'm still nowhere with this ISO strangeness.

I have the latest Lua running on my 5D3 in M mode.

I have deleted all scripts bar this test script:

Code Select Expand

--ISO Test
t = camera.iso.value
menu.close()
sleep(1)
camera.iso.value = 800
display.notify_box("iso="..t, 3000)
sleep(3)
camera.iso.value = t

The script fails with this message:



Can you see the error of my ways?

Cheers

Garry

I'm pleased to announce that MUSIC now has an FRSP feature.

This post explains how MUSIC uses FRSP: https://photography.grayheron.net/2021/01/music-now-for-those-with-senstive.html

In the end I 'just' did a complete reinstall of the latest Lua_fix and all now seems OK.

As I say, strange.

Well I'm mystified, but that's easy :-)

Here is the point of failure, that generates the traceback error:

Code Select Expand

local iso_b = camera.iso.apex
local temp = camera.shutter.ms
local stop = MUSIC_menu.submenu["Number of images?"].value
if MUSIC_menu.submenu["Bookends?"].value == "yes" then stop = stop + 2 end
for i = 1,stop do
if (i == 1 or i == stop) and MUSIC_menu.submenu["Bookends?"].value == "yes" then -- tweak shutter and ISO for first and last images in bracket set
camera.shutter.ms = 1
camera.iso.apex = 10 --FAILS HERE!!!!!!!!
else
camera.iso.apex = iso_b
camera.shutter.ms = temp
end
my_shoot()
msleep(MUSIC_menu.submenu["I2I Delay"].value * 1000)
if MUSIC_menu.submenu["Focus shift mode"].value ~= "None"  then
check_lens_ready() -- just in case
lens.focus(dir,step,true) -- move lens
check_lens_ready() -- just in case
lens.focus(-dir,step,true) -- move back
end
end
camera.shutter.ms = temp
camera.iso.apex = iso_b
display.notify_box("Script Finished Running", 3000)
else -- something is wrong
display.notify_box("Switch on LV", 3000)
end

@a1ex

API test fails here:

Testing picture taking functions...
Snap simulation test...
Single picture...
A:/DCIM/103EOS5D/2P6A0508.CR2 not found.
A:/DCIM/103EOS5D/2P6A0508.JPG not found.

ML/SCRIPTS/API_TEST.LUA:1062: assertion failed!
stack traceback:
   [C]: in function 'assert'
   ML/SCRIPTS/API_TEST.LUA:1062: in function 'test_camera_take_pics'
   ML/SCRIPTS/API_TEST.LUA:1574: in function <ML/SCRIPTS/API_TEST.LUA:1564>
   [C]: in function 'xpcall'
   ML/SCRIPTS/API_TEST.LUA:1564: in function 'api_tests'
   ML/SCRIPTS/API_TEST.LUA:1603: in main chunk

Looks like one of my scripts is creating the problem :-(

If I only run API test all looks OK :-(

But which script I wonder?

Time to test!!!!

@a1ex

Using latest Lua fix on 5D3 123.

Shutter and aperture all OK.

Reading ISO is OK.

Just tried running the API test script and got error "Not enough memory" ?

I've convinced myself that setting ISO values via Lua 'may' be broken.

I can use camera.iso.apex or camera.iso.value etc to read, eg x = camera.iso.apex; but if I use something like camera.iso.apex = 10 I get 'failed stack traceback' error.

Has anyone else come across this?

@a1ex

Answered in reply #1086.

Sorry, I was trying to be specific to the opacity adjustment approach and using pairwise summation via (a+b)/2.

I'll stop posting on this now 

Cheers

Garry

@a1ex

Thanks for the education :-)

Do you think the idea, ie adjusting each image's opacity and summing is achievable?

Or is the idea dead on the starting block?

Cheers

Garry

@IDL@ML

How does the number of merged images relate to the number of ND stops with this simple (a+b)/2 median merging method? 

With this approach one is not trying to emulate the number of ND stops, but the shutter time. We use ND filters to control time. With this approach 'any' LE becomes a 'simple' matter of dialing in the number.

The number of images to take is know, ie if the LE time you are seeking to emulate it T and the shutter time is t, then the number of images yuo will need is simply T/t.

@a1ex

That's the arithmetic mean, and it's quite different from median.

My ignorance. I simply used this: https://www.mathsisfun.com/median.html, and because my idea is to only 'process' two images at a time, the maths becomes easy (a+b)/2.

I'm still thinking how we merge multiple stacks of images in Photoshop is the way to make this work.

In the PS merge multiple images approach, eg https://photography.grayheron.net/2018/04/post-processing-simulated-le-brackets.html, one adjust the opacity of each layer by an amount. Thus, in a four layer stack, the image opacity values for each layer would be (top to bottom), 1/4, 1/3, 1/2. 1/1. These layers are then simply merged, which in my naivety I thought was pairwise (a+b)/2.

Thus, if you have the first image taken in the 'image buffer', and the opacity is adjusted to 1/n, then the next images is 'median merge' into the image buffer having its opacity adjusted to 1/(n-1) first.

Once the final image is created in this way, it is read out as usual.

So the difference is, rather than the image buffer being purged each time, it is added to, with the captured image having had its opacity adjusted according to its position in the LE stack.

BTW this idea is better called LE simulation, rather than ND simulation. We are side stepping NDs :-)

@Greg (typo in name last time, sorry)

Fully understand 'your method', and doing things in post.

The in camera approach, which I'm sure I will be told is not feasible in the end on all cameras, but may work on some, eg 5D3b(?), has the advantage of creating a single image, ie in camera.

Thus, for a 1s exposure, aiming for, say, a 100s simulated ND capture, instead of 100 images on the card, you just have one.

@names_are_hard

The median merge function is 'simply' (a+b)/2, that is sum the pixel values and half the result. As to how one does it at the pixel level I don't know, but someone will 

Anyway, for now it's just a development marker.

Cheers

Garry

@Grey

Yes I know I can do that and use normal approaches to construct bracket sets for processing in post, eg https://photography.grayheron.net/2021/01/music-additional-notes.html

My suggestion is to do this in camera, ie before outputting the FRSP image.

A Thought/Idea

As we look forward to a 'resurgence' in ML development (fingers crossed and thanks to a1ex's tenacity) I would like to try out an idea, but first the usual caveat: forgive me if others have thought of this and/or tried it.

The idea is to create a pseudo ND feature using FRSP.

I say pseudo as it it will not behave like a true ND, but, with the right approach it should be pretty good.

I'm aware of a similar, frame averaging, feature in the XF IQ4, eg https://www.dtcommercialphoto.com/why-the-xf-iq4s-new-feature-update-makes-it-the-most-average-camera-in-the-world/

Then there is a slightly different approach in the OMD cameras, ie Livebulb.

If my understanding is correct, the current FRSP goes like this:

1. Enable the FRSP module and set shutter to between, say, 0.2 and 15s
2. Using the FRSP module take the FRSP
3. The FRSP module reads out the LV image into an 'image buffer', which takes about 200ms (say)
4. The FRSP module reads out a DNG to the card, which takes many seconds
5. You can now take another FRSP

My 'idea' is to ask the developers if we could implement the following:

1. Enable the FRSP module and set shutter to between, say, 1 and 10s (say). The module will check shutter times and provide feedback re acceptability
2. Using the FRSP module start taking the pseudo ND FRSP
3. The FRSP module reads out the 1st LV image into the 'image buffer', which takes about 200ms (say). This is a dead time in picture taking, which is why one needs the minimum shutter to be relatively long, eg 1-2s, say
4. The FRSP module now takes the next frame and the previous frame remains in the image buffer
5. Once the second frame is taken, the FRSP module merges the current frame into the image buffer, using a simple median statistic at each photosite
6. The FRSP module carries on doing steps 4 and 5 until the ND time is reached
7. The FRSP module reads out a DNG to the card, which takes many seconds
8. You can now take another FRSP or ND FRSP

Photographers will only need to carry a minimum number of NDs, ie sufficient to get into the 1-10s zone, from where the FRSP ND feature will allow them to 'dial in' longer ND times.

As I'm not a developer or fully understand C coding, I'm not sure how practical the above is. However, if it can be implemented, I believe it will give ML another killer (photography) feature, ie similar to the XF IQ4's frame averaging.

@ArcziPL

Thanks for the feedback.

Hopefully you will try DOFIS and MUSIC out and they will help you with your captures.

Cheers

Garry

MUSIC now covers people removal and ND simulation :-)

https://photography.grayheron.net/2021/01/music-additional-notes.html

@Kharak

Can you link me to some article explaining this practice?

No 

As I just thought it up. As I say, it may not work.

The jiggle is simply moving the lens from the point of focus to another point, and back again; ie the image is always taken at the same point of focus. I was hoping that engineering tolerances and mechanical imperfections in the lens MAY shift the image relative to the sensor each time.

The first approach, if you can, is to use handholding to achieve SR bracketing, which will guarantee image to image pixel shifts.

If jiggling doesn't work, you still have the noise reduction brackets ;-)

This 'new' MUSIC script is aimed at those interested in taking brackets sets.

This first release covers noise reduction and super resolution bracketing.

Future releases will cover, FRSP bracketing, Zero Noise bracketing, People Elimination bracketing, Hand Held bracketing and Long Exposure simulation bracketing.

You can read about MUSIC developments on my blog at https://photography.grayheron.net/

The latest MUSIC script is always here https://gist.github.com/pigeonhill/7b02d3dcadddbc703940778d74cd7af2?ts=4

LensSim is fully functioning and I would welcome others trying it out.

I wrote it for those that wish to understand their lens, based on knowing the focal length, the aperture, the focus distance from the sensor, the minimum focus distance, the magnification at the minimum focus and the pupil magnification. All fairly easy to obtain.

LensSim then allows you to see how your lens front and rear principal planes and entrance and exit pupils move as you focus.

Remembering that the entrance pupil is the location of the pano pivot point, and that towards the macro end of the lens, the pupil mag effects depth of field. Plus see lens breathing.

Finally, don't forget my DOFIS depth of field script, which allows you to capture perfect focus brackets and, if you wish, exposure brackets as well.

@Kevinrea

From my experience, shooting them in California and New Mexico, use dialled down flash and several of them, if you wish to freeze hummers' details.