Shot Histogram Request - page 37 - CHDK Releases - CHDK Forum

Shot Histogram Request

  • 467 Replies
  • 148426 Views
*

Offline reyalp

  • ******
  • 14126
Re: Shot Histogram Request
« Reply #360 on: 19 / August / 2013, 16:35:27 »
Advertisements
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.
Note that we aren't necessarily asking you to re-write it. Code passing through several authors often ends up better for it.

Quote
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.
This was done for the USB remote capture feature (discussed starting around http://chdk.setepontos.com/index.php?topic=4338.820 released in 1.2). It is only implemented on a few cameras at the moment (see filewrite task nafrafs table http://chdk.wikia.com/wiki/User:Nafraf/csv2wiki) . Currently there is no way to disable jpeg outside of the remote capture process, but it would be relatively simple to add. Continuous mode generally works with remote capture, so not saving an image would be OK.

The remote capture thing is a good example of some code that both srsa and myself re-wrote several times. It is also related to what you are doing in that it makes hooked tasks wait for specific conditions.

This is a slight tangent, but one of the things I see in your code is that this hook waiting is very specifically tied to the shot_meter/shot_histogram stuff. It seems to me if this was done in a very general way exposed to script, it could allow implementing the same thing you have done while also opening up a bunch of other options.

What I envision is script being able say "make capt_seq wait at X" where X could be the the override hook, the NR hook, the raw hook when the raw buffer is valid, etc. The script could then poll or block until the condition is met, and take whatever action it wanted, and then tell the hook when it's ok to proceed. So for example, a script that wanted to get values from the raw buffer could do something like

Code: [Select]
hook=hooks.raw_ready -- hooks have a standard interface
hook.enable() -- tell hook to block when reached
...
press('shoot_full')
...
hook.wait() -- wait until hook is reached, could also have a hook.is_ready() for scripts that want to use a repeat / sleep loop and do something while they wait.
... get meter values ...
hook.continue() -- raw hook it can move on
Note that this would enable a lot more than just metering from the raw buffer in continuous mode. You could also write to the buffer (people have often asked for date stamps on cameras that don't support them), or perform whatever kind of analysis they want on the raw buffer. Bulk data processing (like histogram or shot meter) would be done in C functions that are only valid when a particular hook is active.

For applications that don't actually need to block, a count of how many times a particular hook was reached would be useful.

A hook in the override code would make fiddling with exposure values in the shooting process (the set_now vs set_later) thing a lot more predictable.

I know you've said that putting too much in script prevents you form getting the performance that you need, but without playing with a more script-oriented implementation, I'm not really convinced. Again, I'm not asking you to re-write it this way, this is something I would like to experiment with which could potentially generalize some of the things you have done.
Don't forget what the H stands for.

*

Offline lapser

  • *****
  • 1093
Re: Shot Histogram Request
« Reply #361 on: 19 / August / 2013, 19:44:29 »
Note that we aren't necessarily asking you to re-write it. Code passing through several authors often ends up better for it.
I agree, but I want to get it to a point where I'm satisfied with it before turning it over. I never really polished it up for release, and I have a lot of ideas now thanks to Waterwingz and you.
Quote
(see filewrite task nafrafs table http://chdk.wikia.com/wiki/User:Nafraf/csv2wiki) . Currently there is no way to disable jpeg outside of the remote capture process, but it would be relatively simple to add. Continuous mode generally works with remote capture, so not saving an image would be OK.
It looks like all my cameras have the filewrite task except for the D20 I just bought. I did get CHDK 1.3 and my mods and script installed on the D20 and it works fine. Good job on the port, nafraf!

If anyone feels like adding the filewrite task to the D20, that would be great. I haven't tried remote capture yet, but it sounds interesting. Would it be possible to add a Lua script function to turn jpg files on or off in cameras with filewrite task, or do you think that's a good idea?
Quote
This is a slight tangent, but one of the things I see in your code is that this hook waiting is very specifically tied to the shot_meter/shot_histogram stuff. It seems to me if this was done in a very general way exposed to script, it could allow implementing the same thing you have done while also opening up a bunch of other options.
Interesting ideas. Actually, I'm going to totally decouple the shot_meter/histogram part from the hook delays now. You'll be able to read the shot meter for the last shot at any time, just like the current shot histogram.

For half_shoot in single shot mode, all that's needed is the get_shot_ready() function, which lets the script wait until the histogram and/or shot meters are ready. There's no good way to do that at the moment.

Continuous mode is where you need the two delays: Pre-shot right before shutter open to so you can slow down continuous shooting to the desired interval, and post-shot, to give the script time to set the exposure for the next shot. These functions will be very simple after the shot data buffer part is removed.

The delays are set up as function calls in capt_seq.c, and raw.c. The two functions that are called are in shot_histogram.c. After I get it working, you could generalize it by changing the address of the functions that are called from a script, if you wanted.
Quote
I know you've said that putting too much in script prevents you form getting the performance that you need, but without playing with a more script-oriented implementation, I'm not really convinced.
Actually, I think you're right about scripts now.  I tracked down the major script delays I was having to writing the log file and jpg files at the same time. The script keeps up nicely for setting exposure in continuous mode, usually taking under 10 msec. Lua seems to be very fast.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 14126
Re: Shot Histogram Request
« Reply #362 on: 19 / August / 2013, 21:56:11 »
If anyone feels like adding the filewrite task to the D20, that would be great. I haven't tried remote capture yet, but it sounds interesting. Would it be possible to add a Lua script function to turn jpg files on or off in cameras with filewrite task, or do you think that's a good idea?
I think it's a good idea if there is a use case for it ;)

I'm not sure whether it should be a script option, or a menu setting (which you could set from script with set_config_value) or some combination. My inclination would be to make it menu option, without a separate script function.

The most common reason for people to want to turn off jpeg is to just shoot raw, but in practice I don't think this is much of a win. The smallest/lowest quality jpeg doesn't take much space or time to save, and if you save only raw, you cannot review at all on camera.

Note that our filewrite hook doesn't disable jpeg processing, it just ignores the writes to disk. I suspect that processing the data is a substantial part of the jpeg shooting time. Based on my observations in http://chdk.setepontos.com/index.php?topic=4338.msg103907#msg103907 the actual file writing happens in the background, and can be delayed long after the shot was taken. In fact it may not even start until the *next* shot has been exposed.
Don't forget what the H stands for.

*

Offline lapser

  • *****
  • 1093
Re: Shot Histogram Request
« Reply #363 on: 19 / August / 2013, 23:00:39 »
I think it's a good idea if there is a use case for it ;)
Thanks for that info and link. What I'd like to do is take 2 shots at a time. The first shot would be only for metering, and I'd use get_shot_meter() to set the exposure for the second shot. I wouldn't need to save the first shot.

I think the bottleneck in continuous mode is filling up the file write buffer. Yes, it might be a few shots ahead, but eventually, I think the speed limiting factor is how fast the jpg files can be saved to disk.

Have you tested how fast you can take multiple shots in continuous mode without saving the jpgs? I assume it would be faster, but I wonder how much faster it is?

As for a script or menu interface, I would be happy with just a C function for now so I can test out how to use it, and if it's worthwhile doing. Can you give me an idea how to implement this for testing? No rush, thanks.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 14126
Re: Shot Histogram Request
« Reply #364 on: 20 / August / 2013, 00:25:48 »
I think the bottleneck in continuous mode is filling up the file write buffer. Yes, it might be a few shots ahead, but eventually, I think the speed limiting factor is how fast the jpg files can be saved to disk.
On my a540, there is no discernible slowdown after a particular number of images. There are occasional hitches but for the most part it just shoots at the same rate indefinitely. See this thread: http://chdk.setepontos.com/index.php?topic=10488.msg103780#msg103780
Quote
Have you tested how fast you can take multiple shots in continuous mode without saving the jpgs? I assume it would be faster, but I wonder how much faster it is?
I have not tested this.
Quote
As for a script or menu interface, I would be happy with just a C function for now so I can test out how to use it, and if it's worthwhile doing. Can you give me an idea how to implement this for testing? No rush, thanks.
You should theoretically just be able to call filewrite_set_discard_jpeg(1) before each shot. However, the filewrite code will currently clear it (enabling write for the next image) when the write completes (generic/filewrite.c filewrite_jpeg_complete). The delay issues I mentioned earlier mean that re-setting it for each shot would be tricky. For a quick test you could comment out the code that resets it, or make it some value other than 1 mean "don't reset"
Don't forget what the H stands for.

Re: Shot Histogram Request
« Reply #365 on: 20 / August / 2013, 00:59:13 »
Hi Lapser,
I'm Sia (Siavash), thanks for putting the CHDK build and the script here for me to test.
I've successfully set up the new CHDK on bootable mode and everything worked fine, then I made some tests with the script to familiarize myself with the parameters, some of them are obvious and I'm gonna try other ones to find out how exactly they work, but I'm still confused about these ones:

Shots per Interval: Can we just set the desired interval, or this does something else?

Focus: What does this do? Does it mean that for being able to focus on something not too far away we have to experiment with this value with numbers between 0 and 1 to find the correct focus? or is it enough to manual focus the camera before starting the script?

Smoothing and Glitch: I was confused about these but found some explanations in your previous post.
 
Show Meters: I set this to 1 but nothing happened during the shooting, screen was black between shots (tested with 5 sec, 2 sec and also 1 sec  intervals)

Meter Areas: I think I roughly know that we can set 4 areas to be metered before starting the script, I'd appreciate if you let me know how exactly these areas work, for example, does is help if I put an area for ground and a separate area for sky? and maybe an area containing the places that sun will move on the frame during sunset?

Shutter->ISO (msec): ?

by the way what is the reason for the first shots that is overexposed?

I have to say it's a really good script and I figured out that you've done something with core CHDK that enables it to take shots faster than normal scripts, and set exposures more accurately between shots, I can't exactly understand some of the technical stuff that you guys talk about here but overall it looks great! As soon as I can figure out how to set it up I'll take a sunset time lapse with it and will post it here.

Thanks again

Sia


Re: Shot Histogram Request
« Reply #366 on: 20 / August / 2013, 01:07:56 »
The shot meter exposed the 2nd shot perfectly, matching the shot with the ND filter IN at the end of the first sequence.  The exposure change was about 2.75 EV when the ND filter went out. You can see the glitch at 1:11 in the video. There's a noticeable color change, so I guess the ND filter isn't quite ND.

I'm wondering why did you stop the script and changed the ND filter status while you were expecting the exact same exposure at the next shot (and possibly the shots after that?), was there any reason not to use ND after that point? cause this has introduced the glitch in there in both colour and the smooth movement of the cloud, and also with ND you can expect longer shutter speeds that are more accurate (compared to the shorter ones like 1/500sec etc) that prevents flickering in your movie.

I can understand if it was just for experiment, but in a real situation would you do this in the middle of a time lapse shot?

*

Offline lapser

  • *****
  • 1093
Re: Shot Histogram Request
« Reply #367 on: 20 / August / 2013, 01:52:36 »
You should theoretically just be able to call filewrite_set_discard_jpeg(1) before each shot. However, the filewrite code will currently clear it (enabling write for the next image) when the write completes (generic/filewrite.c filewrite_jpeg_complete). The delay issues I mentioned earlier mean that re-setting it for each shot would be tricky. For a quick test you could comment out the code that resets it, or make it some value other than 1 mean "don't reset"
Thanks! I tried commenting out the reset code and it worked. Then I tested the SX260 camera in continuous mode holding down the shutter button. The spec on the camera is 2.4 shots per second, and that's what I got, both with filewrite disabled, and not disabled. My script did adjust the exposure properly without writing the jpg files, but maximum shot rate was unchanged. My script only does 2.0 shots per second maximum, probably because of the script handshake and shot_meter delays.

I suspect that the camera is hard wired for 2.4 shots per second in continuous mode, whether you're saving files or not. So there's no speed benefit in skipping the jpg saving.

By the way, nafraf already sent me a build for my new D20 with the filewrite task. I was able to do remote captures with it, which I'll have to admit, is pretty cool! Good work. The jpgs didn't show up on the camera either, so I assume nafraf did it right.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline lapser

  • *****
  • 1093
Re: Shot Histogram Request
« Reply #368 on: 20 / August / 2013, 02:48:42 »
Shots per Interval: Can we just set the desired interval, or this does something else?
That's great that you got it working!

You can keep this at 1 normally. It's actually the number of un-delayed shots per interval. I designed it for longer intervals where you want to do a shot or two to get the exposure right. Try setting the interval to 10,000 with 2 shots per interval, and you'll see what it does.
Quote
Focus: What does this do? Does it mean that for being able to focus on something not too far away we have to experiment with this value with numbers between 0 and 1 to find the correct focus? or is it enough to manual focus the camera before starting the script?
For sunsets, I always set it to 1. The script will calculate the "hyperfocal distance" and focus there. This is the closest you can focus and still have infinity in focus. You don't have to worry about focusing then, and foreground objects should be in focus as well as the sunset and clouds. It works pretty well.

If you set it to 0, the camera will do autofocus on the first shot, and hold that focus.
Quote
Smoothing and Glitch: I was confused about these but found some explanations in your previous post.
 
Show Meters: I set this to 1 but nothing happened during the shooting, screen was black between shots (tested with 5 sec, 2 sec and also 1 sec  intervals)
What this does is write lines on the first shot to show the metering areas. The first shot uses the camera meter for exposure, so it's usually overexposed on sunset time lapses. Writing the meter areas on it ruins it as a picture, but it's a good record of the meters.

If you want to see the meter areas on the screen while shooting, press the RIGHT key.
Quote
Meter Areas: I think I roughly know that we can set 4 areas to be metered before starting the script, I'd appreciate if you let me know how exactly these areas work, for example, does is help if I put an area for ground and a separate area for sky? and maybe an area containing the places that sun will move on the frame during sunset?
This is one of the most powerful features of the script. It looks at all the meters and picks the brightest so no area is overexposed. My early time lapse test of sunset over the city resulted in the city lights being way over exposed after the sky got dark. Skip to the very end of this video to see the effect:
http://www.youtube.com/watch?v=MQah7sksQaw#ws

But in this video, I put one of the meters on the a part of the city where I knew the lights would get brighter. I held the first frame so you can see the metering areas at the beginning. Then skip to the end and see how different the city lights are after dark.
http://www.youtube.com/watch?v=qhkVtBtY3t0#ws

This last one is one of my favorites for using the meters. I put one meter on the sky and another very small rectangular meter on Willamette street. The small meter took over after dark and I zoomed in on the street to see the cars better (with movie software). At the very end, I showed the metering area by stopping the script and immediately starting it again to take a picture with the metering areas, and then stopping it.
http://www.youtube.com/watch?v=pozFliELR4w#ws
Quote
Shutter->ISO (msec): ?
The script will vary the shutter time until it gets to this value, using the minimum ISO. Then it holds this value and varies the ISO until it reaches the maximum. Then it goes back to increasing shutter time until that reaches maximum.
Quote
by the way what is the reason for the first shots that is overexposed?
The exposure of the first shot is set by the camera. If the shot meter area is the same as the camera meter area, they would be exposed the same. Usually, I put the shot meter on the brightest part of the sky, so the 2nd shot gets a lot darker.

The bvDelta parameter is the amount of underexposure at -500 (night). It starts at +500 (day). A change of 96 is 1 fstop, so 192 is 2 fstops underexposed after it gets dark.
Quote
I have to say it's a really good script and I figured out that you've done something with core CHDK that enables it to take shots faster than normal scripts, and set exposures more accurately between shots, I can't exactly understand some of the technical stuff that you guys talk about here but overall it looks great! As soon as I can figure out how to set it up I'll take a sunset time lapse with it and will post it here.
Don't forget to set up the camera before starting the script. I usually use Av mode. Turn everything off that you can, especially "safety manual focus." Make sure it's in continuous drive mode also. It's faster, and the pictures will be visible on the screen.

I look forward to seeing what you come up with. Good luck.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline lapser

  • *****
  • 1093
Re: Shot Histogram Request
« Reply #369 on: 20 / August / 2013, 03:00:09 »
I'm wondering why did you stop the script and changed the ND filter status while you were expecting the exact same exposure at the next shot (and possibly the shots after that?), was there any reason not to use ND after that point? cause this has introduced the glitch in there in both colour and the smooth movement of the cloud, and also with ND you can expect longer shutter speeds that are more accurate (compared to the shorter ones like 1/500sec etc) that prevents flickering in your movie.

I can understand if it was just for experiment, but in a real situation would you do this in the middle of a time lapse shot?
The shutter speed maxes out at 3200 for the sx260. On really bright days, or with the sun in the frame, it's nice to extend that with an ND filter. The SX50 and SX260 both have undocumented ND filters that CHDK can control.

Yes, this was a test and I would never do this unless I was testing. I need to test some more so I can find the precise density of the filter and change the exposure by this amount when I set the filter in or out. That's on my to do list, but I'm worried that it will be noticeable. We'll see.

I've found that varying ISO is very precise and works great. Varying the shutter time isn't as precise, and at really fast shutter speeds, the exposure overshoots or undershoots what it's supposed to be. The next shot may sense this and over-correct the other way, leading to "fluttering" of exposure in the time lapse. The ND filter may help keep the shutter times longer to avoid this fluttering. The SX50 has this problem worse than the G1X. The SX260 doesn't seem to have the problem.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

 

Related Topics


SimplePortal © 2008-2014, SimplePortal