looking for some dusk and dawn time lapse logs - page 2 - Script Writing - CHDK Forum supplierdeeply

looking for some dusk and dawn time lapse logs

  • 16 Replies
  • 459 Views
*

Offline Caefix

  • *****
  • 641
  • Sorry, busy deleting test shots...
Re: looking for some dusk and dawn time lapse logs
« Reply #10 on: 04 / November / 2021, 15:02:04 »
Advertisements
Tv + Av = Bv + Sv => Bv = Tv + Av - Sv
Note that the better (more sensitive / light gathering) a camera is, ...

S110 has more entries in it´s shooting.c´s ISO-table. ( && a typo).
Could eventually become a Xv in a calculation?  :)
Code: [Select]
    { 17,  3200,  "3200", -1},
    { 18,  4000,  "4000", -1},
    { 19,  5000,  "5000", -1},
    { 20,  6400,  "6400", -1},
    { 21,  8000,  "6400", -1},
    { 22, 10000, "10000", -1},
    { 23, 12800, "12800", -1},
Edit:  ;) ... The older the cam, the shorter the Iso-table.
« Last Edit: 04 / November / 2021, 16:20:30 by Caefix »
All lifetime is a loan from eternity.

*

Offline Mlapse

  • ****
  • 357
  • S95 S110
Re: looking for some dusk and dawn time lapse logs
« Reply #11 on: 04 / November / 2021, 15:18:37 »
thanks, that's helpfull in 2 ways, first the data, secondly showing me how flawed my question was.

naturally the modern sensor would reach 1 second at a lower bv value, sorry for even asking.

i am looking at the moment the cam is starting to use compensation and is going over 32 Bv steps per Tv step.
all cams i tried did that before they reach 1 second (1/5-0.8seconds)
I was wondering if there were cams where that moment would be much lower and i can already calculate with the values you gave that that must be true for the G7X.

I'm amending my original, crude but effective algoritm for long_exposure to something more elegant and effective.
i think i can solve a key flaw in the code with:

Code: [Select]
and get_tv96() > get_bv96()+get_sv96()-get_av96() then
to check if tv is getting compensated at lower Bv values, it looks so simple if i see it now.

already tried and the first test failed on different fronts, but the data it created was still informative.

« Last Edit: 04 / November / 2021, 15:41:40 by Mlapse »
frustration is a key ingredient in progress

*

Offline Caefix

  • *****
  • 641
  • Sorry, busy deleting test shots...
Re: looking for some dusk and dawn time lapse logs
« Reply #12 on: 04 / November / 2021, 15:50:11 »
Code: [Select]
and get_tv96() > get_bv96()+get_sv96()-get_av96() then
Seems same equation written different, probably never becomes true ...  :(
All lifetime is a loan from eternity.

*

Offline Mlapse

  • ****
  • 357
  • S95 S110
Re: looking for some dusk and dawn time lapse logs
« Reply #13 on: 04 / November / 2021, 16:07:07 »
i was looking for something that does come true on old cams, but it won't on models with quicker sensor or larger dynamic range.

i just don't know where new begins or what it includes.
maybe a modern 1/2.3 with large zoom and high f value still develops compensation before 1 second, but the code will become true at that moment.
so i might still like to know, but do not need to anymore for best results  :)
« Last Edit: 04 / November / 2021, 16:20:48 by Mlapse »
frustration is a key ingredient in progress


*

Offline reyalp

  • ******
  • 13439
Re: looking for some dusk and dawn time lapse logs
« Reply #14 on: 04 / November / 2021, 17:26:21 »
i am looking at the moment the cam is starting to use compensation and is going over 32 Bv steps per Tv step.
all cams i tried did that before they reach 1 second (1/5-0.8seconds)
Yes, it's probably not safe to assume Canon AE always uses "correct" exposure as defined by the APEX equation. Bv is nominally luminance of the scene, but Canon AE has various metering modes (usually Evaluative, Weighted Average, Spot) and it's not clear how the reported Bv relates to those (is it still the entire scene, or somehow derived from the metered area?), or what other factors Canon AE may take into account.

You should be able determine how far it is from "correct" directly using the APEX equation

(difference from correct exposure) = Tv + Av - Sv - Bv

Simply adding this value to the AE-derived Tv would get it back to "correct". If you want to transition from using Canon AE to using your own calculation, you'd probably want to blend them over some range to get a smooth transition.

Another point of caution: At very low light levels, the reported Bv loses precision and becomes unreliable. I don't recall specific values, but should be well after Canon AE starts using 1s.  To get good exposure calculations beyond this point, you should use rawop or shot histogram to derive it from raw values of an appropriately long exposure.
Bv is also presumably unreliable when significant parts of the scene are saturated or has no detectable signal.
Don't forget what the H stands for.

*

Offline Mlapse

  • ****
  • 357
  • S95 S110
Re: looking for some dusk and dawn time lapse logs
« Reply #15 on: 04 / November / 2021, 19:32:57 »
 i think in suix that low light problem is already fairly solved and i don't experience trouble like flickering when it is more than 1 second....i tested it up to 48 seconds.
but i wanted to minimize the differences between cams at 1 sec and for that i had to know or calculate the difference.

as you wrote, you want it to blend. and that's what i am testing the past couple of days.
« Last Edit: 04 / November / 2021, 19:52:06 by Mlapse »
frustration is a key ingredient in progress

*

Offline Mlapse

  • ****
  • 357
  • S95 S110
Re: looking for some dusk and dawn time lapse logs
« Reply #16 on: 06 / November / 2021, 16:32:27 »
Seems same equation written different, probably never becomes true ...  :(

well, strangely enough it always came true, but that's equally unusable.  :(

I was trying to automate finding the point where compensation started or how much it was at 0.8-1sec.
Any of the 2 would make it possible to recalculate Tv with fair accuracy.

But automatically missing that point has proven to be easy enough for it not to work reliable.
because a shot had to be taken at the right moment with a margin of only a few minutes.

I also tested straightening out the compensation, because then i did not have to know the exact point were CF starts to compensate.
and after straightening imposing my own compensation, but that would end up in a specific profile per sensor.
because 'one size fits all' just means it looks equally bad on all ;)

since i also have no idea how to store the automatically found value, i decided, for now, to add a manual setting for compensation in SUIx.

it was interesting though to investigate this and it possibly improved my coding skills, so nothing lost :)
and I have the data, so i might try this again when I have come up with a way of solving this.
« Last Edit: 07 / November / 2021, 05:04:45 by Mlapse »
frustration is a key ingredient in progress

 

Related Topics