CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD - page 50 - Creative Uses of CHDK - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 45 46 47 48 49 [50] 51 52 53 54 55 ... 71   Go Down

CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

  • 704 Replies
  • 150375 Views
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #490 on: 04 / August / 2013, 19:30:41 »
Advertisements
In case you're still around, this looks *very* encouraging already, despite an uncharacteristic test setup ... shooting a wall !  I'll prepare the results soon.
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #491 on: 04 / August / 2013, 20:55:22 »
@srsa_4c

I think you got it ... the world's best small format scientific imager may have just been born and I'll explain later why.  See for yourself here.  Please put the shots into a viewer and flip to see how all this fares.  Despite the poor setup (a room wall), both shots were taken in M mode while maintaining external shot-to-shot conditions as stable as possible, with nothing changed except the hack.

Indeed, full zoom hack (40,1) at f/2 actual glass position (Fig 2), to my eye, produces (severe) vignetting.  What's more interesting ... note that the central bright disk in *both* images is the same brightness in both images (measuring an average R165 G165 B125 in IrfanView), and is about the same size, roughly 1/4 image height.  That suggests the "poor" setup is more than good enough for testing noticeable brightness anomalies and is good enough for a conclusive result here.  The upshot here is that although you see the vignetting correction, when operating normally (40,0) Figure 1, it does not completely correct the image at f/2 leaving a noticeable central bright spot.

What is even nicer that appears to be coming from your discovery ... is that with your f/8 hack, there seems to be no affect on overall exposure brightness of both images.  I expected them to be very different in overall intensity (ie the f/8 version a lot brighter), but you demonstrate they are not.  That is very welcome news.  The 101a has a calibrated diffuse uniform exposure test setup, so if your solution brings us a homogenous image we will definitely know, and this hack will not affect its internal Ev performance.

If there is no more than what you discovered to uncorrect (ie some minor lens correction at f/8), this would be perfect.  The 101a will be the big test.
« Last Edit: 04 / August / 2013, 21:26:52 by SticK »
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #492 on: 04 / August / 2013, 21:24:57 »
A NEAT COMPARISON ...

Despite different cameras, but because the effects are so gross, we can go a step further in the analysis of your solution.  So this is a skewed kind of test but nonetheless useful I think.

Figure 1

If both 101a and 100c cameras were identical, and, the correction is 100% exact (which we now know is not), then in theory a negative 101a image (left panel) should match the 100c f/8 hack image at f/2 glass (right panel).  That is, the left and right panels should be exactly the same, intensity-wise.  With IrfanView, I made a negative of the original 101a shot, and then to adjust for the different exposure conditions, pushed brightness to approximately match the *corner intensity* of the 100c shot.

The results are surprisingly close.  Note that in the 101a, Canon does actually try to correct the central bright spot (darker disk), but correction strength is not high enough, resulting in a noticeable bright spot instead of a uniform frame in the normal shot at f/2 (Figure 1 last post).

Figure 2

In the 101a negative image, in this figure I artificially extracted a better view of Canon's central disk partial-correction attempt, with a tone curve push.

Would you still need the DEBUG0 tests, or can we go we go ahead and try this on the 101a to see what we get, in an iterative fashion in effect ?

edit: my guess is that the central-disk correction might still be there, but let's hope it's not.  If you go this route, please  leave the set_config toggle in for now.
« Last Edit: 05 / August / 2013, 11:48:37 by SticK »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #493 on: 05 / August / 2013, 12:52:15 »
Quote from: SticK on 04 / August / 2013, 21:24:57
Would you still need the DEBUG0 tests, or can we go we go ahead and try this on the 101a to see what we get, in an iterative fashion in effect ?
It will depend on your 101a results. If those are not satisfactorily, further testing will be needed.
Quote
edit: my guess is that the central-disk correction might still be there, but let's hope it's not.  If you go this route, please  leave the set_config toggle in for now.
I left it in.

New CHDK 1.2 test builds are up. I hope that I managed to do the CHDK 1.1 -> CHDK 1.2 transition correctly. These builds have no debug code.

https://subversion.assembla.com/svn/chdk-s1.bin/files/
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #494 on: 05 / August / 2013, 19:56:14 »
I'm back.
Quote from: srsa_4c on 05 / August / 2013, 12:52:15
I hope that I managed to do the CHDK 1.1 -> CHDK 1.2 transition correctly. These builds have no debug code.
That's quite a jump ... several items at once?  Would it not be more rigorous to increment the currently known good 1.1 build, or is it too tricky/tedious to add this into the 1.1 build as an interim test platform ?
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #495 on: 05 / August / 2013, 23:27:59 »
@srsa_4c

How can I get you a case of your favorite beer?!  This is truly amazing.  I could safely say we have a scientific small-format instrumentation imager that leaves all the high-end pros in the dust, including Andor and Roper, naturally once I get the CCD down to -20C.  Not one of these specialty shops can compete with Canon's powerful and well-funded engineering resources.  It was a matter of us extracting that hidden magic, and we did it.

Congratulations!

Please put the image into your pixel browser and mouse around, because even your screen won't do it justice.  On top of it all, your hack shows us how dirty what I thought was a clean CCD window.  I did multiple passes with acetone and Q-tip to get it *clean enough* to demonstrate convincingly that there are no more image processing contortions left to disable!  The uniformity and sensitivity to tiny intensity differences is phenomenal.  Ev consistency looks good, pending many more tests of course.   But, before I delve into my FirstContact Cleaner (Microfunguy's great suggestion that's sitting in the fridge) and continue testing, please look at this ...

A little gremlin ...

V1.1 has been working perfectly w/o single failure for many months.  There is a caveat appears to me to be related to V1.2, or something else special here.  First impressions are always the best.  Everything PUPed fine into PLAY.  I did ->REC and took a shot.  JPG transferred to PC OK.  But then when I took the next shot, LENS ERROR, and good-bye.  Ouch.  But camera did not brick (ie MECHA SIM incompatibility) and PUPed OK again, and going ->REC is fine.  Here's what I've gleaned to help you resolve this one.  All these are from CHDKPTP.

  > Cam in REC MODE
  > I repeated the condition by SHOOT, but this time looking at the cam activity LED.
  > The LED flashed a few times (~4 times) as it does normally for processing and file save.
  > But, instead stopping flash after the save, it continues flashing permanently (here's where I got lens error by attempting a 2nd shot earlier).
  > So this time before taking a 2nd shot, I did ->PLAY first.
  > The first time I did ->PLAY, the GRAY DEBUG menu appeared (the same one I saw in the RAMDmps).
  > Pressing ->PLAY again cleared the DEBUG menu, the LED stopped blinking, and only then did the cam go into PLAY MODE.
  > Then I could ->REC and take a shot, but always only one shot and then needing to cycle through PLAY MODE.
  > That happened twice in succession.
  > The 3rd time I did the ->PLAY "blink stop" trick, the DEBUG menu no longer appeared, cam went into PLAY MODE as it normally should, but this time, the lamp kept blinking.
  > For this condition I discovered that ->REC stops the blinking, and I could take another shot.
  > So without rebooting, the V1.2 cam is in a state where I have to:
         PLAY ->REC (LED OFF)
         SHOOT (LED blinks permanently)
         REC->PLAY (LED blinks permanently)
         PLAY->REC (LED OFF)
         SHOOT  (LED blinks permanently)
         etc
  > If I adhere to the above, I don't get lens error.

I don't think this should be too difficult.

edit:
The DEBUG menu also randomly pops up when turning WHEEL L or WHEEL R in CHDKPTP.  I can conform the same thing happens on the 100c.  Thus my conclusion is that the DEBUG menu can come up randomly with any keypress, and interferes with normal key operation (could be related).  Hope this helps.  By the way, could you make default with set_config(40,1) but keep the enable/disable option in?

edit (more info):
Strange .. If I continue taking 1/8s exposures (ie all the sample shots so far using the shoot() function that I always use on the 101a) it keeps going into permanent blinking.   If I take one long exposure, at 4s, then the cam goes into a behave-normal mode and I can take sequential 1/8s shots w/o the failure for a few shots.  Then if I illuminate, liveview is black.  If I turn WHEEL buttons, I get LENS ERROR. Something is definitely wrong.
« Last Edit: 06 / August / 2013, 09:11:01 by SticK »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #496 on: 06 / August / 2013, 09:14:06 »
Quote from: SticK on 05 / August / 2013, 23:27:59
there are no more image processing contortions left to disable!
That's quite good news, I guess.

But
Quote
A little gremlin ...
this isn't. Especially, that it's a 'lens error'.

A few questions:
- Are you using your "old" modified chdkptp build, and your usual scripts for shooting?
- Can you reproduce the issue on the 100c camera using the latest 1.2 build? Beware: if you manage to crash the 100c cam with extended lens, be sure to power it on without the hacked CHDK next time, as it will find the lens in an unexpected state otherwise (due to the disabled startup lens chack).

And a few hints.
- Are you talking about the grey menu in the middle of the screen which has "<ALT> shortcuts" written in its first line? That's the "help" screen introduced in CHDK 1.2 . You can switch it off with set_config_value(291,0).
- About set_config_value(): this instruction is for adjusting a CHDK setting. The numbers are CHDK version dependent. Most of these will be saved in the CHDK config file, so you only need to issue set_config_value(40,1) once if you want the setting to stay. That means I don't see the reason to make this 1 by default, as you only need to set it once, and it will stay.
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #497 on: 06 / August / 2013, 10:05:55 »
Quote
That's quite good news, I guess
Yes, definitely.  *Your solution is beautiful*.

Quote
- Are you using your "old" modified chdkptp build, and your usual scripts for shooting?
I don't quite understand the difference in your question.  Here's the best I can do for now.  I don't know if or how "modified", but it is "old"  ... I am using the CHDKPTP build I have always used.  I am using my my_shoot(), which uses CHDKPTP shoot() and transfers files to PC, as always.  edit: it does have free memory display, which I think had to be coded into the EXE, in addition to me invoking a call from CHDKPTP.

Quote
- Can you reproduce the issue on the 100c camera using the latest 1.2 build?
I'd rather not .. don't want to risk sacrificing or hardware-messing this cam.  In fact, the 101a appears more resilient!  But I know the grey menu comes up randomly there too.

Quote
Are you talking about the grey menu in the middle of the screen which has "<ALT> shortcuts" written in its first line?
I'm pretty sure yes that's the one.  It comes up randomly on keypresses, and occasionally -- seems to interfere with CHDKPTP buttons.

Quote
You can switch it off with set_config_value(291,0)
I did, no effect on the blinking problem.  edit: So I think there are two problems and they may not be related.

Quote
That means I don't see the reason to make this 1 by default, as you only need to set it once, and it will stay.
Does your nodistcorr work the same way?  Because the way you have it, it seems guaranteed to come up in the right state regardless of issue.  But, if something happens to the cam battery or persistent RAM gets overwritten say in two years from now, then I'll have to do the same for nodistcorr (ie manually set_config etc) .. messy because I will have forgotten.  Anyway, we can cover this later.

Wow, I just had left the 101a running to write this and my computer started to act weird, cam  sending all kind of junk to CHDKPTP, log window scrolling on its own, had to shut the cam off to stabilize my computer.

I am pondering ... this looks like a too big a jump, as I had felt in my previous post.  May I suggest ... add the change to your 101a 1.1 hacks, especially if you think I would have to update my CHDKPTP exe.  Can we do it this way, ie incrementally, so I can just focus on the new fix?  It's much better to have a complete KWG 1.1 that I can fall back on, in case there is future trouble with 1.2 that was not detected at this time.  That would be *very* useful.

Hence I am very much in favor of getting a 1.1 stable system working first, before venturing off to 1.2.
« Last Edit: 06 / August / 2013, 10:42:11 by SticK »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #498 on: 06 / August / 2013, 10:47:29 »
Quote from: SticK on 06 / August / 2013, 10:05:55
Quote
- Are you using your "old" modified chdkptp build, and your usual scripts for shooting?
I don't quite understand the difference in your question.  Here's the best I can do for now.  I don't know if or how "modified", but it is "old"  ... I am using the CHDKPTP build I have always used.  I am using my my_shoot(), which uses CHDKPTP shoot() and transfers files to PC, as always.
OK, that's what I wanted to know.

Quote
Quote
- Can you reproduce the issue on the 100c camera using the latest 1.2 build?
I'd rather not .. don't want to risk sacrificing or hardware-messing this cam.
I understand, however, that test would be of great help when searching for the cause of malfunction.

Quote
Quote
Are you talking about the grey menu in the middle of the screen which has "<ALT> shortcuts" written in its first line?
I'm pretty sure yes that's the one.  It comes up randomly on keypresses, and occasionally -- seems to interfere with CHDKPTP buttons.
It could also be the console - this one appears at the bottom left part of the display - in CHDK 1.2 it auto-hides after a few seconds.

Quote
Quote
That means I don't see the reason to make this 1 by default, as you only need to set it once, and it will stay.
Does your nodistcorr work the same way?
No, that's fixed. The anti-anti-vignetting stuff can also be made fixed, I left it optional for testing reasons.

Quote
Wow, I just had left the 101a running to write this and my computer started to act weird, cam  sending all kind of junk to CHDKPTP, log window scrolling on its own, had to shut the cam off to stabilize my computer.
I have no idea what's going on. What kind of 'junk' was that?

I'll post 1.1 builds in a few hours. If the current test build acts this weird, better stop using it.
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #499 on: 06 / August / 2013, 11:29:56 »
Quote
I understand, however, that test would be of great help when searching for the cause of malfunction
I'd be willing to go into sacrificial territory with the 100c for 1.2 once we've got the 101a fully stable, and functionally correct, with 1.1.

Quote
in CHDK 1.2 it auto-hides after a few seconds.
Right, that's what I noticed happens when it comes up after an occasional button-press.

Quote
No, that's fixed. The anti-anti-vignetting stuff can also be made fixed, I left it optional for testing reasons.
Yes that's what I meant, and yes please leave the toggle in for now, until I can give a green light following further tests.

Quote
What kind of 'junk' was that?
The ">" cursor was blinking in the log window, as though it were scrolling fast on its own.  Plus, my mail app was behaving erratically until I powered down the cam.

Quote
I'll post 1.1 builds in a few hours. If the current test build acts this weird, better stop using it.
Great.  Oh yeah, although MECHA SIM works ie PUP->REC->PLAY, it's staying unpowered. I hope no persistent variables got affected ... that's my biggest fear at this point.

edit: A note on MECHA SIM LENS ERROR.   I've programmed the MECHA SIM only to respond correctly for Canon's expectancy in the PLAY->REC and REC->PLAY (or REC->SHUTDOWN) transitions.   Hence any other attempt to move a lens component outside of those two, will invariably result in a lens error.  So I think the 1.2 issue is quite severe, because it is not supposed happen on its own under normal 101a shooting usage since I was not asking the cam for either of those two transitions.
« Last Edit: 06 / August / 2013, 12:48:46 by SticK »
Logged
Pages: 1 ... 45 46 47 48 49 [50] 51 52 53 54 55 ... 71   Go Up
« previous next »
 

Related Topics