Shot Histogram Request

waterwingz

12139

Re: Shot Histogram Request

« Reply #350 on: 18 / August / 2013, 09:57:19 »

Advertisements

@lapser : a couple of questions about the shot_meter_enable() & get_shot_meter() functions ?

Your TLapser.lua script calls the shot_meter_enable() function and passes 7 parameters. The code only expects 6. The final parameter seems to be ignored - I think it was supposed to have something to do with "smoothing" ?
The value returned by get_shot_meter(0) seems to just be a calculated Bv based on the Av, Tv, & Sv prop case values from the previous image? You don't calculate the Bv value from the raw buffer in your code? Are you supposed to add the get_shot_meter(1), get_shot_meter(2), get_shot_meter(3), get_shot_meter(4) returned values to the get_shot_meter(0) value to get acccurate individual meter area Bv values? Or are those values just "offsets" to tell you how much to adjust the exposure?
In shot_histogram_set_meter(int im,int x1,int y1,int w, int h, int draw) should the parameters w (width?) and h (height?) actually be named x2 & y2 based on how they are used in the code? There is a comment that sort of explains that but its a bit confusing.

Thanks.

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #351 on: 18 / August / 2013, 14:03:53 »

Quote from: waterwingz on 18 / August / 2013, 09:57:19

@lapser : a couple of questions about the shot_meter_enable() & get_shot_meter() functions ?

1. Yes, that's a mistake in the script I'll correct. Thanks for pointing it out. I initially tried to set the exposure and do the smoothing in the C code so it could keep up in continuous mode, but I decided that was too inflexible. But then I had to add a delay for the script to finish setting the new exposure before taking the next shot. Waiting isn't necessary in single shot mode since the script triggers the next shot.

2. Each shot meter returns an Apex96 value that you can add to the current exposure to to get to optimum exposure. I think this is 2 ev (192 apex96) below a meter reading of 50% linear, which approximates the built in camera meter. But the Bv value for the meters also depends on the exposure settings of the shot (Av, Tv, Sv). These settings are the same for all the meters. get_shot_meter(0) returns an Apex96 value that you add to each meter to get the individual Bv96 reading for that meter, as you stated.

You don't really need the Bv96 values most of the time, since you can adjust for optimum exposure with just the shot_meter values. But in my script, I wanted to underexpose the shots as it gets darker, so I use bv96 to tell how dark it is. My script adds an underexposure adjustment (specified in a parameter) which varies linearly from bv96= +500 to -500.

3. This is because I convert the x1,y1,x2,y2 percent input values from the script into absolute x,y,w,h for the shot meter calculation and use the same variable names.

Code: [Select]

  //convert from %(x1,y1,x2,y2) to actual (x1,y1,w,h)
  x1=(CAM_ACTIVE_AREA_WIDTH*x1)/100;
  w=(CAM_ACTIVE_AREA_WIDTH*w)/100 - x1; //w is input width now
  x1+=CAM_ACTIVE_AREA_X1; //x1 is input left position
  
  y1=(CAM_ACTIVE_AREA_HEIGHT*y1)/100;
  h=(CAM_ACTIVE_AREA_HEIGHT*h)/100 - y1; //h is input height now
  y1+=CAM_ACTIVE_AREA_Y1; //y1 is input top position

I should have some time to work on it for the next few weeks. But I've been reviewing the code, and I don't think separating out the shot meter/histogram part from the time lapse part is as easy as it sounds. The exposure values, and the calculated shot meter values are stored in a buffer that is initialized in capt_seq_hook_set_nr() (time lapse part) right before shutter open. get_shot_meter reads its results out of the buffer. In continuous mode, this means you can be reading valid values even though the next shot has already started. I spent months getting all this to work right.

The tearing apart my baby analogy isn't so much an ego thing, although I appreciate your link. It's just very difficult to take a fully debugged, working program and split it up into different parts, and then have to debug the individual parts. Presumably, we'll want to add the time lapse part again, and have to put it back together and debug it all over again. I designed all this to work together, and it does that pretty well now.

So rather than spending a lot of time splitting up the shot meter/histogram and time lapse parts, I'd rather use the time to finish and test the shot histogram part more. I also want to add ND filter control to the script and Bv calculation. I'm happy to get rid of the set_exp96() function and use the current exposure functions modified to work in half_shoot, and with set_sv96() corrected. The apex96 conversion functions are also a separate issue.

I'm glad you're starting to understand and appreciate the power of the shot meter. I think I can do a similar thing with the histogram, i.e. return an exposure adjustment value for optimum exposure based on the histogram for each meter.

But I'm not sure anyone appreciates how powerful the time lapse part is, i.e. set_shot_interval. First of all, the timing of the shots is absolutely perfect, or as close as you can get. A script can't be this precise on its own, and it's pretty complicated to set up the timing correctly in a script. Also, the script can trigger an immediate shot with set_shot_interval(1), and then reset the interval back. The script has precise control of when the shot is taken, so you could trigger synchronized shots with multiple cameras based on anything the script wants, rather than just the current PTP sync method. And of course, it works in continuous mode at maximum speed (more that 2 shots per second for most cameras).

So would it be possible for everyone to agree to work on adding the time lapse/shot meter modifications together? I've tried to set it up so there's only 2 function calls hooked into the current code, that simply return if you haven't called set_shot_meter() or set_shot_interval(). It shouldn't interfere with old scripts or CHDK features.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

waterwingz

12139

Re: Shot Histogram Request

« Reply #352 on: 18 / August / 2013, 14:55:37 »

Quote from: lapser on 18 / August / 2013, 14:03:53

And of course, it works in continuous mode at maximum speed (more that 2 shots per second for most cameras).

I've been doing a lot if drivelapse shooting over the last week. Can't get better than 1 shot / second in continuous mode with my SD940. Discrete shooting mode is slower than 2 seconds per shot. Unlike sunsets, drivelapse has rapidly changing exposures as you face in and out of the sun. Driving beneath an underpass is also a challenge - by the time the exposure is set your are back out in bright sunshine again. Driving slow is better and making smooth turns requires you to drive really slow. But 1 frame per second is about as slow as you can go and have a viewable video when you are done.

I think the best solution is to move to Belgium or Denmark, where it is always grey and overcast.

Quote

So would it be possible for everyone to agree to work on adding the time lapse/shot meter modifications together? I've tried to set it up so there's only 2 function calls hooked into the current code, that simply return if you haven't called set_shot_meter() or set_shot_interval(). It shouldn't interfere with old scripts or CHDK features.

I suspect there will be some concern about the interlocks between functions that you needed to use in your code to make this all work.

But focusing just on the shot histogram stuff and on continuous shooting mode (for fastest frame rate and therefore smoothest time lapses), these seem to be the high level requirements :

Allow a mechanism for "shot meter" style measurements of illumination (in Bv96 values) from the raw image buffer while shooting in continuous mode
Allow more detailed information from the "shot meter" for histogram type analysis
Allow adjustment of exposure settings ( Tv, Av, Sv, ND filter) while shooting in continuous mode with the ability to ensure that adjustments are only made between shots.
Allow the ability to pause continuous mode shooting so that additional processing can occur prior to taking the next shot.

Did I miss anything important ?

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #353 on: 18 / August / 2013, 16:41:44 »

Quote from: waterwingz on 18 / August / 2013, 14:55:37

I've been doing a lot if drivelapse shooting over the last week. Can't get better than 1 shot / second in continuous mode with my SD940.

Oops, it looks like the spec for that camera is 0.8 fps:
http://www.usa.canon.com/cusa/support/consumer/digital_cameras/powershot_sd_series/powershot_sd940_is#Specifications

The sx260 goes to 2.4 fps. Interestingly, it's 0.8 fps with autofocus on, so it sounds like the SD940 is always doing autofocus in continuous mode? But I think you need to try a different camera for drivelapsing. This is a test I did a long time ago with a 1.33 shot per second rate (750 msec interval).
http://www.youtube.com/watch?v=b_nVZbV-MR4#ws
If you want to use my script for drive lapse, try setting the glitch and smoothing parameters to 0. Here's how they work:

Glitch: ignores first exposure change > glitch value. It takes 2 in a row. This handles a lightning flash going off at night, for example.

Smoothing: Limits exposure changes to 1 ev96 within plus or minus smoothing value. I usually use 32 ev96, so the exposure result is within 1/3 ev of optimum. This eliminates fluttering from inaccuracies in small exposure changes, i.e. at fast shutter speeds. It might help with a drivelapse.

Quote

I suspect there will be some concern about the interlocks between functions that you needed to use in your code to make this all work.

But focusing just on the shot histogram stuff and on continuous shooting mode (for fastest frame rate and therefore smoothest time lapses), these seem to be the high level requirements :

Allow a mechanism for "shot meter" style measurements of illumination (in Bv96 values) from the raw image buffer while shooting in continuous mode
Allow more detailed information from the "shot meter" for histogram type analysis
Allow adjustment of exposure settings ( Tv, Av, Sv, ND filter) while shooting in continuous mode with the ability to ensure that adjustments are only made between shots.
Allow the ability to pause continuous mode shooting so that additional processing can occur prior to taking the next shot.

Did I miss anything important ?

That sounds basically right. Take a look at shot_histogram_shot_delay(). When not shooting a time lapse, it still saves the exposure values in the shot data buffer so they can be used later by the shot meter for bv96 calculation.

The rest of the shot data buffer is filled after the raw buffer is ready, in shot_histogram_do_histo(). Without the shot data buffer, it doesn't work right in continuous mode since exposure and meter data aren't guaranteed to refer to the same shot.

Again, I've got all this working and debugged. I don't see any advantage in trying to split it up.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

waterwingz

12139

Re: Shot Histogram Request

« Reply #354 on: 18 / August / 2013, 17:25:27 »

Quote from: lapser on 18 / August / 2013, 16:41:44

The sx260 goes to 2.4 fps. Interestingly, it's 0.8 fps with autofocus on, so it sounds like the SD940 is always
doing autofocus in continuous mode?

Nope - my script locks focus at infinity (AFL shows on the Canon OSD). Its an older camera and one of the smallest Canon has every made. You don't get something for nothing.

Quote

But I think you need to try a different camera for drivelapsing

The SD940 is just a really nice & light image stablized pocketable camera (shirt pocket - not cargo pants side pocket). Not sure I want to hang my G10 or SX50 on a suction cup windshield mount. One fps is good enough for archiving the drives I want to remember some day.

Quote

If you want to use my script for drive lapse, try setting the glitch and smoothing parameters to 0. Here's how they work:

Well, I have my own script - I seem to have written a few - and playing with your own code is way more fun that just using somebody elses. But thanks for the offer !

Quote

Quote
Did I miss anything important ?
That sounds basically right. Take a look at shot_histogram_shot_delay().

Good - thanks.

Quote

Again, I've got all this working and debugged. I don't see any advantage in trying to split it up.

A highly customized piece of code working and debugged to suit your exact requirements is a great accomplishment. I salute you. But when this is all over, I expect we wil end up with a more generalized solution suitable for multiple scripting applications and the complete range of 112 or so cameras we support. Pretty much every patch I have posted beyond the trivial bug fixes has been improved by reyalp, philmoz, msl, srsa_4c or someone else. So please try to remember rules 2 & 3 as we go along for the ride.

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #355 on: 18 / August / 2013, 18:28:10 »

Quote from: waterwingz on 18 / August / 2013, 17:25:27

A highly customized piece of code working and debugged to suit your exact requirements is a great accomplishment. I salute you. But when this is all over, I expect we wil end up with a more generalized solution suitable for multiple scripting applications and the complete range of 112 or so cameras we support. Pretty much every patch I have posted beyond the trivial bug fixes has been improved by reyalp, philmoz, msl, srsa_4c or someone else. So please try to remember rules 2 & 3 as we go along for the ride.

I like to think of what I've written in C as more generalized than customized. I tried to make sure everything works in single shot, and with the shot meters enabled or disabled, and that it doesn't break any old scripts. Phil pointed out awhile back that a few cameras don't have capt_seq_hook_set_nr() implemented. I think I can include a workaround for that problem within the current code structure if that's important. But why not start with the current code and capabilities that I've already done and have everyone see what they can do to generalize and improve it, if needed?

Also, I don't think you want the shot meters to just return bv96. Then you would need the av, sv and tv values for that shot to compute the next exposure change, and they're not always available in continuous mode. I could have the meters return the suggested exposure change AND bv96 as a second Lua return value if that's easier.

And I welcome all help and improvements, including totally re-writing everything if that's what people want to do. But if the "improvements" take away the continuous mode and other capabilities, then they're not really improvements.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

reyalp

14082

Re: Shot Histogram Request

« Reply #356 on: 18 / August / 2013, 19:27:16 »

Quote from: lapser on 18 / August / 2013, 16:41:44

Again, I've got all this working and debugged. I don't see any advantage in trying to split it up.

One big advantage is making it understandable to the people who will have to maintain it. It will also probably result in code that is more modular, and thus easier to maintain. As a maintainer "working" isn't the only thing that matters to me.

I've been trying to follow this thread but haven't had a chance to dig into the code enough to provide detailed feedback yet. From what I have seen, it seems both complicated and very tightly tied to your specific use case, but I'll have to look more to understand whether those impressions are justified. Waterwingz efforts to separate out the different aspects are certainly helpful.

I know you have spent a lot of time on this, and the value is clear. I would definitely like to have some form of it in CHDK, but I'm not in a hurry. I'd rather get things right than put in something that causes a lot of headaches later.

Logged

Don't forget what the H stands for.

lapser

1093

Re: Shot Histogram Request

« Reply #357 on: 19 / August / 2013, 02:21:06 »

Quote from: reyalp on 18 / August / 2013, 19:27:16

I know you have spent a lot of time on this, and the value is clear. I would definitely like to have some form of it in CHDK, but I'm not in a hurry. I'd rather get things right than put in something that causes a lot of headaches later.

That sounds good. Let me see what I can do to make it more modular and easy to understand. I think that I can get rid of the shot data buffers, which work but are complicated. The script can buffer the data it wants in a string and then release the camera to take the next shot (in continuous). I'll make the code as modular and easy to understand as possible, but it's a design change. Trying to split up the current code won't work right. That's what has seemed rushed to me.

I want to ask you one more thing. I understand you're implementing a new file save hook. Is it possible to abort the jpg save after the raw buffer is ready? In addition to avoiding saving Canon jpgs with CHDK raw, it might be very useful in conjunction with the shot meter. I wonder what would happen in continuous mode if no jpg or raw files were being saved? I'm assuming it would speed up the shot rate, but I'm not sure. Is there a thread on the file save hook? Thanks.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

waterwingz

12139

Re: Shot Histogram Request

« Reply #358 on: 19 / August / 2013, 09:47:12 »

Quote from: lapser on 19 / August / 2013, 02:21:06

I think that I can get rid of the shot data buffers, which work but are complicated. The script can buffer the data it wants in a string and then release the camera to take the next shot (in continuous). I'll make the code as modular and easy to understand as possible, but it's a design change.

Before you start any recoding, and referring to my previous post [ http://chdk.setepontos.com/index.php?topic=8997.msg104252#msg104252 ], I think it would be good to discuss the mechanism to be used to sync exposure settings and continuous mode "pausing" under script control. Getting that generalized, the timing understood, with a clean script interface, and the actions coordinated is probably the biggest challenge. Your work with the histogram & shot meter code seems to be good enough for now (given that all code can usually be improved if you want to invest the time).

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #359 on: 19 / August / 2013, 11:49:15 »

Quote from: waterwingz on 19 / August / 2013, 09:47:12

I think it would be good to discuss the mechanism to be used to sync exposure settings and continuous mode "pausing" under script control. Getting that generalized, the timing understood, with a clean script interface, and the actions coordinated is probably the biggest challenge. Your work with the histogram & shot meter code seems to be good enough for now (given that all code can usually be improved if you want to invest the time).

Thanks for all the input. I understand what needs to be done to simplify the code and get it into the trunk in an organized manner now. I can eliminate the shot data buffers and get rid of a lot of code and complexity. Also, it will decouple the shot meter and histogram functions from the time lapse part. We can put each into the trunk separately like everyone wants.

You caught me at the stage where I just got everything working, including Phil fixing that nasty "Lua bug." But the code really wasn't ready to turn over yet. Let me spend this week working on it, and I think I can have something ready for you to look at, and for everyone to modify as they wish.

As for the timing code and script delay, that's not as big a problem as it appears. The get_shot_ready() function already aborts the wait for script delay in continuous mode, on the first call after it returns true. If you want to abort the script delay and do more processing, all the script needs to do is save the get_shot_ready() return value. There's no need for another function to abort the script delay (like set_exp96). This complete time lapse script explains what I mean:

Code: [Select]

set_shot_meter(1 [,metering area])
set_shot_interval(1000)
press("shoot_full")
repeat sleep(10) until get_shooting()
tv=get_tv96()
ready=false
repeat
  if(not ready)then
    repeat sleep(10) until get_shot_ready()
  end
  sp=string.format("tv=%d",tv) -- save string to print later
  tv=tv+get_shot_meter(1)
  set_tv96_direct(tv) -- assumes it work in half_shoot
-- the next part is optional 
  ready=get_shot_ready() -- aborts script wait delay and saves ready status
  print(sp) -- print log file without delaying next shot
until false

A little background... In my testing with continuous mode, I discovered that writing a log file while the camera was also saving jpg files as fast as it could, sometimes resulted in long delays in the print or write statement. I fixed this by buffering the shot data, including the shot meters. The buffers allow you to read the meters from the last shot even while calculating the meters for the next shot. That solved the print delay problem nicely.

Eliminating the buffers means you have to process all the meter data before starting the next shot. But part of that processing can be saving the log file in a string (using string.format). The lua string becomes the buffer, so the shot data and meters don't need to be buffered. That makes the C code a lot simpler. That's what I'll be writing this week.

[edit] After thinking about it a little more, I don't think you really even need to save the ready flag in the second call to get_shot_ready(). At that point, get_shot_ready() had just returned true, and CHDK is waiting for the script to call get_shot_ready() again before continuing. But another shot can never become ready during the wait for script delay.

« Last Edit: 19 / August / 2013, 13:24:16 by lapser »

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos