Landscape focus bracketing without scripting - Creative Uses of CHDK - CHDK Forum
supplierdeeply

Landscape focus bracketing without scripting

  • 22 Replies
  • 1272 Views
Landscape focus bracketing without scripting
« on: 30 / December / 2018, 11:19:06 »
Advertisements
I just wrote a short piece on focus stacking that some may find of interest. As we know, there are two types of focus bracketing: macro and landscape. This post covers landscape focus bracketing.
The post is here: http://photography.grayheron.net/2018/12/some-thoughts-on-focus-bracketing-with.html
As usual I welcome any feedback.
Cheers
Garry

*

Online reyalp

  • ******
  • 12159
Re: Landscape focus bracketing without scripting
« Reply #1 on: 30 / December / 2018, 18:44:04 »
Nice.

Quote
The CHDK inbult depth of field and hyperfocal calculations appear to be based on an acceptable CoC that is far from optimal, ie about 30 microns x the G7X crop of 2.7: or about 11 microns.
Indeed, it's defined as 11 https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/platform/g7x/platform_camera.h#ln79

It could be defined differently, or we could allow user override the value used in the calculator. We could define it in terms of pixel pitch if we added a sensor size define ( annoying to add for all 150+ cameras, but available from specs)
Don't forget what the H stands for.

Re: Landscape focus bracketing without scripting
« Reply #2 on: 31 / December / 2018, 03:35:21 »
reylap
Thanks for the code pointer, I haven't looked at the trunk data before in CHDK. I did add in, with the help of a1ex, the DoF code into ML, including diffraction, but I'm not a C programmer ;-)
On my blog I have tried to discuss the value of understanding blurs as a way of controlling/setting DoF.
As you are aware, on the Powershot cameras, the useful blur zone in microns is from about 30xcrop to 2xsensor pitch. Also, apertures are limited compared to a full frame DSLR: so it's most probably not worth trying to enhanced the CHDK code with diffraction sensitive DoF math. Better to make users aware of the two main blur components, ie defocus blur, as built into CHDK, and diffraction blur.
As diffraction blur is 'flat' through the scene, some say that this can be accounted for in Photoshop etc. To some extent this is true. The defocus blur, however, is another story, as it varies through the scene. The chart I created here (http://photography.grayheron.net/2018/11/focus-tutorial-part-1.html) tells the story.
Although I think it would be useful to have an user input feature for the defocus blur, ie CoC; you don't really need it if you use the hyperfocal distance to control blur, as shown in the chart. That is, knowing that the g7X CoC is set at 11 microns, I can set it to half that by focusing at 2*H. In other words I can fully control the blur at infinity: assuming the Canon-CHDK distance reporting is 'accurate' and we know that Canon lens reporting is far from 'smooth' in the 'far field'.
Finally, I think the 4 bracket approach will give you a reasonable approach for landscapes. In fact, you could most probably just use three brackets, ie start at H/3 and use a distance offset of about H.

Bottom line: I think what we have is OK, recognizing we are playing around with a P&S camera ;-)

Re: Landscape focus bracketing without scripting
« Reply #3 on: 31 / December / 2018, 08:07:30 »
Reylap

I’ve had a thought regarding implementation of a non linear bracketing arrangement, based on the already implemented CHDK approach.; however I need a bit more info to refine my ideas. Also I don’t know where to look in the trunk code.

At the moment CHDK allows us to dial in a delta distance when focus bracketing. What I don’t know is whether this distance is simply used addatively, ie each refocus add that delta to the last position, or if it is used in an absolute sense, ie the nth bracket is (n-1)*delta from the initial focus point.

Can you, or anyone else, throw any light on this for me?

My idea is to simple provide an algorithmic delta option as well, to account for the landscape bracketing needs.

Cheers

Garry


*

Online reyalp

  • ******
  • 12159
Re: Landscape focus bracketing without scripting
« Reply #4 on: 31 / December / 2018, 14:55:59 »
The logic is in core/shooting.c shooting_subject_distance_bracketing
Don't forget what the H stands for.

Re: Landscape focus bracketing without scripting
« Reply #5 on: 31 / December / 2018, 16:54:00 »
Thanks. I’ll see what I can do.

Re: Landscape focus bracketing without scripting
« Reply #6 on: 31 / December / 2018, 19:10:21 »
Reyalp hope you can help. I’ve looked at the code and am beginning to reverse engineer it, but am struggling to understand this:

int shooting_get_lens_to_focal_plane_width()
{
    return (int)(lens_get_focus_pos()-lens_get_focus_pos_from_lens());
}

That is the difference or meaning between the two lens distances.

Hope you can educate me.

Cheers

Garry

*

Online reyalp

  • ******
  • 12159
Re: Landscape focus bracketing without scripting
« Reply #7 on: 31 / December / 2018, 22:59:02 »
That is the difference or meaning between the two lens distances.
lens_get_focus_pos  should be the distance from the sensor to the subject, while the  lens_get_focus_pos_from_lens should be from the lens to subject. See https://chdk.setepontos.com/index.php?topic=4529.msg43610#msg43610


Don't forget what the H stands for.


Re: Landscape focus bracketing without scripting
« Reply #8 on: 01 / January / 2019, 04:40:31 »
Got it: thanks.

Hopefully one final question, at least for now. 

In bracketing in continuous mode does CHDK know how many images the user has set?

For my ideas to work, I need to know how many images are going to be taken.

*

Online reyalp

  • ******
  • 12159
Re: Landscape focus bracketing without scripting
« Reply #9 on: 01 / January / 2019, 14:18:21 »
In bracketing in continuous mode does CHDK know how many images the user has set?
No. I suspect the time lords would get rather upset if we implemented precognition  :D

Less silly answer:
"Bracketing in continuous mode" works in continuous mode for as long as you hold the shutter down, so obviously the number is unknown in that case. (edit, oops, leaving out the un changes the meaning a bit :-[)

It also works in custom timer mode, in which case the number of shots should be available from propcase TIMER_SHOTS, but note that this propcase isn't defined in all propsets and isn't currently used in CHDK. It could probably be added.

If you want to handle this, I'd suggest something like
if in customer timer mode, use timer shots
otherwise, assume some reasonable number (3 or 4?) and stop bracketing after those are done.

somewhat related: CAM_DRIVE_MODE_FROM_TIMER_MODE is set on most except very early ones. This means that custom timer will always be treated as continuous mode. I haven't tested, but I suspect older cameras would just check the normal drive mode setting.
« Last Edit: 01 / January / 2019, 16:31:46 by reyalp »
Don't forget what the H stands for.

 

Related Topics