CHDK Forum
CHDK Development => General Discussion and Assistance => DryOS Development => Topic started by: jak5280 on 18 / January / 2009, 11:24:17
-
Is anyone out there working on a port to the SD990 - I would like to help by testing builds.
-
http://chdk.wikia.com/wiki/IXUS980IS (http://chdk.wikia.com/wiki/IXUS980IS)
-
Well this looks as good a place as any to post porting related information:
The memory layout is changed a bit from from the Digic II and III cams:
regions 2 and 3 (corresponding to cached and uncached views of main memory) are 128M instead of the 32M or occasionally 64M found on current CHDK cameras.
region 3 is located at 0x40000000 instead of 0x10000000
The data TCM, which usually lives at 0x40000000 is bumped up to 0x80000000
Interestingly, this bit of code which on other cams sets SP to the data TCM still uses the old address
ROM:FF810194 LDR SP, =0x40001000
ROM:FF810198 B loc_FFA48FC0
:o
Stuff I have found (all unverified!)
ROM:FF810130
canon_data_src = (void *)0xFFB74B98;
canon_data_dst = (void *)1900;
canon_data_len = 0xFE80 - 0x1900;
canon_bss_start = (void *)0xFE80;
canon_bss_len = 0xE8B40 - 0xFE80;
from sub_FFAAFEBC:
CRAW BUF SIZE 0x1574D00 (A bit too large for 10 bpp, maybe 12bpp = 14999040 raw pix 4480*3348 sensor ?)
CRAW BUF 0x40EBAFA0
ROM:FF821894 task_PhySw
physw_run
1C28 (1C1C + C) ?
ROM:FF8219DC ShowPhySwStatus
physw_status 0x11318 ?
Possible LED addresses from sub_FF8EB458 ?
0xC0220134
0xC0220130
0xC0220138
0xC02200B0
0xC02200BC
-
Well this looks as good a place as any to post porting related information:
The memory layout is changed a bit from from the Digic II and III cams:
regions 2 and 3 (corresponding to cached and uncached views of main memory) are 128M instead of the 32M or occasionally 64M found on current CHDK cameras.
region 3 is located at 0x40000000 instead of 0x10000000
The data TCM, which usually lives at 0x40000000 is bumped up to 0x80000000
...
Yeah, noticed the same on the SX10 some time ago( wikia - SX10#main.c (http://chdk.wikia.com/wiki/SX10#main.c)) ...
"MOV R0, #0x80000006\n" // all others have 0x4...
-
any updates yet?
-
lib.c
void *vid_get_bitmap_fb()
{
return (void*)0x40471000; // dispcon* functions and BmpDDev.c
}
void *vid_get_viewport_fb()
{
return (void *)0x407F6DC0; // search on VRAM Address
}
void *vid_get_viewport_fb_d()
{
return (void*)(*(int*)0x525C); // sub_FF85AF14 0x5210 + 0x4C
}
char *camera_jpeg_count_str()
{
return (char *)0x4AF18; // search on "9999"
}
stubs_min.s:
DEF(physw_status, 0x11318) // 0xFF8219DC ShowPhySwStatus
DEF(physw_run, 0x1c28) // 0x1C1C + 0xC @0xFF821894 task_PhySw
DEF(FlashParamsTable,0xFFB499F4) // sub_FFA58670, search for ParameterManager.c
DEF(zoom_busy, 0x8A1c) // 0x8A08 + 0x14, found in sub_FF93368 search on "ZoomLens"
DEF(focus_busy, 0x8914) // 0x890C + 0x8, via _sub_FF92E770__FocusLensController_c__201 and comparison to s5is
DEF(movie_status, 0x53DC) // 0x53A0 + 0x3C? via loc_FF861EAC and _sub_FF860E64__MovieRecorder_c__0
I've also got enough of boot.c to get to spytask and physw task startup, stubs_entry.S generated (but not checked), loader basically done, and everything else with enough dummy values to compile.
Some of the above are probably wrong, since they are all untested.
The sensor size I listed earlier appears to be correct based on other parts of the firmware.
Basically waiting on the camera now.
-
So, if the sensor records images with 12 bit per pixel, enabling the RAW format would be a great advantage over 8bit JPEG, right? Can't wait for this to happen..wish I had the skills to create the port. I have the camera though, so if anything is needed I can try to help...
-
So, if the sensor records images with 12 bit per pixel, enabling the RAW format would be a great advantage over 8bit JPEG, right?
Depending how much of that is usable signal, rather than noise. The other downside is that CHDK currently assumes 10 bit raw, so it will take more effort to get working. sharky has done some work on 12 bit raw support for the SD770 http://chdk.setepontos.com/index.php/topic,2841.0.html (http://chdk.setepontos.com/index.php/topic,2841.0.html)
I still don't have the camera yet, but I've been making progress on things that can be done from the firmware dump alone. All of the stubs_entry.s entry points are checked now, and from the few propcase calls I've looked at, it appears to still use propset 2.
-
I would love to help in testing as I have no programming skils, my firmware is GM1.00E and I have CHDK running on my SD500 and SD900 (beta also testing)
The 990 with the addition of manual and IS seems like a good camera for the added fratures of CHDK. The 990 will be a joy to use
-
I have the camera now, so this will be the official porting thread. It currently loads far enough to run an LED blinking task :)
As soon as I have something that people can test, I'll upload it.
edit:
LEDs
0xC0220134, // green
0xC0220130, // orange (right)
0xC0220138, // yellow (left)
0xC02200B0, // power
0xC02200BC, // dp
AF assist not found yet
and spytask loads, although I'm not sure what's up with the 4x tiled bootsplash:
edit:
and a 4 way menu, physw_task is working enough to navigate the menu and override card lock.
edit:
720x240 bitmap display looks better, chdk logo is still messed up, color pallet appears to be different. Canon advertises a "23000 dot display" (720x320 ?) but perhaps this applies to the live view and not the bitmap.
edit:
Setting both the screen size and buffer size helps ;)
-
Wow, that's great news. Sounds like it won't be long now and Canon's best compact camera will get the features it deserves. Many thanks already to you, reyalp :-)
I guess mszaller (in this thread http://chdk.setepontos.com/index.php/topic,3005.0.html (http://chdk.setepontos.com/index.php/topic,3005.0.html)) will be happy to hear the progress, too :-)
-
Reyalp,
I'm keen to test things as soon as you get something working. I'm very appreciative of your efforts.
-
No screenshots, but making progress.
UI/OSD is pretty much fully functional. Zebra is broken.
CaptSeqTask runs, raw is captured (22.5 MB each, saves surprisingly quickly) but only every other shot goes to the address I'm using. Need to find the variable that controls this.
Optical zoom in video works.... sometimes.
lua libtest runs without errors.
-
Amazing! That's quick progress. There are many "first-times" with this camera, right? Digic IV, 15MP, 12 bit RAW files (if the last 2 bit (compared to SD770) contain some information other than noise) and maybe even manually adjustable aperture? I hope it is (and keeps being) fun for you, as it seems like without you there wouldn't be a port for this camera for a long, long time...
Thanks!
-
No manually adjustable aperture, only an ND filter. That part is the same as the other ixus. There are some difference from other cameras, but nothing too huge so far.
The raw files aren't really usable, because there aren't any programs that know how to convert them. I've just been using irfanview "open as->raw" to see the pixel values. I can tell if it's the picture I took or random memory garbage, but that's about it.
-
The raw files aren't really usable, because there aren't any programs that know how to convert them.
Maybe is possible to convert 12 bit RAW to 10 bit (converter (http://ewavr.nm.ru/chdk/12to10.zip)), then use DNG4PS2 (see ixus85 topic on page 5) or modified DCRAW.
-
hmm...I also read in sharky's SD770 thread that it's difficult to create a usable RAW file without knowing anything about the used color spectrum (or manually creating a calibrated profile). Is this the same with every CHDK release or can the older, more mature chdk releases really get a usable RAW file out of the ixus?
-
Is this the same with every CHDK release or can the older, more mature chdk releases really get a usable RAW file out of the ixus?
yes 10 bit raw images are usable on my SD 500 and SD900(CHDK Beta)
-
hnikesch, sounds good. Did you have to do any manual color calibration or did a standard Canon profile work as well?
-
hmm...I also read in sharky's SD770 thread that it's difficult to create a usable RAW file without knowing anything about the used color spectrum (or manually creating a calibrated profile). Is this the same with every CHDK release or can the older, more mature chdk releases really get a usable RAW file out of the ixus?
dng4ps and dcraw (along with various programs that use the dcraw source) handle the 10 bit CHDK raw fairly well for the most part.
12 bit RAW will need the same sort of thing. dcraw actually supports 12 bits for some cameras, but the code makes my head spin.
-
hnikesch, sounds good. Did you have to do any manual color calibration or did a standard Canon profile work as well?
I have only used Raw Therapee and it handled the images without any changes right after install, nothing special for the camera
-
Okay, sounds good. I must admit, I don't know much about about RAW yet, so I'll need to wait for the first "beta" release of reyalp's port to try things. I owned all the predecessors of the ixus 980 but learnt about CHDK only 3 weeks ago when I already had the 980...
dcraw (at least dcraw-x for the Mac) seems to be pretty outdated, last updated in 2005...from a "supported cameras" aspect, I can't see a difference between dcraw, Adobe Photoshop and Aperture...maybe one of those programs can handle the RAWs that are created by the SD990 sensor...
-
Raw Therapee uses dcraw code for raw loading.
maybe one of those programs can handle the RAWs that are created by the SD990 sensor..
Converting raw sensor data into what a human perceives as an accurate representation of the scene requires an arbitrary transformation of the data. This is not something that any program will magically know how to do.
-
and it's also really true that even every Canon camera uses a totally different way of saving RAW files? So even the PowerShot G1-G10 that are supported by Photoshop each use a different format and there's no chance it may be identical with that of the SD990? Too bad.
But buying a professional color chart and using a program to calibrate to the SD990 files could be done right? I'd do that and upload the profile if helpful.
-
Got the raw buffer fixed today. Interestingly, the border pixels of the raw aren't 0 like they are with my a540.
I've uploaded a sample raw (along with the corresponding jpeg) at http://www.zshare.net/download/560430458d0657df/ (http://www.zshare.net/download/560430458d0657df/)
for anyone who wants to work on conversion software. 4480*3348*12bpp, packed, little endian, bayer unknown.
Also fixed Tv bracketing.
Weekend is over, so don't expect to see much more for a bit.
-
I've uploaded a sample raw (along with the corresponding jpeg) at http://www.zshare.net/download/560430458d0657df/ (http://www.zshare.net/download/560430458d0657df/)
for anyone who wants to work on conversion software. 4480*3348*12bpp, packed, little endian, bayer unknown.
Here is my modification of dcraw: http://www.zshare.net/download/561154003d8febab/ (http://www.zshare.net/download/561154003d8febab/)
Color matrix from A650 (not good).
How about color chart image (http://code.google.com/p/dng4ps2/wiki/HowToCalculateCM)?
edit: updated
-
reyalp, is it already possible to upload the chdk "alpha" version or are there too many loose ends? I could take a photo of this colorchart ewavr mentioned on a probably good screen (iMac 24"). The adapted dcraw is another great piece of the puzzle :-) Thanks, ewavr!
-
I should be able to upload something this weekend.
Discovered the live viewport is still 360x240, even though the bitmap is 720x240. This means zebra, edge overlay and histogram will all need changes in the core :( The canon firmware has a live histogram, so that one isn't so important. Both the record and playback dynamic viewport addresses are found now.
Played with the dng4ps2 calibration stuff (using 12to10 ewavr posted earlier) , but I must be doing something wrong in the image or calibration. AFAIK monitor quality shouldn't matter, since you de-focus anyway.
My attempt at a calibration image is at http://www.zshare.net/download/56297358d73b1dce/ (http://www.zshare.net/download/56297358d73b1dce/)
As one would expect from the number of pixels and sensor size, the sd990 is very noisy, even at ISO 80.
-
Quick-n-dirty matrix (before 'official'): 0,837237 -0,290137 -0,128156 -0,127762 0,643909 0,052973 0,004446 0,088354 0,224246
Dcraw with this matrix - http://www.zshare.net/download/563001452023e519/ (http://www.zshare.net/download/563001452023e519/)
-
Nice ewavr. Did you do this with dng4ps2 ? If so, can you describe how ?
Here's a test build. This should regarded as an alpha. It is NOT a complete working port. Use it AT YOUR OWN RISK. If you do not accept a small chance it will completely destroy your camera, DO NOT USE IT.
Here's some information about this build. Please note this is NOT a complete list, it's just whatever I know or remember off the top of my head. I've also attached a patch against svn 714. This is for any other developers interested on working on the port. Be warned that this is work in progress, and has random debugging code scattered around.
General info:
Digic IV, dryos, propset 2 (there may be digic IV specific stuff, but nothing found so far)
14.7mp raw 4480*3348 12 bits/pixel
Video is h264 NOT mjpeg
ND filter only, NO iris
Booting:
Encoded diskboot required, FI2 "firm update" supported.
With diskboot camera will always boot in play mode. Press halfshoot to switch to record.
With FI2, you must boot in play mode in order to access the firm update menu.
Display:
Live view is 360x240
Bitmap buffer is 720x240
Bitmap color palette is different from other cameras. You should configure CHDK colors (visual settings) to ensure everything is visible.
Buttons:
Direct print button is the ALT button. This can be assigned a function in the
original canon firmware. Hold it down to access the canon firmware function
Other keys use the standard mapping for cameras without an erase button.
Features known BROKEN or NOT supported:
DNG
RAW operations (sum, average, subtract)
shot_histogram
bad pixel removal
Zebra
Histogram (use built in live historgram instead)
Edge overlay
Custom curves
Motion detection
video overrides
Multiparition support
LED script control
Microphone mute/unmute
Raw buffer cached
Jogdial control from CHDK
Play button control
Many other things are untested.
-
Did you do this with dng4ps2 ? If so, can you describe how ?
Yes, using dng4ps2 as described in Wiki (http://chdk.wikia.com/wiki/DNG4PS-2/Calibration).
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).
-
Wow! This will be a nice Sunday just playing around with the camera...amazing work so far!
-
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
-
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.
-
- 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 (http://www.zshare.net/download/56420971e208f8a5/)
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 (http://www.zshare.net/download/564241170ecc5dc6/)
-
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.
-
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,
-
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.
-
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.
-
@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?
-
That's strange, the code is definitely storing the dimensions and display address into a to the pointers passed to that function:
_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 ?
-
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.
-
The same code (with 720 and 240) exists in SX100, G9, S5IS, SX10, but all of them work well with 360x240 bitmap size.
-
@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 :o.
-
@ewavr: will test
multipartition support added
12 bit raw stuff from ewavr
diff is now against rev #720
-
@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 :o.
Yes, same problem. I see the code you put in sx10 to workaround this, I'll have a look at that.
When I was doing capt_seq, I looked at a few different cameras, and it some of them seemed to have roughly the same code but put the hooks in different places. I picked the one that looked most similar/easiest, but unfortunately I don't remember which one I used as a model. :(
edit:
Also saw taskCreateHook2. Is there some problem I should check for to see if I need this ?
edit:
workaround from sx10 helps, but doesn't work if flash is triggered ???
example:
set Tv override to 1/4 in auto mode, flash disabled
- half press, then shoot = Tv 1/4
- quick press = Tv 1/4. Before fix, this would give auto exposure value.
as above, but flash set to auto
- half pres, then shoot = Tv 1/4, no flash
- quick press = Tv 1/60, flash fires
Maybe we should do overrides later
-
Also saw taskCreateHook2. Is there some problem I should check for to see if I need this ?
Sometimes InitFileModules is not hooked (p[0]=(int)init_file_modules_task statement executed, but has no effect).
Hooking InitFileModules in taskCreateHook2() works when camera is powered on in playback mode.
Hooking InitFileModules in taskCreateHook() works when camera is powered on in record mode.
Maybe because InitFileModules is created using CreateTask() function, but all other task (hooked by CHDK) using KernelCreateTask() function?
I don't like it.
workaround from sx10 helps, but doesn't work if flash is triggered ???
Same thing on SX10
edit:
quick press = Tv 1/60, flash fires
SX10: 1/4 s, flash fires
-
I think the "task hook" isn't really a task like we have in vxworks. 0x1930 and 0x1934 called in the IRQ handler, I don't understand how it works ???
I don't have SD990 starting in record mode yet.
-
Hey guys! First post here.
I just ordered a Canon SD990 IS to replace my ancient Olympus D-100 (1.3 megapixels! Cellphone cameras can do better than that now! :lol)
Anyway, I knew I wanted a Canon ever since I found out about CHDK (quite some time ago).
I wish you luck with your porting endeavor, and I can't wait for the final build!
I might even try out the test build when my camera arrives.
-
Raw, auto iso, OSD displays and bracketing make the beta usable and already fun to use try it when you get your Cam
-
Sounds good so far! I'll definitely try it out.
-
I also just ordered a 16GB SDHC card... I'll split it into two partitions for use with CHDK.
-
I am using CHDK on my sd990! How great!
I decided to make a USB remote button, and can't get it to work. Has anyone else gotten a USB button working with this camera?
-
Pixeldoc got it to work on a SD900 but it required 3.5V unlike some other cams that only needed 1.5v
-
Pixeldoc got it to work on a SD900 but it required 3.5V unlike some other cams that only needed 1.5v
I got an LED flashlight that takes three 1.5 V button cells, so I should have 4.5 V. The flashlight seemed to be wired backwards to me, so maybe I do have it wrong. Unfortunately I can't fit my multimeter leads into the mini-USB socket to see what's going on. The multimeter did report that each cell only seems to give 1.3 V, so maybe I should try either new batteries or get the LED flashlight with four button cells in it.
Here's a stupid question: what if I plug in the camera to a USB charger to try to give it the signal? I'll of course check the voltage first! I tried this, and was able to get it to work this way. (Also by plugging and unplugging the camera from my computer!) Either my wires are crossed or my batteries are too low to make it work with the flashlight.
On a side note, I added info about the colors of wires 1 and 4 to the CHDK wiki. I chose to cut up a USB cable to make a rather sleek looking button.
UPDATE: I got it working. Here are short instructions http://sites.google.com/site/canonremotehowto/ (http://sites.google.com/site/canonremotehowto/)
-
Just ordered two of these cameras to make a 15MP stereo rig...Has anyone else done this? I'm new to all this and looking forward to working through the details, though I probably won't be much help at first...Thanks to all those who are making this possible for the rest of us to get our feet wet with well synchronized water droplets.
-
So what do you guys think of the SD990? I don't really have anything to compare it to, but the pictures seem a little noisy to me and I'm wondering if I should have picked a different model instead of going for the most megapixels.
I've put CHDK on my SDHC card. I haven't tried out its features yet, but just the more accurate battery meter makes it worth it! I've got a 16 GB card which I had to partition for CHDK to work, but the second partition (where all the photos are stored) won't show up in Windows, so I have to boot from a Linux CD to get my photos off the card. It's a bit of a hassle, but carrying around multiple SD cards instead would be a hassle as well. The only problem is that when I'm not running CHDK, the camera stores pictures on the first partition, which is tiny (23 MB). Is there a way to get the camera to store pictures to the second partition when not running CHDK? Is there a way to get Windows to detect the 2nd partition on the card?
-
I haven't seen the camera yet, but I would imagine that if the quality was an issue. the G10 would be the next step up, but sacrificing the compact size, of course...I also like the wider zoom range of the G10...Now that the SD990 porting is underway, does it make it easier for the brains on this board to tackle the G10? I must say, Cannon needs to know that people are making purchasing decisions based on the good work everyone is doing here...Do they help? Has anyone asked them for help?
-
So what do you guys think of the SD990? I don't really have anything to compare it to, but the pictures seem a little noisy to me and I'm wondering if I should have picked a different model instead of going for the most megapixels.
It's very noisy, even at ISO 80, you can see both the noise and the noise reduction. The optics also aren't good enough to give you full resolution at the edge of the picture, and fringing is noticeable. All of this is expected in this size range.
It' is still a very nice camera for a pocket point and shoot. If size isn't critical, you could definitely get more out of a G or SX series. Maybe even an A.
I've put CHDK on my SDHC card. I haven't tried out its features yet, but just the more accurate battery meter makes it worth it!
I'm not convinced the CHDK battery meter is calibrated correctly yet, I just copied the values from some other camera with the same battery. Feedback appreciated.
I've got a 16 GB card which I had to partition for CHDK to work, but the second partition (where all the photos are stored) won't show up in Windows, so I have to boot from a Linux CD to get my photos off the card. It's a bit of a hassle, but carrying around multiple SD cards instead would be a hassle as well.
You can use the "swap partitions" command in CHDK to make the large partition the first one (aka the only one windows sees). Of course, the next time you boot CHDK after that, you have to load it with the firm update menu. Make sure you have the ps.fi2 on both partitions!
You should be able to use the firm update method without re-partitioning the card at all. (note that some outdated parts of the wiki say you can only use diskboot.bin with dryos cams. This is no longer true since we have fi2 support)
There are some hacks that let windows see multiple partitions on an SD card, but it's a pain.
You can also use USB transfer from the camera of course.
ddd:
Staying under canons radar is in our best interest, I certainly wouldn't ask them for help! The G10 will be ported when a developer has one.
-
So what do you guys think of the SD990? I don't really have anything to compare it to, but the pictures seem a little noisy to me and I'm wondering if I should have picked a different model instead of going for the most megapixels.
It's very noisy, even at ISO 80, you can see both the noise and the noise reduction. The optics also aren't good enough to give you full resolution at the edge of the picture, and fringing is noticeable. All of this is expected in this size range.
It' is still a very nice camera for a pocket point and shoot. If size isn't critical, you could definitely get more out of a G or SX series. Maybe even an A.
Oh size is definitely important for me. I want a small camera that can fit in my pocket. How does the SD990 compare to the other SD's in terms of image quality?
I've got a 16 GB card which I had to partition for CHDK to work, but the second partition (where all the photos are stored) won't show up in Windows, so I have to boot from a Linux CD to get my photos off the card. It's a bit of a hassle, but carrying around multiple SD cards instead would be a hassle as well.
You can use the "swap partitions" command in CHDK to make the large partition the first one (aka the only one windows sees). Of course, the next time you boot CHDK after that, you have to load it with the firm update menu. Make sure you have the ps.fi2 on both partitions!
Ok thanks! I'll try that. So I need ps.fi2 on both partitions... do I need diskboot.bin on both partitions or only the small one?
You should be able to use the firm update method without re-partitioning the card at all. (note that some outdated parts of the wiki say you can only use diskboot.bin with dryos cams. This is no longer true since we have fi2 support)
Wait... so I didn't need to split my card if I don't want to boot immediately from CHDK?
-
Ok thanks! I'll try that. So I need ps.fi2 on both partitions... do I need diskboot.bin on both partitions or only the small one?
right, diskboot is only needed on a partition that you are autobooting from. diskboot.bin and ps.fi2 are basically two copies of the CHDK program, just encoded and named differently so the camera will see them as either a bootable image or a firmware upgrade program.
Wait... so I didn't need to split my card if I don't want to boot immediately from CHDK?
Right, if you use the manual load, you don't need a fat16 partition.
-
Ah, I understand now. Thanks very much! Sorry for being such a n00b and also for derailing this thread a bit.
EDIT: I successfully swapped partitions and loaded ps.fi2 onto the large partition. Now when I put the card in the camera, I am able to load CHDK as a firmware upgrade from the large partition. However, it won't let me swap back to the small bootable partition now. Am I doing something wrong, or is this not working properly in the beta yet?
-
I have installed ixus980_sd990-100e-0.9.7.zip.
I found that the auto iso cause incorrect explosure.
The shutter speed looks like follow the old ISO value.
Also, In Scene mode 'ISO3200', auto iso also cannot override the ISO value.
:o :o :o
ISO3200 is a very special mode which has extremely short shutter lag mode and we can take photo at high speed 4fps.
It would be very useful if auto iso can apply to it correctly.
-
@reyalp:
Thanks for working on the port! Already works nicely on my IXUS980IS. And I can't wait to see the remaining issues addressed.
@all:
I used openSUSE BuildService to create versions of dcraw, ufraw and dng4ps2 compiled for various Linux distributions with support for IXUS980IS/SD990. Please have a look at
http://download.opensuse.org/repositories/home:/garloff:/Photography/ (http://download.opensuse.org/repositories/home:/garloff:/Photography/)
(Easiest way to install from there is to subscribe to the repository, BTW, otherwise you have to do dependency resolution yourself ...)
dcraw, ufraw and dng4ps2 all process the CHDK produced .crw files just fine. I hacked 12bit support into dng4ps2 and put ewavr's matrix in there and that works as well.
I tested on openSUSE 11.1 only -- I'm happy to accept patches or .dsc files (in case someone wants the package to build for Debian or derivatives).
-
@garloff
Excuse me. Are you sure the port really has no problem run on your 980IS? Even the auto ISO?
@all
Since I have Photoshop CS4, I can just open the 980IS dng directly without doing any conversion.
Just take out the .dng and open in CS4. My friend has CS3 also has no problem to open 980IS dng.
-
@garloff
Excuse me. Are you sure the port really has no problem run on your 980IS? Even the auto ISO?
I have set AutoISO to max 640 (and to max 1000 with HiISO) in CHDK and I did not notice any exposure issues. I have not tried 3200. Maybe iContrast hides this though.
And no: I did not say that 0.9.7 is perfect yet. I only use a fraction of the functionality and that's pretty useful to me already. (AutoISO, RAW being the two most important ones, along with some extra information in the OSD.)
@all
Since I have Photoshop CS4, I can just open the 980IS dng directly without doing any conversion.
Just take out the .dng and open in CS4. My friend has CS3 also has no problem to open 980IS dng.
There's no CS4 on Linux ... But most tools (including Bibble, dcraw, ufraw, ...) do process DNG just fine these days, so that's the easier way. Colors are slightly different when I compare the conversion from .CRW and the one from .DNG, but I can't say better or worse and you can adjust anyway.
-
@reyalp:
One little bug in the .dng files: The crop factor for this camera is 4.6 (as correctly recorded in the .jpg by the camera firmware), not 6.1 as CHDK seems to think. (The camera has a 1/1.7" sensor, not 1/2.3" like many of the compact cameras -- that's a primary reason why this one performs better than most others.)
-
My cameras just arrived and I must say the 15 MP is surreal. I took a shot of the view out my window and in Photoshop you can zoom in to see detail such as far away tree branches against the sky that you otherwise can not see at normal view...remarkable for such a small camera...Have yet to play around with remote shuttering through chdk.
-
Awol: You should be able to swap back, I've done this on my camera ???
mikemikemike:
Are you trying to use CHDK autoiso or canon autoiso ? What mode are you shooting in. If you can give me step-by-step instructions to reproduce the problem, it's much more likely I'll be able to fix it.
For the shutter speed, the current build also has an issue where if you press the shutter quickly, the shutter override is ignored.
The "3200 ISO" is special (I think it uses binning internally), and relatively new for CHDK supported cams, so I wouldn't be surprised if it breaks things.
garloff:
Thanks. I just guessed the active area for DNG by looking at the raw data. I'll look into that. oops, I totally misunderstood that.
-
-
I'm not convinced the CHDK battery meter is calibrated correctly yet, I just copied the values from some other camera with the same battery. Feedback appreciated.
I use 3975 / 3425 this seems to to work on both my SD900 and the SD990
-
I'm not convinced the CHDK battery meter is calibrated correctly yet, I just copied the values from some other camera with the same battery. Feedback appreciated.
I use 3975 / 3425 this seems to to work on both my SD900 and the SD990 they use the same battery
-
Oh size is definitely important for me. I want a small camera that can fit in my pocket. How does the SD990 compare to the other SD's in terms of image quality?
see attached shots cropped shots from the 990 vs the 900 house is near the end at left of the image, the 990 is a real up grade from the 900 also the 900 is an visable IQ increase over the SD 850
-
-
Yeah, got it it :)
-
-
reyalp, Thank you so much for the good work. I played around with the chdk a little now and was able to shoot amazing pictures, especially with EV bracketing.
What I don't get yet is how to make SDHC cards easy to work with. Whenever I boot from the small partition, chdk boots automatically, as it should, but the camera tries to save photos on the small partition, where there is not enough space. After swapping the partitions, it doesn't boot anymore but has to be loaded manually. I somewhere read that, when booting from the small partition, chdk autmatically selects the bigger partition for saving the photos...is that possible somehow with the current build?
Again, thanks so much, also for all the others that contribute so nicely!
-
reyalp, I just repeat to try run the auto iso and it looks like working has no problem.
Most likely I was always use ISO3200 with auto iso which will cause inconsistent effect to the camera.
Also, I have tested MF override and it also works without problem. This made the MF very useful to this camera since I can snapshot a known distance object lighting fast.
Thank you for your great work.
Also, may I know how to get more information on how to develop CHDK for SD990? I know C language but I really have no idea how to develop CHDK. Can you show me how to get more information??
-
Also, may I know how to get more information on how to develop CHDK for SD990? I know C language but I really have no idea how to develop CHDK. Can you show me how to get more information??
There's really no shortcut to understanding the code if you want to work on it.
The wiki http://chdk.wikia.com/wiki/For_Developers (http://chdk.wikia.com/wiki/For_Developers) can help you get started.
http://chdk.wikia.com/wiki/Modifying_the_CHDK_Sources (http://chdk.wikia.com/wiki/Modifying_the_CHDK_Sources) gives you a rough overview of the source.
A lot of the camera specific stuff requires you to have a decent knowledge of ARM assembly and how the canon firmware works.
-
reyalip, Thank a lot for your information.
I have played with CHDK for almost 2 days. I keep trying to take RAW from 980IS and comare with the jpg. I find that Canon 980IS output jpg is already very good. Digic IV de-noise is amazing and I cannot see much advantage that the noisy RAW files over camera jpg. (jpg won't loss too much detail after de-noise !)
However, the CHDK auto-iso is really useful for me.
Also, is there any way to hide some CHDK function? Or how can we customize the CHDK menu / or create some shutcut key for fast access?
I think that most of the function in CHDK may not be useful to some users.
-
You can use the "user menu" to create a menu of frequently used functions. A search of the forum or wiki should find instructions. Feature requests or questions not specific to this port should go in their own thread in an appropriate forum.
As for raw, if you are happy with the jpeg there's no reason to use it. Raw gives you more control and slightly more dynamic range at the expense of much more complicated workflow.
-
Hi there,
I'm sorry to be asking this question. N00b that I am.
Where can I download a release of CHDK for the 980IS? I've read every page of this thread and can't find a link. I have found the firmware dumps and have extracted PRIMARY.BIN but did not get this to boot on my SD card - so I guess this is not the right file?
Sorry again...
Scott
-
@scotia
post #29 on page 2 of this thread has the link... you need to be
logged in to see it...
wim
PS ...and welcome to the forum
-
@scotia:
Actually, you'll want to download the .zip from comment 44 on page 3 as well and copy the bootloader/ps.fi2 from there over the ones you extracted from the other files.
-
@whim,@garloff:
Thanks guys,
problem was I wasn't logged in... derr...
Got it all up and working - many thanks to the developer(s). Fantastic work.
Scott
-
Good stuff, been watching Chdk for some time now... found out about it from Lifehacker.com way back when. I bought the canon sd990 back in december because it was top of the line compact with hopes it would be chdk'd one of these days. Glad to see it's well on it's way, thanks for all the hard work!
-
Help my camera wont update the firmware anymore!
I was using the sd990-test-3.patch and it was working great. I decided to see what voltage the camera would shutdown at, so I let it shut itself down while doing a video and now I cannot load the firmware anymore...When it asks if I would like to update and I click 'ok' it shuts down within 1 second. I tried reloading the firmware on my sd card and using a different sd card which worked before with the firmware update and no luck. Any ideas??? I really want to use this!
-
Here are battery voltage settings that represent well the state of the battery: max=4025, min=3375 (milliVolts)
The camera shuts down at ~3350.
The CHDK battery indicator is much better than Canon's, BTW. The Canon one shows a full battery until there's <~25% capacity left.
-
Mine shutdown at 3.25volts. But now it wont work with CHDK anymore...Reference my post above for more details. Please help!!!
-
I am wondering if this could be a ram issue...Is there any way to clear the cameras internal ram(not the cameras firmware)?
-
I got it working! Keep up the great work on this, I really like what you have done so far!!!
-
Hello.
I've been hard-testing this week the 15th march version (mostly DNG) and I 've got very improved results, mostly about hot pixels.
Quite interesting. What kind of software did you use to get this improved results over JPEG?
-
Hello,
Many thanks for reyalp & co for amazing work!
Can someone explain what is the purpose of sd990-test-3.patch and how to use it?
-
Gurus,
I've built cross toolchain (on Linux) with binutils-2.18 and gcc-4.3.3 as described.
Building chdk for ixus980, I now get the failure that the processor would not support the "BLX R12" assembly instruction (in boot.c).
Is passing mcpu=arm946e-s -mfpu=fpa the right remedy? As I don't know the hardware, I'm especially doubtful on -mfpu=fpa ... Does the processor have an FPU? If so, shouldn't it be an vfp9?
-
Is passing mcpu=arm946e-s -mfpu=fpa the right remedy? As I don't know the hardware, I'm especially doubtful on -mfpu=fpa ... Does the processor have an FPU? If so, shouldn't it be an vfp9?
Well, it compiles, but crashes on the camera. Not passing any -mcpu/-march switch (as it always seems to imply something about FPU availability that's not right) and then recompiling the single file that fails (boot.c) with -march=arm5vte to avoid the blx r12 message does the trick for me. I doubt that this is ideal or even clean. Resulting FW then works. (I have battery voltage limits and EFL corrected ...)
-
Is passing mcpu=arm946e-s -mfpu=fpa the right remedy? As I don't know the hardware, I'm especially doubtful on -mfpu=fpa ... Does the processor have an FPU? If so, shouldn't it be an vfp9?
Well, it compiles, but crashes on the camera. Not passing any -mcpu/-march switch (as it always seems to imply something about FPU availability that's not right) and then recompiling the single file that fails (boot.c) with -march=arm5vte to avoid the blx r12 message does the trick for me. I doubt that this is ideal or even clean. Resulting FW then works. (I have battery voltage limits and EFL corrected ...)
There is a long thread on gcc 4 confguration here (never mind the windows parts)
http://chdk.setepontos.com/index.php/topic,2500.0.html (http://chdk.setepontos.com/index.php/topic,2500.0.html)
FWIW, the camera does NOT have an FPU.
Sorry I've been quiet lately on this thread, Real Life has been keeping me extremely busy. I should have a bit more time soon.
-
Hello,
Many thanks for reyalp & co for amazing work!
Can someone explain what is the purpose of sd990-test-3.patch and how to use it?
It's a patch against the CHDK source tree. Since you didn't recognize this, it's unlikely to be any use to you. If you want to use CHDK, use the build included in the zip.
-
Thanks!
-
Anyone know how to make a motion/lightening script or better yet where I could find one???
Thanks
-
Anyone know how to make a motion/lightening script or better yet where I could find one???
Thanks
I ran MDFB (digic III version) successfully. http://chdk.setepontos.com/index.php/topic,471.0.html (http://chdk.setepontos.com/index.php/topic,471.0.html)
-
I still feel like an idiot with CHDK, most of the talk around here just confuses the hell out of me, which is frustrating because I like to think I'm an advance tech geek, maybe it's all the unfamiliar camera terminology!
I appreciate all the hard work you've put in reyalp, can't wait to see the final product, I hope it to be a sweet product, with all the best scripts et al bundled together ready to go!
i5xSwipe
-
I appreciate all the hard work you've put in reyalp, can't wait to see the final product, I hope it to be a sweet product, with all the best scripts et al bundled together ready to go!
It will be like any other CHDK build.
I've finally got some time to work on it again, so here's a new build.
main changes:
- optical zoom in video. No mute yet and the zoom motor is really loud!
- workaround for fast click of full shoot. The workaround will only be used if sv or tv override is in effect. Note, whitebalance appears to be different with or without the workaround. Also, I'm not sure if it works right with flash or not. However, tv/sv overrides with automatic flash don't make much sense anyway.
- adjusted fl_tbl
- tweaked battery high/low values. Note, these are stored in cfg, so unless you reset your cfg you won't see any change.
- enabled scripted LED support
I've also included (#ifdef'd out, under the define CAPTSEQ_MSG_LOG) some code for recording the sequence of values the main loop of capt_seq_task pulls from the message queue. This is messy and won't go into the trunk, but maybe someone will find it useful. Note, this will hang you cam in movie mode.
attached are patch and full build.
-
I will give new build a try, last build worked for the stuff I need. I leave it running, Added some display items, also use bracketing, custom auto iso, user menu, and a little RAW
-
beta version is merged into the trunk. This will appear on the autobuild server soon, and be functionally the same as the last build I posted here.
-
Quite interesting. What kind of software did you use to get this improved results over JPEG?
I always process DNG on Adobe Camera Raw over PS Elements, and Photomatix Pro when HDR.
Noise is a pity, but it can be eliminated via plugins.
Greetings
-
A quick and dirty timelapse I took the other day http://www.youtube.com/watch?v=6XlZkYThklI#hd (http://www.youtube.com/watch?v=6XlZkYThklI#hd)
custom lua script loosely based on http://chdk.setepontos.com/index.php/topic,2589.0.html (http://chdk.setepontos.com/index.php/topic,2589.0.html)
-
ISO override from the CHDK menu or script appears to only go up to effectively 800, despite showing ISO 1600 (or whatever) in the UI and exif.
The override definitely does change the ISO in the 80-800 range, but everything higher than 800 looks exactly the same.
A manual mode shot with the same settings and ISO 1600 is much more exposed.
I haven't tried comparing raws yet, but that's next.
-
Updated in trunk (get it from the autobuild server http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/))
Jogdial support. This means you can script the jogdial, and it'd disabled when you are in alt mode
Power up to shoot mode: just hold the power button down a bit longer
edit:
and now video quality control. I just blindly modeled it off the SX10 stuff (thanks ewavr :xmas) so I'm not sure if the numbers are right, but it seems to work.
-
Hey together,
first of all - great job... I admire you guys doing all that complicated work. Thanks for porting it to the SD990.
Today I got my SD990/IXUS980 and I downloaded the beta version to try it out. I split the SDHC card (32GB), first partition 200MB FAT16, second partition the rest FAT32. DISKBOOT.BIN/PS.FI2 on the first partition, CHDK on the second, big one. Since I did not find a way to switch the camera on in play mode, I decided to do the BOOTDISK method by editing partition one. This worked, the cam boots into CHDK. It also stores pictures although the SDHC card is switched to LOCK (of course, otherwise it would not boot).
BUT - these pictures are all stored on the first, small FAT16 partition, nothing on the big FAT32 partition. Why? It must recognize the FAT32 because there is the CHDK file structure and I guess it would not work without this. I can press the direct print button to get into ALT mode, go through the menu... I didn't try mode, but definitely, pictures and movies go to the small partition.
Is this my fault? I cannot find any more hints about that.
Thanks a lot anyway, this is a great thing.
Torben
-
kic:
I'm not sure why the pictures would be stored on the first partition. When CHDK loads, it should autodetect the larger partition and switch to that. I know this worked with the 8gig card I had set up. I used various linux tools to partition it, as described on the wiki.
You should also be able to load directly from a FAT32 card (or partition) using the "firmware update" method.
Did you use the build from http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/) or one of the old ones attache to this forum ?
FWIW, diskboot.bin is only used for the autoboot method, and PS.FI2 is used for the "firm update" method. Each one is a complete copy of the CHDK executable, in slightly different formats. the CHDK directory structure should go on the big partitition.
-
Good morning reyalp,
I just played with the file browser and this one as well is showing me my 200MB FAT16 content, where - on boot - a CHDK folder is created. I deleted it there later using my finder, but after booting the camera it is there again. No contents, just directories. Only 200MB in total, it does not touch the rest of the card. But the camera itself very well recognizes the big card, without modifications it says I have room for 8343 pictures :)
Strange, auto-booting works, CHDK itself starts, but does not find the contents of the FAT32 partition and does not store pictures there.
I have no idea where to go from here, if you need any debugging help for this, let me know.
Oh, and yes, I used the http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/) firmware. Tonight I might try my own build (the pipeline works completely including IV/KEY extraction thanks to ewavr), so if you want me to put in some debugging code, let me know.
Need to run to work! Cheers and thanks,
Torben
PS: How do I start in PLAY mode so the camera would detect the FI2 file without me making any modification to the card formatting? I have not found a way to do this.
-
G I deleted it there later using my finder
Mac ? Possibly a clue there.
but after booting the camera it is there again. No contents, just directories.
Yes, CHDK creates most of it's directory tree if it doesn't exist.
Only 200MB in total, it does not touch the rest of the card. But the camera itself very well recognizes the big card, without modifications it says I have room for 8343 pictures :)
That's very strange. It sounds as if your 200mb partition is marked as fat32 even though it is actually FAT16.
I have no idea where to go from here, if you need any debugging help for this, let me know.
It's something specific to your partition setup. The partition detection and switching code is common to all the CHDK cameras that support multi-partition. I've returned the SD990 to it's rightful owner (hence the flurry of late night commits ;)), and my own camera does not support SDHC, so I'm not sure how much debugging I could do.
PS: How do I start in PLAY mode so the camera would detect the FI2 file without me making any modification to the card formatting? I have not found a way to do this.
Put PS.FI2 on the root of the card.
Power on using the play button.
Choose "firm update" in the menu.
If the FI2 isn't detected, your mac is doing something strange to the copied files. This isn't unheard of. See http://chdk.wikia.com/wiki/FAQ/Mac (http://chdk.wikia.com/wiki/FAQ/Mac)
-
reyalp, thanks a lot! It is now working.
I guess the missing step was setting the pid to 1. That is what I haven't known and of course did not do. But on the mac page it is explained.
Sorry for that, really... but I promise I searched - just not specifically for mac :) I should have used my Linux server for the partitioning :)
THANKS A LOT again!
Torben
PS: My partition was displayed as FAT16 (200MB), now I made 4MB only and it became a FAT12, but it is working with FAT12 :)
-
Great! The instructions for Mac really worked. Now I can use the big partition for storing photos and videos, too. I think the important step is to not include the CHDK folder on the first partition but only on the second, larger one. However, fantastic work, reyalp! Video quality settings are a great new feature, too...
-
Hey guys! First post here.
My english is very bad.
Thank you for your great work reyalp.I have a few questions.
1.Why the colors from DNG (raw) is very different compare to JPG.Is this the real color that sensor capture or manual color calibration.
2. I think that efl is incorrect chdk shows 35mm but the real Eq focal lenght is 36-133mm
3.RAW files dont have exif data.
3.DNG vs RAW what do you guys think.
4.When you quick press the shutter it saves only jpeg.
-
Hey guys! First post here.
My english is very bad.
Thank you for your great work reyalp.I have a few questions.
1.Why the colors from DNG (raw) is very different compare to JPG.Is this the real color that sensor capture or manual color calibration.
Manual, see earlier in this thread.
2. I think that efl is incorrect chdk shows 35mm but the real Eq focal lenght is 36-133mm
Rounding. It could be adjusted slightly.
3.RAW files dont have exif data.
Raw files are just the data from the sensor. If you want exif data, use DNG, or keep the jpeg.
3.DNG vs RAW what do you guys think.
You're choice. DNG has almost exactly the same data, except that bad pixels are interpolated over. DNG includes metadata, RAW does not. RAW saves quicker, but few tools know how to deal with CHDK 12 bit raw.
4.When you quick press the shutter it saves only jpeg.
This is a bug. Similar issues have been seen on other cameras, so I'll see what I can do, but as I mentioned earlier, I don't have the camera any more.
-
Hi.
I would like to test the RAW files of the SD990/Ixus980.
I want to find out which applications can open the RAW files.
I don't have the camera yet but I would like to buy it if RAW is usable.
Can someone please upload a RAW file or a variety of files?
P.S. I've got a Mac.
Thanks.
-
Well, CHDK and this forum are really impressive.
Meanwhile, I've found the test CRW by reyalp and also the DNG that was converted from it on a computer.
Unfortunately I can't open the CRW in any of my Mac programs but the DNG opens in Adobe Bridge.
The DNG has really a better quality than the JPEG. The noise at ISO 80 is ok in my opinion and can stay. Just the blurriness in the edges worries me a bit. Does it get better with higher focal length? The fringing can be fixed quite well in Camera Raw, however.
But, my question is, how can I get the camera to save a DNG?
I must admit that I'm new to CHDK, so I have played a bit with it on an old Ixus 750, and did some reading in the forum.
But I can't create the badpixel.bin file from CHDK right on the camera.
Can the Ixus 980 do this?
Has anyone got the badpixel.lua script to work on this camera?
Also, as I understand, I can't create the badpixel.bin file on a Mac. Is there a way to do this?
-
I ran the badpixel.lua on the camera without problems. I don't recall which settings I used, but you should find something in this thread http://chdk.setepontos.com/index.php/topic,156.30.html (http://chdk.setepontos.com/index.php/topic,156.30.html)
-
Thanks for the info, reyalp.
Just for practicing, I followed the steps described there with the Ixus 750 that I've borrowed.
I can start the script and it tells me to be patient and the two LEDs next to the viewfinder are alternately flashing.
This takes on very long, till the battery is empty I'd guess, and in the end the file is not there.
Maybe this camera can't do that?
This experiment makes me a bit nervous about the Ixus 980.
The crucial point is, that I seem to need the DNG files from the Ixus 980, because CRW wouldn't work for me.
Can't I just use a dummy badpixel.bin file and do the retouching in Photoshop?
From what I've found in the forum, I don't really get an idea about this option.
How would that dummy file exactly look like?
-
just formatted my SD card by mistake and had to re-run badpixle script
worked just fine here are the steps
load CHDK to SD card and start CHDK on the camera
start CHDK menu
go to scripting parameters>
load script file (select script file TEST/badpixle.LUA)
close CHDK manu leave (alt) screen on the LCD
Create badpixle.bin (alt) should be on the lower left of lcd screen
depress shutter release and wait
the camera will flash the blue LED one long flash take an image flash the LED again take 2nd image
takes about 1 min
that should do it
good luck
-
Thank you, hnikesch. I still don't have the camera though. Yesterday, I went to a shop to make some testshots.
I brought my own SD card and I thought I could play a little with CHDK on the camera. But I couldn't check the firmware. When I pressed set+disp the firmware didn't show up. I had both the ver.req and vers.req files on the SD card. Can that be a problem? Does anyone have an idea why the firmware check didn't work? That's why I hesitated to load CHDK. But maybe I was just too hasty and forgot to switch to the play mode.
Are there any other known firmwares except 1.00e? A european firmware maybe? The exif data in my testshots only says version 1.00.
Another point is the blurriness in the corners which is quite obvious. Comparing the photos here:
http://www.imaging-resource.com/PRODS/SD990IS/SD990ISA7.HTM (http://www.imaging-resource.com/PRODS/SD990IS/SD990ISA7.HTM)
and here:
http://www.dkamera.de/testberichte/canon/digital-ixus-980-is/beispielaufnahmen (http://www.dkamera.de/testberichte/canon/digital-ixus-980-is/beispielaufnahmen)
- I get the impression that could be too blurry for me. Still, for the small size of the camera, the photos are great and RAW gives a lot opportunities for compensation. When I open the pictures in Adobe Bridge I get all the Camera Raw options for improving the photos.
But compared to the Canon G10, especially concerning the corners, I think I may be happier with the G10.
What do you think?
-
I brought my own SD card and I thought I could play a little with CHDK on the camera. But I couldn't check the firmware. When I pressed set+disp the firmware didn't show up. I had both the ver.req and vers.req files on the SD card. Can that be a problem? Does anyone have an idea why the firmware check didn't work? That's why I hesitated to load CHDK. But maybe I was just too hasty and forgot to switch to the play mode.
You are probably pressing the buttons in the wrong sequence. Press and hold set, then press disp. Subsequent presses of disp (still holding set) cycle through various information. I don't remember if you have to start in play mode or not, but it's probably a good idea.
Are there any other known firmwares except 1.00e? A european firmware maybe? The exif data in my testshots only says version 1.00.
No other firmwares are known at this time.
Another point is the blurriness in the corners which is quite obvious. Comparing the photos here:
http://www.imaging-resource.com/PRODS/SD990IS/SD990ISA7.HTM (http://www.imaging-resource.com/PRODS/SD990IS/SD990ISA7.HTM)
and here:
http://www.dkamera.de/testberichte/canon/digital-ixus-980-is/beispielaufnahmen (http://www.dkamera.de/testberichte/canon/digital-ixus-980-is/beispielaufnahmen)
- I get the impression that could be too blurry for me. Still, for the small size of the camera, the photos are great and RAW gives a lot opportunities for compensation. When I open the pictures in Adobe Bridge I get all the Camera Raw options for improving the photos.
This is the price you pay for a zoom lens in such a small package. You will probably get best results somewhere in the middle of the zoom range, but really my experience with the SD990 is that you only get full resolution in the middle of the image under ideal conditions.
But compared to the Canon G10, especially concerning the corners, I think I may be happier with the G10.
What do you think?
If the the compact package of the SD990 isn't a major factor, go with the G10 (but remember CHDK isn't ported to it yet). The optics will be far less compromised than a compact like the SD990, and you get a real aperture, 5x zoom, native RAW etc.
If image quality was more important than form factor, I'd get the G10 or maybe the SX10. For a pocketable camera that takes decent snapshots, one of the lower end ixus will do almost as well as the SD990 for less money.
-
Thank you reyalp. Sure, it's the size that sets limits for picture quality, but from my old camera I am used to a better size-to-sharpness ratio.
I've got a Minolta G500 which has a similar size as the SD990. The chipsize is 1/1.8", the focal length is 39 - 117 mm and the pictures are overall sharp. And the camera has manual aperture and shutter time settings. But Minolta does not build cameras anymore and I need more than 5 megapixels and a wider angle would also be nice. Coming from that camera, the G10 seems a bit too big for me, while on the other hand I wouldn't necessarily need a "spycam"- sized camera. I'd like a camera at the size of the Panasonic Lumix LX-3 but it's focal range is too small for me.
The pictures shot with the G10 have a great sharpness and tolerable noise at low ISO. But they are also a bit odd. It seems that the camera does not apply much correction of the fringing and other things to the JPEGs.
That maybe a reason why it got such a bad critique here:
http://www.dpreview.com/reviews/canong10/page9.asp (http://www.dpreview.com/reviews/canong10/page9.asp)
So, you are forced to shoot in RAW and do postprocessing in Photoshop.
I opened the test-JPEG from the above article in Camera Raw and really was able to improve the image substantially.
I love CHDK because it gives the opportunity to get everything from the pictures through RAW and manual settings. From shots at low ISO I can get more quality than the camera's built-in digic processor.
Well, I'm quite clueless in the cameraworld at the moment. Sorry, if this gets a bit off-topic.
Which other current Ixus cameras or small-sized Powershot cameras for which CHDK is available can you recommend?
-
rather minor thing here, just sorta curious..
anyone played with grids yet, i tried a few but they were all off skew/wrong size screen im guessing, maybe it was something i did, but has anyone else noticed this?
and if so what size is this screen compared to others?
edit:
hrmm I did find this on the first page, i assume this is our screen size? i guess ill tweak around and see if i can create a grid that works using that size vs the 360*240 written on the grid wiki page.
720x240 bitmap display looks better, chdk logo is still messed up, color pallet appears to be different. Canon advertises a "23000 dot display" (720x320 ?) but perhaps this applies to the live view and not the bitmap.
edit:
Yep, found some time tonight.. played around.. turned this one from the wiki:
http://chdk.wikia.com/wiki/Grids#--_Diagonal_Method (http://chdk.wikia.com/wiki/Grids#--_Diagonal_Method)
@title Diagonal Method
@line 0,0, 269,239, 26
@line 0,239, 269,0, 26
@line 90,0, 359,239, 26
@line 90,239, 359,0, 26
Into
@title Diagonal Method 720*240
@line 0,0, 538,239, 26
@line 0,239, 538,0, 26
@line 180,0, 719,239, 26
@line 180,239, 719,0, 26
and it comes out properly.. hmm I see a few other newer cameras also have this same screen size.. so i suspect this will show up else wheres also with some other conversions if anyone else trys to use the grids. I guess ill do a few searches on the dev forums and see what i find if not ill convert some more later.
-
- tweaked battery high/low values. Note, these are stored in cfg, so unless you reset your cfg you won't see any change.
I deleted my CHDK.cfg file, and now it won't come back. ???
How do I get my camera to create a new one?
-
Are there any other known firmwares except 1.00e? A european firmware maybe? The exif data in my testshots only says version 1.00.
No other firmwares are known at this time.
On a SD990 shipped this week I'm seeing a firmware version of 1.01B , so it appears they may have just upped it.
-
On a SD990 shipped this week I'm seeing a firmware version of 1.01B , so it appears they may have just upped it.
Thanks for letting us know.
If you have this camera, please get a dump and post in the http://chdk.setepontos.com/index.php/board,5.0.html (http://chdk.setepontos.com/index.php/board,5.0.html) forum. udumper with newdryos should work on this camera. You can find more information on the wiki http://chdk.wikia.com/wiki/Porting_the_CHDK (http://chdk.wikia.com/wiki/Porting_the_CHDK)
You can also try the current 100e port. Occasionally the changes between canon firmwares are small enough that a new CHDK is not needed, although I'd expect that 100 to 101 indicates a bigger change. Running the wrong version probably just crash your camera, but the usual disclaimers apply http://chdk.wikia.com/wiki/FAQ#Q._Can_CHDK_damage_your_camera_.3F (http://chdk.wikia.com/wiki/FAQ#Q._Can_CHDK_damage_your_camera_.3F)
-
On a SD990 shipped this week I'm seeing a firmware version of 1.01B , so it appears they may have just upped it.
If you have this camera, please get a dump and post in the http://chdk.setepontos.com/index.php/board,5.0.html (http://chdk.setepontos.com/index.php/board,5.0.html) forum. udumper with newdryos should work on this camera. You can find more information on the wiki http://chdk.wikia.com/wiki/Porting_the_CHDK (http://chdk.wikia.com/wiki/Porting_the_CHDK)
Hopefully will have time in the next few days. Shouldn't be a problem assuming the dumper works fine with this rev.
You can also try the current 100e port. Occasionally the changes between canon firmwares are small enough that a new CHDK is not needed, although I'd expect that 100 to 101 indicates a bigger change. Running the wrong version probably just crash your camera, but the usual disclaimers apply http://chdk.wikia.com/wiki/FAQ#Q._Can_CHDK_damage_your_camera_.3F (http://chdk.wikia.com/wiki/FAQ#Q._Can_CHDK_damage_your_camera_.3F)
No dice, causes a crash requiring battery removal.
-
Hello
I just tried the newest CHDK release on my IXUS 980 1.01B and it just locked up.
I looked briefly for a way to download the firmware, to post it here but didn't find any reasonably understandable How To.
Does any one have the firmware for the IXUS 980, that the CHDK is based on, so I could try out the CHDK ?
-
A new port would be needed to support 101B. There is not a firmware dump yet, so porting cannot be started. Even if there was a dump, there is no developer with the camera, although if the differences are minor, a "blind" port isn't out of the question.
See http://chdk.wikia.com/wiki/Porting_the_CHDK (http://chdk.wikia.com/wiki/Porting_the_CHDK) for information on how to obtain the dump and http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera (http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera) for how to make a port once you have that.
You will not find a "downgrader" that will turn your 101B camera into the supported 100e version. The firmware dumps we use for porting are not suitable for re-flashing to the camera.
-
A new port would be needed to support 101B. There is not a firmware dump yet, so porting cannot be started. Even if there was a dump, there is no developer with the camera, although if the differences are minor, a "blind" port isn't out of the question.
I have made a dump of the IXUS 980 IS 1.01B firmware, it can be found here http://www.frogkick.dk/projects/photo/CANON_IXUS_980_IS_1.01B_PRIMARY_cam-firm.zip (http://www.frogkick.dk/projects/photo/CANON_IXUS_980_IS_1.01B_PRIMARY_cam-firm.zip). It would be great if somebody with knowledge of the 1.00E firmware could check how different the two versions are.
I would very much like to be able to take underwater photos in RAW format :D
Yours!
DryDuck
-
Hello & welcome, DryDuck !
The dump looks ok, i've added it to the dumps repository...[1] (http://chdk.setepontos.com/index.php/topic,288.msg36473.html#msg36473)
-
Purchased a Powershot SD990 today in Toronto.
Firmware: 1-5.0.1.0
Is this yet another firmware version?
-
That's not the firmware version. See
http://chdk.wikia.com/wiki/FAQ#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F (http://chdk.wikia.com/wiki/FAQ#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F)
Please note! your camera's firmware version is NOT 1.0.0.0 or 1.0.1.0! It's a number that looks similar to this example: 1.01e. If you get a number like 1.0.1.0, then you did not do it properly and probably the ver.req or vers.req file in the root directory of the inserted SD-card is missing.
-
Thx. 1.00E.
-
Thx. 1.00E.
You are in luck then, that's the only version that is currently supported.
-
Hello,
I got two new ixus980 a few days ago which have FW 1.01B but there is some strange behaviour: when inserting any bootable SD card including a diskboot.bin file, card is locked this is what happens: camera boots up saying 'card locked' so it seems it ignores the diskboot.bin and also ignores booting it - I tried same SD card in a different ixus camera with the correct diskboot.bin file and it boots up, whereas on the ixus980 this does not happen (even with the flase diskboot.bin the camera shoud at least lock). Any ideas whats different here?
thanks
Werner
-
ok did some more tests - the ixus980 seems to ignore different diskboot.bin files from other cameras - using the diskboot.bin from ixus980 version 1.00e the camera crashes as expected.
greetings
Werner
-
Hello & welcome, Werner !
ok did some more tests - the ixus980 seems to ignore different diskboot.bin files from other cameras - using the diskboot.bin from ixus980 version 1.00e the camera crashes as expected.
The firmware update loading mechanism always checks whether the Platform-ID (http://chdk.wikia.com/wiki/P-ID_%28Table%29) is the correct one for this camera model.
Different firmware versions (and also different "brands" like Powershot/IXUS/IXY or PAL/NTSC cameras) have the same P-ID.
A "foreign" CHDK (i.e. with the wrong P-ID) will be rejected with an error message or will be ignored...
So, since the 1.01B fw is not yet supported, it must be ported first...
-
Hy!
I don't have any programming knowledge, but I have 1.01B fw. Could somebody compare the 2 fws, and make a blind port?
Please! I'd like to enjoy the benefits of CHDK!
Thanks!! :)
-
;) A friend of mine informed me of CHDK. Great program for my SD990!! Thanks. I finally got RAW working, which is the main feature I was looking for. For some reason I can't get Bracketing to work. Does it work in this beta software?
-
Hello & welcome, Darrelj !
;) For some reason I can't get Bracketing to work. Does it work in this beta software?
Yes, of course.
Ok, I see what you mean. So I can only take pictures in the regular mode. But how will I be able to use features such as bracketing?
Enter the <Alt> with PRINT, enter CHDK menu with MENU, set up wat you want...
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fimages.wikia.com%2Fchdk%2Fimages%2F%2F6%2F68%2FAllbest51-425_SD400_ExtraPhotoOperations.jpg&hash=906bdc04d16efb7c65f5b121f59a4b13) (https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fimages.wikia.com%2Fchdk%2Fimages%2F%2F8%2F8a%2FAllbest51-425_SD400_Bracketing.jpg&hash=f960a8b6609bce704cc198161b73655d)
-> set "TV bracketing value" to [2 Ev], "Brackting type" to [+/-], exit Alt mode, use the custom timer (set up to 1s delay, 3 shots)
-
Thanks. I'll try that. On a separate question, I see that Zebra mode always shows the lower half of the LCD display with striped lines. Is that normal?
-
On a separate question, I see that Zebra mode always shows the lower half of the LCD display with striped lines. Is that normal?
Hmmm - with zebra on, only over- or underexposured areas of the liveview should be marked...
See Zebra parameters (http://chdk.wikia.com/wiki/CHDK_firmware_usage#Zebra_parameters) and also some sample images here (http://chdk.wikia.com/wiki/CHDK/End-Users-Guide-AllBest50#Zebra_parameters).
To make sure it's not an issue with your CHDK settings, you should reset these settings to the default values
(Reset options to default... from the CHDK Miscellaneous menu).
If this doesn't help, it would be helpful if you post an image of the screen (e.g. taken with with the camera of a mobile phone) here...
-
Here's a shot of the effect. Sorry, it's not very clear, but when zebra flashes, you see the the whole lower half of the image is covered with a series of horizontal lines.
-
Resetting caused the effect to go away. Now I just have to go set everything up again.
Anyway, thanks. I'm still not able to get bracketing to work, but maybe its operator error. I set everything up the way you suggested. When bracketing do I have to hold the button down, or does it automatically do the three bracket pictures?
-
Zebra does not work on this camera. Making it work would require significant hacking of the zebra code, because of the difference between bitmap and live view resolutions.
-
Resetting caused the effect to go away. Now I just have to go set everything up again.
Oh, now i remember....thx reyalP
I'm still not able to get bracketing to work, but maybe its operator error. I set everything up the way you suggested. When bracketing do I have to hold the button down, or does it automatically do the three bracket pictures?
a) First you have to adjust the Canon custom timer mode (see page 75 of the SD990 manual, pdf version, see image 1)
Set it to "Delay"=2 seconds, "Shots"=3
This settings will be stored by the camera, so you have to set up this only once...
b) Then set up the CHDK Bracketing:
"TV bracketing value" = [2 Ev]
"Brackting type" = [+/-]
If you disable "Clear bracket values on start", then the settings will be saved,
otherwise you have to set them up again each time you've powered off the camera.
c) Now let's bracket:
- Switch to the "Custom-Timer" mode of the camera (press the DOWN button until you see the (c) symbol)
- Half-press & hold the shutter to focus
- then full-press the shutter button & release it
- hold the camera, do not move...
-> Now the camera waits for 2 seconds (the Delay value you set up in the menu),
-> then the camera will take 3 shots (as setup with "Shots"=3 in the menu) with the CHDK bracketing:
1st shot with the camera's default exposure,
the 2nd shot with +2 Ev (overexposured)
and the 3rd shot with -2 Ev (underexposured)
-
Thanks for taking the time to spell it out. I'll try it step-by-step. For me, the biggest gain with CHDK is RAW --the rest is just icing on the cake, and I'm just playing around with these new features. Congratulations on a great hack!
-
Ok, I did exactly that, and it did work. I set it to 1/3 EV, and it took three pictures, one at 1/60, 1/40 and 1/80 shutter speed. I expected the exposures to show on the +/- readout, rather than the shutter speed.
-
SX10 CHDK has enable ISO overide in ISO3200 mode.
Will this function work on current version 980IS CHDK?
http://chdk.setepontos.com/index.php/topic,2468.msg30890.html#msg30890 (http://chdk.setepontos.com/index.php/topic,2468.msg30890.html#msg30890)
-
Hi everyone,
I also have a recently purchased sd990 with firmware 1.01b, and use CHDK in several other cameras.
I would like to help with the porting for this version. I'm not a programmer, just an enthusiast.
I was reading here;
http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera#Requirements (http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera#Requirements)
that it may be possible to modify an existing port for a camera; I'm thinking the sd990 with the 1.00e firmware, compare
the files and make necessary changes. Like I said, I'm no programmer but am willing to try this. What/how do I need to
compare and modify?
This is probably beyond the scope of these postings, but you never know unless you ask!
thanks for all the good work and the time contributed,
Curt
-
I was reading here;
http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera#Requirements (http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera#Requirements)
that it may be possible to modify an existing port for a camera; I'm thinking the sd990 with the 1.00e firmware, compare the files and make necessary changes. Like I said, I'm no programmer but am willing to try this. What/how do I need to compare and modify?
You have misunderstood. You will not be able to do this if you are not a programmer with a reasonable grasp of C and assembler.
-
Test build for SD990 101b. Please note, I do not have an SD990 of any kind, so this is totally untested. It probably won't melt your camera, but it could easily crash. If you choose to try it, it's at your own risk.
Both a diskboot.bin and ps.fi2 are included. To test, I suggest installing the full SD990 100e build, and then copying the enclosed PS.FI2 and DISKBOOT.BIN to the root of the SD card.
Attached patch is for developers who may be interested in debugging, it is not required to run.
patch will be attached to next post due to attachment limits.
-
Patch
-
Thanks for working on this!
Spent a little time on the 1.01b version.
No crashes at all.
The biggest problem I have is the font size. I had to enlarge the menu fonts to the largest arial font in order to comfortably read the menu. I am unable to find a way to increase the size of the OSD font as of yet. They are pretty small, but still legible.
The menu is off to the left, not centered like the other CHDK's I have used.
All of the Shutter/ISO/Custom ISO functions worked well for me. I did not try any bracketing or scripting yet.
All the video functions that I tried worked fine.
The clock and battery work fine.
Writing RAW files works ok. I did not do any DNG conversions.
The control wheel does not work while navigating the CHDK menus, not sure if it is supposed to or not, although I think it does work in my SX110.
Not sure about being able to auto boot in something larger that 2GB, but that seems to be about the max size for auto boot. 4GB will not, although I did not try with Card Tricks, I just copied the files over.
I was mostly interested in a way to control the shutter speed better and this does seem to work well.
I hope this helps to keep the ball rolling.
-
Test build for SD990 101b. Please note, I do not have an SD990 of any kind, so this is totally untested. It probably won't melt your camera, but it could easily crash. If you choose to try it, it's at your own risk.
Hi reyalp
Thanks for making a port that work with the 1.01b firmware. This is what my preliminary testing has revealed.
Testes/working features:
- RAW works
- DNG raw files also work, at least Photoshop and Picasa knew how to read the files.
- Override shutter speed
- Override ISO value
- Histogram
- Changing color of the menu and OSD elements
- Scripting, attached output of libtst.lua
- The menus are centered, unlike what Digiman1946 reported
broken features:
- Grid lines - are only shown on the left half of the screen.
- Games - are also only shown on the left half of the screen.
/DryDuck
--- Underwater photography in RAW
-
Thanks for testing and detailed reports, sounds like it's up to where the 100e version is. I'll check it in and add it to the autobuild.
Most of the screen weirdness (grid lines, games etc) is due to the 720 pixel bitmap width which is unique to this camera. Same for the apparent small font size. Menu centering should be an option. You should be able to create custom grids that work on the SD990, the grid format is described on the wiki. The standard grids are just made for a 320 pixel display.
Note that if you already had CHDK for a different camera on the card, you might end up using the cchdk.cfg from that, which would affect the positions of things etc.
Some existing, known bugs that don't need to be reported (for both 100e and 101b)
- zebra, edge overlay and curves don't work
- Intermittent raw. If you press the shutter quickly (or maybe some other factor), RAW/DNG may not be saved.
Since I don't have this camera any more, I probably won't work on the display related stuff. It's just too fiddly to do without being able to test it. I'll probably try to get to the intermittent raw one eventually.
edit:
Committed, will be in autobuild 792 and later
-
Thanks reyalp, being able to shoot in raw with the IXUS 980 firmware 101b is brilliant.
-
I think I've fixed "Intermittent RAW: if you press the shutter quickly, RAW/DNG files may not be saved"
Test builds at http://drop.io/reyalp_chdk (http://drop.io/reyalp_chdk)
If an SD990 user can verify that this works, I'll commit it.
The display setup is very similar to D10, so I may be able to finally fix some of those longstanding issues as well.
-
Sorry just noticed your post, uploaded your port and tried several shots (20) using the autobuild and your new build. both operate the same, if you quickly press shutter only jpeg is saved, if you hold shutter 1/2 pressed until focus lock both DNG and jpeg are saved
Hans
-
I think I've fixed "Intermittent RAW: if you press the shutter quickly, RAW/DNG files may not be saved"
If an SD990 user can verify that this works, I'll commit it.
The display setup is very similar to D10, so I may be able to finally fix some of those longstanding issues as well.
Hi reyalp
Just saw your message.
I have tested your build from drop.io and it works on my camera (firmware 101b). I tried a number of different settings: auto, P/M (auto, macro and manual focus) and QuickShot (all of them both with and without flash) So I think that you safely can commit your changes.
Yours
DryDuck!
-
@DryDuck:
Does raw/DNG save correctly if you pressed the shutter quickly ? If not, then this is no point committing it.
@hnikesch
Which firmware version of SD990 do you have ?
-
I have firmware 1.00e
DNG + jpeg save is very consistent, push shutter quickly and only jpeg is saved, hold shutter 1/2 pressed until focus lock and both DNG and jpeg are saved in P, M, SCN, and quick shot modes
Hans
-
@DryDuck:
Does raw/DNG save correctly if you pressed the shutter quickly ? If not, then this is no point committing it.
@hnikesch
Which firmware version of SD990 do you have ?
Hi reyalp
All my tests were done by quickly pressing the shutter button, and all of them saved both the jpeg and the DNG file.
I just made a smaller test, also done by quickly pressing the shutter, saving the RAW images in CR2 the format and it also worked flawlessly.
Yours
DryDuck!
-
Thank you both for your careful testing. Sounds like I messed up the 100e fix or build. I'll look into it.
For future reference, there's no need to check both DNG and CHDK raw, if this bug is fixed for one it will the fixed for the other.
-
Thank you both for your careful testing. Sounds like I messed up the 100e fix or build. I'll look into it.
For future reference, there's no need to check both DNG and CHDK raw, if this bug is fixed for one it will the fixed for the other.
Hi reyalp
OK about the need not to check both DNG and CR2 raw writing.
I haven't looked at the source code, so just out of curiosity. What caused the bug, and how did you fix it?
Yours
DryDuck
-
Just moved the raw hook slightly, after realizing the code it was in depended on the flag that is set for "quick press".
sub_FF8662E0_my
LDR R0, [R6,#0x24] ; <- "quick pressed" flag
CMP R0, #0
BNE loc_FF866390
...
BL sub_FF93DDF4_my // SsCaptureSeq.c:0 nr setup
; <- old raw hook was here
MOV R5, R0
B loc_FF8663A0
loc_FF866390:
LDR R0, =0x54EC
LDR R0, [R0,#4]
CMP R0, #0
MOVNE R5, #0x1D
loc_FF8663A0:
BL capt_seq_hook_raw_here ; <- new raw hook here
-
I have firmware 1.00e
DNG + jpeg save is very consistent, push shutter quickly and only jpeg is saved, hold shutter 1/2 pressed until focus lock and both DNG and jpeg are saved in P, M, SCN, and quick shot modes
Hans
I've uploaded a new test build for 100e: http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-rawtest-2-zip (http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-rawtest-2-zip)
The same change was in both versions in my tree, but it's possible I got the wrong build last time.
-
new file works , save both jpeg and DNG with fast shutter press tried about 6 in a row, thanks
Hans
-
Excellent, must have zipped the wrong build last time. Checked in as changeset 923 (http://tools.assembla.com/chdk/changeset/923), should be on the autobuild shortly.
-
Thanks for all your good work reyalp, I will be downloading the autobuild soon
Hans
-
hey guys I just want to say great work. I'm new to photography, but I always like to put custom firmware on my gadgets. I have some questions and if anyone could help it would really be appreciated! (bear with me I'm new to this RAW stuff).
1) My sd990 had the 1.01b firmware so I used the autobuild for that firmware from the autobuild server. Are there other ports out there that have other features, or is the best one from the server?
2) I have been reading the DNG raw format is better for adobe bridge compatibility? (I really have no idea so please someone correct me if I'm wrong). I'd like to shoot raw + jpeg for each shot. If DNG +jpeg is the best way to go, I can't seem to enable it because DNG is not an option in the RAW extension option in the raw settings. I tried enabling "DNG file extension" but that didn't seem to do anything for me. My setup is basically using Adobe Bridge to manage photos, and edit in photoshop/ ACR. Whatever the correct settings are in CHDK to allow this workflow is what I'm looking for. Is DNG the format I need and how can I get it working?
3) On the latest version of ACR (from adobe's website it says), the SD990 is not "supported." What exactly does that mean as I thought raw format is essentially universal?
4) This is a little off topic but it's been bugging me. I'm trying to get a little into HDR photos. I've been able to get auto bracketing to work using chdk by settings the cannon to a custom (2 sec delay 5 photos) settings, and then enabling the bracketing on continous mode. This works great. Now. is a RAW file for each exposured shot really necessary? I don't know what I'm missing here but since you can change the exposure after the fact with a raw shot.. wouldn't you just need 1 raw shot, and then you could make duplicates of it, and on each one change the exposure to your desired range... then merge hdr?
5) Again, a little off topic, but why would you have the option (in adobe bridge) to open a JPG in "raw editor". I thought RAW editor is just for raw editing! I cannot get any of the CRW files to be imported into adobe bridge when I connect the camera to the pc.
again, thanks if you can bear with me. I'm excited to learn all this new stuff:)
-
Hello & welcome, sphinxxx !
1) My sd990 had the 1.01b firmware so I used the autobuild for that firmware from the autobuild server. Are there other ports out there that have other features, or is the best one from the server?
No, there's always the latest build for a camera available from the autobuild server
2) ...Is DNG the format I need and how can I get it working?
DNG works with almost all Adobe apps, so yes, you should use it.
To enable DNG, you have to run the "badpixel.lua" script once on your camera:
--> Enable DNG support guidance (http://chdk.setepontos.com/index.php/topic,2468.msg30870.html#msg30870)
3) On the latest version of ACR (from adobe's website it says), the SD990 is not "supported." What exactly does that mean as I thought raw format is essentially universal?
CHDK RAW is no "format" at all, just the unmodified data from the camera's sensor; the DNG format contains the same data, but conditioned to the DNG specifications and supplemented with some meta data.
Adobe (and most others) only lists cameras with native DNG support.
...is a RAW file for each exposured shot really necessary? I don't know what I'm missing here but since you can change the exposure after the fact with a raw shot.. wouldn't you just need 1 raw shot, and then you could make duplicates of it, and on each one change the exposure to your desired range... then merge hdr?
You don't need RAWs for HDR, you'll get also good results with multiple images captured with different exposure times. With RAW, the time between the shots is longer (since saving the data to the card takes some time), not good for moving targets; also not all HDR software will work with RAW images.
Of course you can create a kind of HDR from only one image (JPG or RAW) with a software - the results will not be as good as when using multiple exposures with additional image data...
...why would you have the option (in adobe bridge) to open a JPG in "raw editor".
You can work with all kind of images the same way, the same workflow, the same tool for all your images...
-
fe50, that was a fantastic response and I probably learned more from that than a few hours of reading.
I will use that script to enable DNG.. I think thats exactly what I'm looking for. and the CRWs I've alreayd shot, I can just convert those using my computer right?
When I connect the cam to my pc, I cannot see any of the crw files. Would canon utility work or is the only option to use a card reader and manually find the files.
Let me just ask this last question before I go about raw :) (I know how it is to deal with me). ACR can open both jpeg's and raws, but when opening a raw (lets say DNG file), you can't edit it in photoshop directly.. it only would open in ACR?
Thanks again for the tremendous help.
-
the CRWs I've alreayd shot, I can just convert those using my computer right?
You may have a look to the DNG4PS-2 (http://chdk.wikia.com/wiki/DNG4PS-2) tool...
When I connect the cam to my pc, I cannot see any of the crw files. Would canon utility work or is the only option to use a card reader and manually find the files.
This depends on the camera model & the CHDK setting, also on the application/software.
You could be able to transfer the RAW images with a special CHDK setting, e.g. with settings like
- DNG format: enabled (*1)
- RAW File in Dir with JPEG: enabled
- RAW File Extension: CR2 (*2)
- DNG file extension: disabled
Note: power off & on the camera once before you establish the USB connection, otherwise the files would not be visible;
the files are in DNG format (*1), but with the "wrong" filename extension (due to (*2)), you have to rename the .CR2 files to .DNG after transfering them.
Since this is not very comfortable, is suggest to use a card reader...
ACR can open both jpeg's and raws, but when opening a raw (lets say DNG file), you can't edit it in photoshop directly.. it only would open in ACR?
I'm not a PS user, but my guess is: PS use the ACR plugin to handle/convert the different RAW image types, this way the RAW-related functions/routines/algorithms are not part of the PS code; updates or support for new file formats don't demand a PS update, just a new version of the ACR plugin must be published...
Maybe PS users could give you more/better answers to this question...
-
I use the DNG file name and open them in PSE, that opens the ARC and lets you edit the DNG file in ACR for exposure, noise reduction and sharpness, when done it opens the PSE editor for normal editing. Using DNG allows me to use the same work flow for my Pentax DSLR and canon P&S
Hans
-
Fixed OSD test for SD990. The aspect correction settings used on D10 should be applicable to SD990 as well.
This means
- standard grids will work (and old SD990 specific grids will not)
- menu / ui bigger, correct aspect ratio
Please let me know if this looks OK.
Test builds on my drop: http://drop.io/reyalp_chdk (http://drop.io/reyalp_chdk)
-
I tried this on my IXUS980 100e. unfortunately It displayed the same as previous versions. I just overwritten the databoot.bin and PS.FI2 in the root dir of sd card on top of the a full install of build 933.
Fixed OSD test for SD990. The aspect correction settings used on D10 should be applicable to SD990 as well.
This means
- standard grids will work (and old SD990 specific grids will not)
- menu / ui bigger, correct aspect ratio
Please let me know if this looks OK.
Test builds on my drop: http://drop.io/reyalp_chdk (http://drop.io/reyalp_chdk)
-
I tried this on my IXUS980 100e. unfortunately It displayed the same as previous versions. I just overwritten the databoot.bin and PS.FI2 in the root dir of sd card on top of the a full install of build 933.
If you are using a multipartition card, are you sure you got the binary on the correct partition ? Diskboot.bin goes on the small one. If you load manually with ps.fi2, it uses the one from whatever the "current" one is.
Did you test a grid ?
The only way it could look completely the same is if I built the wrong tree or something like that (this is possible!)
-
hey sorry if this is off topic. I have the sd990 with chdk.
I love the feature of using overrides to get really fast shutter speeds. However when I do this, I don't really know what the total exposure is going to be (unless I were carrying a separate light meter). Is there anyway to quickly find the real exposure when using overrides? (and if i'm using flash how would i do it?)
thanks again
-
If you are using a multipartition card, are you sure you got the binary on the correct partition ? Diskboot.bin goes on the small one. If you load manually with ps.fi2, it uses the one from whatever the "current" one is.
Did you test a grid ?
The only way it could look completely the same is if I built the wrong tree or something like that (this is possible!)
I am not using multipartition card. Actually when I tested it, grids and games were all displayed on the left half of the LCD, as well as the menu. However when I use build 933, menu is on the center of LCD.
Anyway, thank you for your hard work on this model, I know you are even not having such a camera.
-
oops, I missed some #defines :-[
Sorry about that. New builds up.
http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-osdtest-2-zip (http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-osdtest-2-zip)
http://drop.io/reyalp_chdk/asset/ixus980-sd990-101b-0-9-9-osdtest-2-zip (http://drop.io/reyalp_chdk/asset/ixus980-sd990-101b-0-9-9-osdtest-2-zip)
-
oops, I missed some #defines :-[
Sorry about that. New builds up.
http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-osdtest-2-zip (http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-osdtest-2-zip)
http://drop.io/reyalp_chdk/asset/ixus980-sd990-101b-0-9-9-osdtest-2-zip (http://drop.io/reyalp_chdk/asset/ixus980-sd990-101b-0-9-9-osdtest-2-zip)
You rocks!
Now font and grids are working. However I didn't find game option in this test drop. Not a big issue, I don't think the camera is a good game console anyway.
Thank you again.
I tried edge overlay and it works!.
But zebra is still not working. In zebra mode, all zebra info is displayed on the left half of LCD and the right half is vertical stripes.
-
Now font and grids are working.
Thanks for confirming. Checked in changeset 934 (http://tools.assembla.com/chdk/changeset/934/trunk)
However I didn't find game option in this test drop. Not a big issue, I don't think the camera is a good game console anyway.
Oops, had them turned off in my makefiles. Should work OK, they did on D10.
But zebra is still not working. In zebra mode, all zebra info is displayed on the left half of LCD and the right half is vertical stripes.
Yes, fixing zebra will require additional work.
-
oops, I missed some #defines :-[
Sorry about that. New builds up.
http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-osdtest-2-zip (http://drop.io/reyalp_chdk/asset/ixus980-sd990-100e-0-9-9-osdtest-2-zip)
http://drop.io/reyalp_chdk/asset/ixus980-sd990-101b-0-9-9-osdtest-2-zip (http://drop.io/reyalp_chdk/asset/ixus980-sd990-101b-0-9-9-osdtest-2-zip)
You rocks!
Now font and grids are working. However I didn't find game option in this test drop. Not a big issue, I don't think the camera is a good game console anyway.
Thank you again.
I tried edge overlay and it works!.
But zebra is still not working. In zebra mode, all zebra info is displayed on the left half of LCD and the right half is vertical stripes.
Hi is there a difference between this link and the one on the autobuild server? I am a little confused as autobuild server page says everything there is "beta". Is there another place to get other releases, or is your link the same as the autobuild server one
(ixus980_sd990-101b-0.9.9-934_BETA). There were a little bit different in file sizes. thanks
-
Hi is there a difference between this link and the one on the autobuild server?
Yes, the one on the link is a test build built by me, to get test feedback before I check in. The one from the autobuild server is the latest official build. Since I've checked in this change, you should use the autobuild.
I'll probably take the beta tag off when zebra is fixed.
-
In changeset 935 (http://tools.assembla.com/chdk/changeset/935) zebra should be fixed. Please let me know. You may have to adjust the thresholds to get reasonable zebra function.
-
reyalp, not to overwhelm you or anything, but just wondering if this feature is possible.
Writing a script to automatically trigger flash (and the picture) upon a threshold noise level (picked up through the microphone).
I'd be glad to try although I haven't coded in a while. Could you help me out on where I should go to learn how to code scripts for the sd990?
-
reyalp, not to overwhelm you or anything, but just wondering if this feature is possible.
Writing a script to automatically trigger flash (and the picture) upon a threshold noise level (picked up through the microphone).
No. CHDK doesn't not currently have the capability to use the sound hardware in this way. You might be able to do it with eventprocs, but if possible, it will require significant hacking. See http://chdk.wikia.com/wiki/Event_Procedure (http://chdk.wikia.com/wiki/Event_Procedure) Some of the information from the Canon basic thread http://chdk.setepontos.com/index.php/topic,5549.0.html (http://chdk.setepontos.com/index.php/topic,5549.0.html) may also be useful, the people who figured out how to run that did some stuff with sound eventprocs.
I'd be glad to try although I haven't coded in a while. Could you help me out on where I should go to learn how to code scripts for the sd990?
Scripting works the same way for all CHDK cameras (there are some camera specific variation and quirks, but the fundamentals are all the same). I suggest you start with the script related categories on the wiki http://chdk.wikia.com/wiki/Category:Scripts (http://chdk.wikia.com/wiki/Category:Scripts) http://chdk.wikia.com/wiki/Category:UBASIC (http://chdk.wikia.com/wiki/Category:UBASIC) http://chdk.wikia.com/wiki/Category:LUA (http://chdk.wikia.com/wiki/Category:LUA)
This thread is for SD990 development. Please make non-sd990 specific posts in the appropriate subforum.
-
In changeset 935 (http://tools.assembla.com/chdk/changeset/935) zebra should be fixed. Please let me know. You may have to adjust the thresholds to get reasonable zebra function.
Zebra is working.
Thanks.
-
Zebra is working.
Thanks for confirming. I've removed the beta label from this port.
-
Downloaded the latest autobuild and all looks great, my old eyes really like the larger font, everything seems to work
Hans
-
Continuing this here as nafraf suggested.
PS: If this camera can also be included in the custom color palette work I'd like that.
We can try to implement custom colors for ixus980, I think it is better to discuss this on ixus980_sd990 porting thread (http://chdk.setepontos.com/index.php/topic,2972.0.html).
We need to discover the value of active_palette_buffer on rec and play mode. Please use the patch in attachment, and enable Misc values (CHDK menu -> Miscellaneous Stuff -> Debug Parameters -> Show Misc. Values [ x ] )
Please tell me the value of active_palette_buffer (APB) on rec and play mode.
Additionally, please post an image of palette on rec and play mode. (CHDK menu -> CHDK Settings -> Color Settings -> Draw Palette).
Thanks
Thanks for the patch. I tested for the values you wanted.
APB in Rec mode is 0, APB in play mode is 1.
While the Canon native menu is up APB depends on what TAB on that menu is active.
In play mode there are four tabs (APB values 7,8,11,13), in rec mode there are three tabs (APB values 5,11,13). I don't know if you need that menu business I'm listing it for completeness' sake.
-
Here are the palette screen shots. Top is Rec, second is Play. The lwermost three are the three active tabs inside Canon Menu in Rec mode. They are all of the same fashion. Funny that of the few colors that do vary between them one is used for CHDK menu as it is...
From top to bottom APB values 0,1,5,11,13
-
Thanks.
Patch to load custom colors (PLAY and REC modes).
EDIT: Patch updated, new version includes transparent dark grey
-
Thanks.
Patch to load custom colors (PLAY and REC modes).
EDIT: Patch updated, new version includes transparent dark grey
Works but default menu colors still seem to be what they were. Updated screen shots enclosed. Rec first, then Play.
-
Could you reset CHDK Colors configuration?
CHDK Menu-> CHDK Settings -> Color Settings -> Reset All Colors
-
Could you reset CHDK Colors configuration?
CHDK Menu-> CHDK Settings -> Color Settings -> Reset All Colors
Yes, thank you that was what was needed. After the reset it looks just like what Waterwingz was proposing as the default menu color set in the other thread. Very nice compared to what there was before...
-
Thanks. Changes committed to trunk. Changeset 3698 (https://www.assembla.com/code/chdk/subversion/commit/3698).
I'd like to post patches for ixus95_sd1200 and a1100, could you check palettes, active_palette_buffer values and post to the corresponding porting threads?
-
I'd like to post patches for ixus95_sd1200 and a1100, could you check palettes, active_palette_buffer values and post to the corresponding porting threads?
Sure, I did.
-
Thanks. Changes committed to trunk. Changeset 3698 (https://www.assembla.com/code/chdk/subversion/commit/3698).
I'd like to post patches for ixus95_sd1200 and a1100, could you check palettes, active_palette_buffer values and post to the corresponding porting threads?
In trunk 3708 this is broken again for IXUS 980. I'll post screen shots of the palette later. I'll also re-check A1100 and IXUS 95 which we worked on at the same time if the situation also applies to them.
-
In trunk 3708 this is broken again for IXUS 980. I'll post screen shots of the palette later. I'll also re-check A1100 and IXUS 95 which we worked on at the same time if the situation also applies to them.
A1100 also has a problem I'll post on it's thread and IXUS 95 was fine.
It might be interesting to check what happened between Changeset 3698 and 3708 that broke this. I guess 3706 did. And to ponder if any of the other previously working cameras with custom colors would be affected. I think I could test some of them but I don't have all.
In CHDKPTP all works as before but on the camera it does not.
-
In trunk 3708 this is broken again for IXUS 980. I'll post screen shots of the palette later. I'll also re-check A1100 and IXUS 95 which we worked on at the same time if the situation also applies to them.
A1100 also has a problem I'll post on it's thread and IXUS 95 was fine.
It might be interesting to check what happened between Changeset 3698 and 3708 that broke this. I guess 3706 did. And to ponder if any of the other previously working cameras with custom colors would be affected. I think I could test some of them but I don't have all.
In CHDKPTP all works as before but on the camera it does not.
In revision 3698 this line:
extern char** palette_buffer_ptr;
was changed to:
extern int** palette_buffer_ptr;
I think the new (second) version is wrong as it causes the offset added in the next line to be multiplied by 4. I think this is why the palette sent to chdkptp is wrong.
Phil.
-
For ixus980, please test philmoz suggestion:
Index: platform/ixus980_sd990/lib.c
===================================================================
--- platform/ixus980_sd990/lib.c (revision 3716)
+++ platform/ixus980_sd990/lib.c (working copy)
@@ -108,6 +108,6 @@
void *vid_get_bitmap_active_palette()
{
extern int active_palette_buffer;
- extern int** palette_buffer_ptr;
+ extern char** palette_buffer_ptr;
return (palette_buffer_ptr[active_palette_buffer]+16);
}
That change was not included in posted patch, probably I added that bug before committing the patch.
I tested this today and it woks just fine when it's a char** again.
A1100 also needs to be checked, there was a problem with it, too.
@philmoz: Thank you very much.
-
Patch commited to trunk, changeset 3718 (https://www.assembla.com/code/chdk/subversion/commit/3718). Thanks