CHDKPTP - PC Remote Control Performance Analysis - page 5 - RAW Shooting and Processing - CHDK Forum  

CHDKPTP - PC Remote Control Performance Analysis

  • 465 Replies
  • 99489 Views
*

Offline reyalp

  • ******
  • 13792
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #40 on: 01 / September / 2012, 16:17:18 »
Advertisements
If you think the filesystem is actually corrupted, you should probably verify that with some disk checking tools or something.

Not showing an image isn't conclusively diagnostic of disk corruption, it could mean the Canon firmware is confused in some other way.

Creating badpixel.bin is just regular file operations (fopen, fwrite, fclose, remove and rename) so if that kills the card then so should doing the same with Lua or the file browser. It's fairly unlikely that this would have gone unnoticed for as long as this port has been available, although regressions are always possible.

You can run CHDK/SCRIPTS/TEST/llibtst.lua to exercise these functions from lua.

Alternative possibility:
The 4gb card you bought is bad in some way. Counterfeit and junk cards are quite common.
Don't forget what the H stands for.

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #41 on: 01 / September / 2012, 17:07:43 »
chkdsk reports no problems and it's pretty rigorous.  I will try the other 8GB card this evening.

*

Offline reyalp

  • ******
  • 13792
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #42 on: 01 / September / 2012, 19:05:52 »
Based on your last post about the palette, I've checked in the changes from test-2 in the stable branch changeset 2112 unstable changeset 2113

Regarding the card, if it's bad, then exercising it without CHDK should show up problems at some point too, e.g. take some long videos or a bunch of stills.
Don't forget what the H stands for.

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #43 on: 01 / September / 2012, 23:43:12 »
BADPIXEL.BIN crashing PLAY mode

Here's the story ....

Both 4 GB SD cards are Duracell (one for the SX110 and the other for S90) were taken from the same rack (batch).  The SX110 4GB works properly (ie untethered I can view images in PLAY mode) with BADPIXEL.BIN. 

The SX90 has 2 cards: the {Duracell 4GB FAT16 TEST-2} and a {Lexar 8GB FAT12+FAT32 STOCK}.  The problem I described earlier happened on the 4GB card, twice.  The first time the problem occurred the card got badly corrupted before I could notice something was wrong (I know definitely at some point I did generate a BADPIXEL.BIN).  I then reformatted reinstalled afresh and detected the 1st point normal behavior deviation ie BADPIXEL.BIN which I described in detail yesterday (before I went to sleep I mean). 

So that's two strikes against the virtual batter (at this point could be the camera|SD .. could be CHDK .. we don't know yet).

The 8GB card has never had BADPIXEL.BIN generated or CHDK RAW enabled (same technical state as the 4GB after reformatting).  This is what I did just now:

a) Put in the 8GB card and tethered.

b) Pressed the SHOOT button in CHDKPTP a few times.

c) Validated file structure in FILES tab .. looks normal, new JPGs where they should be, no duplicates.

d) Untethered.

e) Did corruption test (see Yesterday at 19:34:39) and all's fine.

f) ??==>> Create BADPIXEL.BIN // OK

g) ??==>> corruption test: FAIL

Now I can't use PLAY mode on the untethered camera.  That is, 2 different SD cards {edit: with 2 different builds} are duds ... three strikes against the virtual batter.  I am thus convinced it is not the card.  So, it can only be either the camera, or CHDK.  Let us see if work this one out. 

Your turn.
« Last Edit: 01 / September / 2012, 23:48:04 by SticK »


*

Offline reyalp

  • ******
  • 13792
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #44 on: 02 / September / 2012, 03:03:33 »
None of this makes any sense to me.

Since creating badpixel supposedly triggers this problem, does deleting it make it go away?

Why all this stuff with "tethered" or not ? If it's caused by badpixel then just
1) fresh format + install
2) create badpixel
3) restart and see if the problem happens.

Badpixel generation takes two pictures. Is it possible that the black screen you are seeing is in fact the last image taken by badpixel ?

If you switch to record and back to play, do you see the images ?

Badpixel takes some memory, which might cause problems if the camara has very little free RAM. However it shouldn't be loaded unless you have DNG 1.1 enabled. You can check free memory in the misc menu.

Having DNG enabled will also cause more file handles to be used at startup, which could cause problems. Again, should not make any difference if you don't have DNG enabled.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4450
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #45 on: 02 / September / 2012, 08:19:49 »
@SticK
Can you try to
- reformat one of your cards
- reinstall CHDK
- use CHDK's File Browser to rename a file (you can find it in the "local menu" under the menu item "More"). The local menu can be reached by pressing "left". You may find the rename box a bit complicated to use (I do). After the rename operation, check for corruption.
If you can't figure out how to use the rename box, you can take 2 RAWs (CHDK RAWs, not DNGs), select them in File Browser (right key), find "RAW sum" or "RAW average" in the local menu (under "RAW ops"), and execute it. After it completes, check for corruption.

Why all this?
Badpixel generation has an implicit rename operation, there may be problems with rename on your cam. At least, this is my guess :)

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #46 on: 02 / September / 2012, 08:35:56 »
reyalp Quotes ....

None of this makes any sense to me.

==>> It's weird because I do have some experience with both SX110s ... I created, renamed and erased  badpixel.bin a few times to test that they did what they were intended to do and all's fine.  BTW, yesterday before noticing the corruption problem I did check same on the S90, and that worked.  That is I first inspected a shot w/o badpixel.bin and then with, and I got the expected results.

Since creating badpixel supposedly triggers this problem, does deleting it make it go away?

==>> Good question.  Before I do it I guess that it won't.  Here's what happened.   I deleted the file, ran chkdsk (passed), and the answer is: no, the problem is still there.  NEW: Next I put the tab in write protect so CHDK is not loaded and problem is still there.

Why all this stuff with "tethered" or not ? If it's caused by badpixel then just
1) fresh format + install
2) create badpixel
3) restart and see if the problem happens.

==>> Please reread carefully my original description.  As a reminder, "tethered" means "connected to CHDKPTP and running."  Your 1,2,3 is what I did, I preceded {Create badpixel.bin} by taking a few shots first to verify if everything works normally and it does, until badpixel.bin gets created.  The bottom line is it doesn't matter if the preceded test shots are taken "tethered" or "untethered."

Badpixel generation takes two pictures. Is it possible that the black screen you are seeing is in fact the last image taken by badpixel ?

==>> Good point.  Your idea prompted me to PAGE through the images (which I had not done till now) and yes indeed you're right all my other shots are there and so the two black images are there.  Correct.

So therefore the "No image" condition is likely a corruption that happened later in the day probably when I began using CHDK RAWs. For example, I noticed that RAWTherapee didn't recognize the DNG 1.1 and one of my first missions was to investigate this when I got trapped by the "No Image" corruption.  So while this is a good step, it's not resolved yet because I have not yet recreated the original problem.

If you switch to record and back to play, do you see the images ?

==>> Of course yes thanks, but I have to page because the 1st one that comes up is indeed the last dark image taken by Create badpixel.bin. 

Badpixel takes some memory, which might cause problems if the camara has very little free RAM. However it shouldn't be loaded unless you have DNG 1.1 enabled. You can check free memory in the misc menu.

==>> Just to be sure: Free 892 KB, CHDK: 252KB.

==================

So I declare *both* SD cards as not corrupted yet.  Now I will start with the RAWs again this time keeping a careful eye out for "No Image."

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #47 on: 02 / September / 2012, 08:45:31 »
@srsa_4c

Thanks for your tips // I will keep them in mind should I run into the "No Image" corruption.  I'm on edge because I have to get my-side instrumentation tests done and perhaps I am a bit too cautious at this point, but I must say relieved that so far all's fine and I can move forward.


*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #48 on: 02 / September / 2012, 09:16:00 »
BADPIXEL QUESTION

I recall reading that you do the bad pixel operation independently from Canon's preloaded map, correct?  Hence the 2 images and a comparison ... meaning with CHDK I have the freshest bad pixel map... correct?

Q1

How does it work?  Do you look for zero-valued (completely dead) pixels?  Let us assume I have some marginal very-low-valued poorly-responsive pixels ... Is there a way I can bring them into the map?  say by setting a threshold value?  In that sense, if I want to get more bad pixels, is a bright image better than dark?

Q2

When badpixel is enabled for DNG, what is the algorithm you use to interpolate the bad pixel?

Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #49 on: 02 / September / 2012, 10:16:22 »
Sometimes the wiki search function can be useful. :P

http://chdk.wikia.com/wiki/Badpixel_removal
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics