SD990

[ewavr]

Did you do this with dng4ps2 ? If so, can you describe how ?

Yes, using dng4ps2 as described in Wiki.
22 squares was selected (except top-left (brown) and bottom-right (black)).
As usually, dng4ps2 reported: "results are poor", on 4 squares error reached 11-11.5%.
Of course, this is 'unofficial' calibration (but result is better than matrix from other camera).

[Marcel2087]

Wow! This will be a nice Sunday just playing around with the camera...amazing work so far!

[hnikesch]

Nice surprise this morning to find this post,  Loaded the port and found most things working well,  things tested so far bracketing, Custom auto iso, OSD displays, User menus, SD overide, Manual flash.  Pleasant surprise unlike my other SD cameras the ISO value forced by Custom auto ISO displays during play back mode.  All exposures were correct,   Great Job,  It's already usable

[reyalp]

Glad to hear it's working for you guys. Here's an update:
Fixed:
- CHDK live histogram
- CHDK UI colors. If you've set custom colors in your CFG, you'll need to reset to see the difference. A couple colors in the boot logo are still off.
- DNG saving. Color is not great. I wasn't sure how to translate ewavrs color matrix to the DNG code, maybe I guessed wrong. DNG extension via USB not supported (I didn't see the required pointers anywhere in the dump) ufraw and irfanview load without problems, very purple cast. badpixel.lua ran without problems.
- Cached raw. Not as much speedup as other cams, maybe 200ms (out of 5+ seconds) on DNG save time.
- Motion detector. Tested with MDFB digic 3 version briefly.
- shot_histogram. Not tested. The range is scaled to be the same as 10bpp sensors (simply dropping the two lowest bits), so existing scripts should be able to run unmodified.

I enabled the USB remote #defines, not tested or looked at the code.

Also did some work so that it integrates into the code without breaking other cams.

I've attached the small zip with just the CHDK binary files. The previous post has a full zip with the other files.

I probably won't get a chance to do too much more work on this for a bit, both next week and the following weekend look busy.

[ewavr]

- DNG saving. Color is not great. I wasn't sure how to translate ewavrs color matrix to the DNG code, maybe I guessed wrong.  ufraw and irfanview load without problems, very purple cast.

Here is DNG, produced by DNG4PS2 from your CRW (converted to 10 bit) - out.7z - 12.34MB
DNG4PS2 settings are shown in attached screenshot (color matrix is the same which I posted earlier). IMO, colors in dng are satisfactory (in dcraw and ACR at auto, daylight or cloudy WB).

P.S. In your diff BLACK_LEVEL is still 31. Maybe, it must be 127 or 128?

edit: I can confirm, that purple colors are disappears after set BLACK_LEVEL to 127.
Here is "true 12 bit" DNG, produced from your CRW (not converted) by my own DNG writer - out.7z - 13.47MB

[reyalp]

P.S. In your diff BLACK_LEVEL is still 31. Maybe, it must be 127 or 128?

edit: I can confirm, that purple colors are disappears after set BLACK_LEVEL to 127.

Oh, that makes sense. So much for the 12 bit advantage

edit:
here's a build with black level corrected and active area set for DNG.

[hnikesch]

I am getting good color using CRW and .dng files in Raw Therapee slightly cooler than the .jpg files but nice,  I am a real rookie with raw, still trying to understand when to use it.  Also loaded some raw and .dng files into photoshop but I don't know any settings or how to handle raw in PS, poor results but that's my fault
I think I will stick with jpg for a while. 

ND filter over ride works, fast ev switching works, All of the OSD displays work,  user menu and font sizes work, I will play more when I get more time

Thanks guys, 

[nabeshin]

Hello!
I've been waiting anxiously for this port since last year when I bought Ixus 980. It's working great for me! The only bug I found is when focusing with Zebra enabled, which provokes a lot of white dots in screen. Anyways I don't use zebra, I even  don't know what it is.
AEB works great and this would be enough reason to use CHDK. DNG is working great, too (ACR and Pixelmator recognizes it)
Thank you so much, you've made me forget about buying a reflex

Thanks for your efforts.

[reyalp]

As stated previously, zebra is broken. It will take some hacking to fix, because of the difference between viewport resolution and bitmap resolution. I suggest disabling the zebra option. Edge overlay is broken for the same reason.

Most raw operations are similarly broken, because CHDK is hard coded to assume 10 bpp.

[snc]

@reyalp: in your /sub/lib.c :
long vid_get_bitmap_buffer_width() { return 720; } // _sub_FF8EA47C__BmpDDev_c__134

the same value (0x2D0) can be found in the BmpDDev functions of the ixus970, ixus90, sx10. i doubt that this is the "final" indicator for the 720 buffer width in the 990?

[reyalp]

That's strange, the code is definitely storing the dimensions and display address into a to the pointers passed to that function:

Code: [Select]

_sub_FF8EA47C__BmpDDev_c__134 
  ...
                 MOV     R0, #0x2D0      ; 720
                 MOV     R1, #0xF0       ; 240
                 STR     R0, [R4]        ; *arg0 = width
                 STR     R1, [R5]        ; *arg1 = height
                 STR     R0, [R6]        ; *arg2 = width
                 LDR     R0, =0x40471000 ; bmp base
                 STR     R0, [R7]        ; *arg3 = base
                 MOV     R0, #1
                 STR     R0, [R8,#0xC]   ; *(0x7D98 + C) = 1
                 MOV     R0, #0
                 LDMFD   SP!, {R4-R8,PC}
The code later in sub_FF9C3654 uses those values to calculate the address of the second bitmap buffer. See around FF9C36B4

You are sure those other cameras do not also have a 720 bmp ? Or perhaps the code is present in recent cameras, but only used in those that have the larger bitmap ?

[snc]

Hmm, well as far as I can tell, the code matches with the one in the sd890.

The function @ FF8EA47C in the sd990 matches up with FF8EA99C in the sd890.
Likewise, the area @ FF9C36B4 of the sd990 matches with the area @ FF9AE31C in the sd890.

Obviously, the bmp base address is different, and instead of *(0x7D98 + C) it uses *(0x7EC4 + 14).

Well, to be honest, judging from the code, i am not so sure anymore the sd890 has a bmp buffer width of 360... Just i found it weird, so yesterday night i tried vid_get_bitmap_screen_width and vid_get_bitmap_buffer_width both with 720. Results were really quite bad... Maybe vid_get_bitmap_buffer_width alone should be set to 720? Sure seems strange, will give it a shot later on, just to be certain.

[ewavr]

The same code (with 720 and 240) exists in SX100, G9, S5IS, SX10, but all of them work well with 360x240 bitmap size.

[ewavr]

@reyalp:

Shooting override works correctly for SD990, if shoot button is pressed quickly?
For SX10 we have in this case real shutter speed from camera settings... and CHDK shutter speed in  JPEG EXIF  .

[reyalp]

@ewavr: will test

multipartition support added
12 bit raw stuff from ewavr
diff is now against rev #720