making sense of tv values - Script Writing - CHDK Forum  
« previous next »
Pages: [1] 2   Go Down

making sense of tv values

  • 13 Replies
  • 11454 Views
*

Offline mattkime

  • ****
  • 299
making sense of tv values
« on: 19 / February / 2009, 23:54:33 »
Advertisements
is there any documentation on the site regarding how tv and tv96 values work? i'm completely baffled by them.

in particular, i'm trying to make sense of fbonomi's code below -

Code: [Select]
function sec_to_tv96(sec)
  local sec=sec
 
  local tv96=0
 
  sec=check_range(sec,1,65)
 
   
  local sec1000=sec*1000
  local countsec=1000
 
  while countsec<sec1000 do
   countsec=(countsec*1091)/1000
   tv96=tv96-12
  end
 
  return tv96
 end

the loop....throws me for a loop.
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: making sense of tv values
« Reply #1 on: 20 / February / 2009, 03:18:13 »
The loop is approximating the seconds -> tv96 conversion because floats aren't available as said in fbonomi's comment to the function:
 -- convert seconds to APPROXIMATE tv96 values
 -- in: only whole seconds, in range 1 to 65
 -- out: approximate tv96 value (calculated with integer math in steps of 12)

All the *96 values are integers, where each step of 96 in the value of such variable equals one exposure value step. In case of tv96 this means doubling (subtract 96 from tv96) or halving (add 96 to tv96) exposure time. See http://en.wikipedia.org/wiki/Exposure_value.

These variables known to CHDK come from the camera's propcases, tv96 happens to be centered around 0 at exposure of 1 seconds. Longest exposures are negative.
Logged
*

Offline fbonomi

  • ****
  • 469
  • A570IS SD1100/Ixus80
    • Francesco Bonomi
Re: making sense of tv values
« Reply #2 on: 20 / February / 2009, 06:56:55 »
TV96 is just TV expressed in 96ths (Internally the camera uses TV96 instead of TV so that fractional TVs are possible without floating point Math)

TV96=TV*96

To convert to seconds, remember that:
1) Tv 0 is equivalent to 1 second
2) Increasing TV by 1 halves the shutter time.

Tv     sec
0   1
1   0.5
2   0.25

and vice-versa
Tv     sec
0   1
-1   2
-2   4


If you have floating point math you can do:

ShutterTime = 2^-TV

Or

ShutterTime = 2^-(TV96 / 96)

My loop is a trick to approximate this with integer math.

First consideration: instead of working in 1/96th of Tv, I approximate and work in 1/8th of Tv.

Second consideration: 1.091 ^ 8 = 2  (MAGIC NUMBER!!)

Third consideration: countsec is expressed in 1/1000th of seconds (again, to simulate decimals with integer math)

My code just starts at TV 0 and shutter time of 1 second, then increases Tv in steps of 1/8th every time multiplying shutter time by 1.091, until the Tv gets to your Tv.

In that moment countsec will have the approximate equivalent of your Tv in 1/1000th of a second
commented snppet.

-- Start at Tv 0
  local tv96=0
 
-- The time i want to convert, expressed in milliseconds   
  local sec1000=sec*1000

-- my "counter", in milleseconds. Start from 1 second
  local countsec=1000
 
-- loop until countsec gets to the time I wanted to convert
  while countsec<sec1000 do

-- every time multimplying countsec by 1.091
   countsec=(countsec*1091)/1000

-- and increasing my Tv of 1/8th of a Tv
   tv96=tv96-12

  end
 
-- After looping, tv will have our time converted
  return tv96
 end

Think about the table above:

Tv     sec
0   1
-1   2
-2   4

But we work in tv/96 and sec/1000
Tv     sec
0   1000
-96   2000
-192   4000

My program iteratively goes through a similar table, only instead of doing
tv96=tv96-96
countsec=countsec*2

we go in smaller steps to have some more precision, in steps that are about 8 times smaller:
tv96=tv96-12                          (12*8=96)
countsec=countsec*1.091         (1.091 ^ 8=2)


it's like having this conversion table from tv96 to msecs:


Tv96   msec
0   1000
-12   1091
-24   1190
-36   1299
-48   1417
-60   1546
-72   1686
-84   1840
-96   2007
-108   2190
-120   2389
-132   2607
-144   2844
-156   3103
-168   3385
-180   3693
-192   4029

follow the Tv96 column until you get to your value: the msec column has the equivalent shutter time.

As you see, it's anyway approximate because the value of -96 is 2007 (not 2000) and for -192 it's 4029, not 4000

I hope I made it clearer. If not, I blame the fever :-)
« Last Edit: 20 / February / 2009, 11:59:10 by fbonomi »
Logged
*

Offline mattkime

  • ****
  • 299
Re: making sense of tv values
« Reply #3 on: 20 / February / 2009, 11:34:49 »
is this on the site somewhere? if not, i should make a page.
Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: making sense of tv values
« Reply #4 on: 20 / February / 2009, 11:54:29 »
It's standard APEX system (http://en.wikipedia.org/wiki/APEX_system), except that Canon uses integer 96 multiples of the values (e.g., Tv96=96*Tv=96*log2(1/T), where T is shutter time in seconds). Well, almost standard -- Sv (sensitivity value) is tricky, there're three related propcases. That's perhaps one reason why ISO override has proven a source of perpetual confusion.

By all means, a good page of information is always welcome.
Logged
*

Offline fbonomi

  • ****
  • 469
  • A570IS SD1100/Ixus80
    • Francesco Bonomi
Re: making sense of tv values
« Reply #5 on: 20 / February / 2009, 12:03:19 »
@mattkime: no, there is no specific documentation about this.

@whoever: you are right, a reference to APEX waold have made it a bit less obscure :-)

and yes, the SV-ISO settigns have always puzzled me. Do you know something I don't know ? :-)
I mean, do you know where I can get some explanation of that stuff? (marketing SV vs other SVs)

Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: making sense of tv values
« Reply #6 on: 20 / February / 2009, 13:15:10 »
Quote from: fbonomi on 20 / February / 2009, 12:03:19
where I can get some explanation of that stuff? (marketing SV vs other SVs)
As you say, there's no coherent info on the subject -- surely no first hand docs (== fromCanon, Inc.). ISO override in CHDK, in its present state, was mostly done about a year ago -- the time of AllBest builds, remember? Then, there were some discussions scattered over a couple of forums, mostly conducted by Mr. AllBest himself (I believe he actually sorted it out in general, and in a sense in particular, so far as it somehow works in today's CHDK). The best way to understand his findings is to read the sources and see how he treats "SV", "market SV", and "delta SV" -- all of them somehow interconnected and related to the exposure calculation. This, I believe, is a good starting point to further comprehend internal canon workings (I personally never tried to delve deeper into this).
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: making sense of tv values
« Reply #7 on: 20 / February / 2009, 15:12:40 »
I wrote down some stuff about how each Sv/Tv/Av propcase works in CHDK last year when I did a Ev corrected viewport to MDFB in ubasic for a570... the propcases are pretty straghtforward but their operation changes with camera modes.

What our script commands and overrides use is another matter and I never found the motivation to compare code with my notes to document it all, I just started using propcases instead of those functions in scripts. maybe I should dig those notes up from the dust...
Logged
*

Offline mattkime

  • ****
  • 299
Re: making sense of tv values
« Reply #8 on: 20 / February / 2009, 15:38:05 »
>>It's standard APEX system

I've read the wiki page and i'm still not entirely sure what you mean by that - and I have a four year degree in photography!

anyway, this definitely points me in the right direction.
Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: making sense of tv values
« Reply #9 on: 21 / February / 2009, 03:21:19 »
Quote from: fudgey on 20 / February / 2009, 15:12:40
maybe I should dig those notes up from the dust...
Definitely -- they deserve a better fate! Then again, they will help mattkime to sort things out, so he can write a nice wiki page to everybody's delight.

Concerning the tricky one -- the "film speed" -- I seem to recall now (correct me if I'm wrong) that it's the "real ISO" that reflects actual sensitivity, and that both "real" and "market" are stored in EXIF and/or maker notes. However, in order to override  you have to change all of them  (real, market, delta) in a consistent way, at least that's how it is done in CHDK. The results are not fully consistent though, which was noted on the forums a thousand times or more. So if you indeed sorted it out how to consistently  override ISO -- then I'd say it is your duty to share ;-)

Quote from: mattkime on 20 / February / 2009, 15:38:05
>>It's standard APEX system
I've read the wiki page and i'm still not entirely sure what you mean by that
I believe I meant that Canon's internal Av/Tv/Sv/Ev/Bv were 96 times the corresponding logarithmic APEX values (http://en.wikipedia.org/wiki/APEX_system#The_additive_.28logarithmic.29_system). As mentioned above, that's to be able to go with integer math only, without sacrificing accuracy (96 divisions per full stop is more than sufficient). And how exactly you approximate log() with integer math is a matter of taste -- fbonomi showed one possible example.
Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal