Closed GoogleCodeExporter closed 9 years ago
Gheez, if this is the best I can do for a feature request / enhancement then
the current 400plus hack must be pretty steenkin' excellent already!
Original comment by mike.guf...@gmail.com
on 3 Jun 2011 at 2:39
My two cents:
When taking one single photograph, selecting the right exposure is critical; in
this situation, having a granularity of 1/2 or 1/3 EV makes perfect sense to me
(I have my camera configured for 1/3 EV, as 1/2 EV looks "too big" for me, but
this is a personal preference).
But when you are going to do multiple exposures (with the intention of
combining them later), I feel that having a precision of 1 EV is perfectly
adequate; after all, none of the exposures is supposed to be correct, that is
we are using HDR. And if you feel that the limits of your series do not match
your needs, you can always add another exposure. I prefer not to have too many
values there, to be able to change quickly from one value to another.
However, all this is just my point of view... Adding more intermediate values
is quite easy; if there is a real need for them, I will do it. But we will also
need to decide about the separation between shots (it is fixed at 1EV now,
should it be configurable, too?), and what happens when the max value does not
match the min value plus a multiple of the separation (like min=1/100,
max=1/1500, sep=1EV).
Original comment by eduardo....@gmail.com
on 3 Jun 2011 at 11:56
Thanks for your thoughts on this. I hope others will chime in also.
My .02 = your .02 as far as Extended Bracketing features as they exist now for
the purpose of HDR. We have more than enough capability now in 400plus to do
what we need for great HDR.
I was not even thinking HDR when I wrote this request but rather the idea of
using the Intervalometer script along with the Extended Bracketing script to
have the opportunity to take as many exposures as you want at whatever exposure
length you want from the exposure values that are normally offered from your
camera the way it was currently configured.
Similar to what was posted on the forums by "repeater" at:
http://chdk.setepontos.com/index.php?topic=3290.msg67723#msg67723
In his scenario it could(?) be valuable to be able to offer whatever the camera
normally offers for exposure times based on the C.Fn 6 settings, along with the
values chosen for the 400plus script settings.
But... is what we have now not adequate and valuable enough for most people?
This I don't know and thus I posted this feature request to get some feedback
from you guys and others. Maybe a better choice would have been to make this a
forum post. Keep in mind also that I am testing the builds regularly in
probably way more detail than most with the goal of trying to help perfect this
very nice piece of software.
Yes, more code validation would be required to ensure that script settings are
valid (min, max, EV selected, etc.). If the 400plus settings script values
available to choose from were driven based on what the camera C.Fn 6 is
configured to (yes, more code again...) then maybe it would be a little bit
simpler? Hmmm, do I see another shortcut here for quick access to C.Fn 6
"Exposure level increments"?
Let's keep this going, we can always close it out as "Won't Fix" or "Postpone"
if not enough interest or too difficult to take on at the moment. I still like
the idea, but I'm not writing the code :), just using it.
Original comment by mike.guf...@gmail.com
on 3 Jun 2011 at 3:54
But... that EAEB with max = min is just a dirty trick to use the intervalometer
for long exposures (> 30s); for short exposures, users can just use the
intervalometer and fire the camera normally, using whatever parameters they may
need (and that includes any shutter speed available).
I already had plans to add long exposures out of EAEB, and these will not have
the limitation of 1EV step; I am thinking now that we must allow users to fire
those long exposures from the intervalometer. Probably this will cover all
cases, but I am willing to be proven wrong.
PS: Your comments constitute an invaluable contribution to this project;
please, keep them coming!
Original comment by eduardo....@gmail.com
on 3 Jun 2011 at 8:12
This issue was closed by revision r1140.
Original comment by eduardo....@gmail.com
on 19 Mar 2012 at 9:50
Original issue reported on code.google.com by
mike.guf...@gmail.com
on 3 Jun 2011 at 2:36