badpixel.bin generation problems - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1]   Go Down

badpixel.bin generation problems

  • 8 Replies
  • 6287 Views
*

Online reyalp

  • ******
  • 14080
badpixel.bin generation problems
« on: 05 / February / 2012, 21:31:06 »
Advertisements
I'm unable to create a badpixel.bin with the current trunk on d10. It shoots one picture, and then silently stops. It's definitely not even getting to the second shot, a print in BADPIX_S1 stays on the screen, so it's not hitting the console_clear() in BADPIX_S2. I don't understand how this can even happen  :blink:

I think I also saw the 'failed, try again' after only one shot was taken, since it only shot once, this wouldn't be the normal 'try again' that just happens because the counts don't match.

I reproduced this multiple times on d10. With the release-1_0 build, it worked right away.

I wasn't able to reproduce on a540, trunk worked fine multiple times in a row.

Looking back through the log, I didn't see any obvious culprits.

Putting a 1 sec delay between the first and second shots (pushed at the end of BADPIX_S1) seems to make it work. I've reproduced it enough both ways that I'm fairly sure it isn't just completely random.

I'd be interested to know whether the release-1 and trunk work on other cameras.
Logged
Don't forget what the H stands for.
*

Offline dvip

  • ****
  • 451
Re: badpixel.bin generation problems
« Reply #1 on: 05 / February / 2012, 22:48:25 »
Hi reyalp,
I just tested it from the raw menu with trunk 1648 and it did not work with the A590IS 101-b. It did not create badpixel.bin.

Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: badpixel.bin generation problems
« Reply #2 on: 05 / February / 2012, 22:57:27 »
Tried with 2 cameras: A430, A470. Both worked (with current trunk and release 1.0).
Compiled on Linux/x86, gcc 4.5.3, binutils 2.18 .
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: badpixel.bin generation problems
« Reply #3 on: 05 / February / 2012, 23:23:13 »
Do camera settings have any effect (mode, ISO, review hold time, etc)?
I know ISO setting affects the number of bad pixels on the SX30.

Will test my cameras tonight and report back.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Online reyalp

  • ******
  • 14080
Re: badpixel.bin generation problems
« Reply #4 on: 05 / February / 2012, 23:48:43 »
Quote from: philmoz on 05 / February / 2012, 23:23:13
Do camera settings have any effect (mode, ISO, review hold time, etc)?
I know ISO setting affects the number of bad pixels on the SX30.
I have review mode off, tried ISO 80 and 400 with no apparent effect. This is *not* the number of bad pixels varying between shots, it doesn't take the second shot at all. As best I can tell, it doesn't even execute the BADPIX_S2 item. I'm putting in some debug logging to try to figure out how that happens.

Quote
Will test my cameras tonight and report back.
Thanks :)

edit:
It seems to get stuck on waterwingz old friend AS_WAIT_SAVE

edit:
This looks like basically the same issue. The second shot fails for some reason (in this case, camera not quite done with the last shot ? not totally clear yet), so shooting never goes to SHOOTING_PROGRESS_PROCESSING and so can never switch back to done. The action stack sits around forever waiting for it to come back.

Adding a delay in the badpixel process between shots is probably a legitimate solution for the shot not firing, but the shoot command shouldn't go off to never land if the shot isn't taken.

I've attached the code I used for the code and scripts I used to debug this, in case anyone else finds themself need to trace whats going on the the actions stack.

Basic idea is
- patch adds some printf debugging macros that use the Printf eventproc
- enable uart logging with uartrctl.lua
- run your action stack / script stuff
- download the resulting uartr.log, optionally run it through the sed script to get human readable names for the action stack constants.
« Last Edit: 06 / February / 2012, 01:52:50 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: badpixel.bin generation problems
« Reply #5 on: 06 / February / 2012, 04:01:55 »
Here are my test results:

G12, IXUS310, SX30 and SX40 - works correctly on release-1.0 and trunk.

IXUS700 - works on release-1.0, fails to take first shot on trunk.

Having looked at the code there is one difference between the release and trunk versions.
When I cleaned up the histogram code I removed the un-needed states in the AS_SHOOT command stack that was waiting for the histogram calculation to complete - this was between the KEY_SHOOT_HALF and KEY_SHOOT_FULL actions.

Unfortunately I screwed up, and also removed the action that was waiting for the 'shooting_in_progress()' flag to get set (it was inside one of the histogram states) :(

Putting an action back in to wait for 'shooting_in_progress()' fixes the IXUS700, so should sort out other cameras as well.

Fix is in changeset 1649 (fingers crossed).

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline dvip

  • ****
  • 451
Re: badpixel.bin generation problems
« Reply #6 on: 06 / February / 2012, 11:11:52 »
I just tested it on the A590IS (a590-100e-1.0.0-1650) and the problem is gone.
Thanks!

Logged
*

Online reyalp

  • ******
  • 14080
Re: badpixel.bin generation problems
« Reply #7 on: 11 / February / 2012, 17:11:39 »
Quote from: philmoz on 06 / February / 2012, 04:01:55
Unfortunately I screwed up, and also removed the action that was waiting for the 'shooting_in_progress()' flag to get set (it was inside one of the histogram states) :(

Putting an action back in to wait for 'shooting_in_progress()' fixes the IXUS700, so should sort out other cameras as well.

Fix is in changeset 1649 (fingers crossed).

Phil.

Great, that seems to resolve it on d10 as well. Not totally clear why it failed on some and not others.

It does seem like we should have some kind of timeout if shooting fails to start.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: badpixel.bin generation problems
« Reply #8 on: 11 / February / 2012, 17:22:47 »
Quote from: reyalp on 11 / February / 2012, 17:11:39
It does seem like we should have some kind of timeout if shooting fails to start.
We talked about that on IRC for the new USB remote code - which uses the same action_stack sequence.  If the camera does not start a shoot due to inability to focus or set exposure in difficult shooting situations then it would hang.  But it turns out that only started happening when philmoz change the histogram code - which just happened to occur while I was testing the new USB remote code.  Once philmoz fixed that,  I have been unable to reproduce the USB remote hang during low light shooting. 

So a timeout seems like it would be good but I can't prove that we ever get into a situation where it is needed ?

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: [1]   Go Up
« previous next »
 

Related Topics