Talk:Downloads

The contents of this page are very outdated. For current help with CHDK downloads and features, please post on the [CHDK forum]

trying to clean up this page. users shouldn't need to read so much in order to download chdk and get started. -mattkime

Great idea, [mr. anon]. Thanks for expending the effort.

Thanks for the vote in favor. With the dire lack of cooperation from the G7 gang, I couldn't think of any other way to include their bizarre file-sharing links in a fair manner. The only problem will be as updates happen to the author's own files and their filenames. I hope those using those makes and models and builds will take the time to update them if they ever see fit.

If you see any G7 or A5710 links that I missed or haven't found (or upcoming versions that I know nothing about), please share them. I listed all that I know. And far as I can tell the A5710 is still in testing so I didn't list any link to that one yet.

G7 src & bin

G7 src & bin - http://ewavr.nm.ru/chdk/g7.htm. This page is written in Russian, but there is all links.

IXUS700 (SD500) src & bin - http://ewavr.nm.ru/chdk/ixus700.htm

Removal of a limit in 1 Gb for video (for some cameras) + src http://ewavr.nm.ru/hdk/for_test/

Thanks VERY much for this further info. Especially for those test versions. I'm anxious to see those wonderful features working! Could someone please clarify for me though, are Zosim and Ewavr both one in the same person? I never know which name to use when making headers and references.

Yes, Zosim and Ewavr the same person (EWAVR). Test versions are checked up now on а710 and s3is.

Thanks for the clarification! That's going to help in editing. :-)

Here's my own tests on the S3 (full version):

Test results: 640x480 30fps video, 44.1kHz audio, compression 50 -- stopped at 24 minutes 36 seconds, 1.85 gigs. Camera reported 2G card was full. (It was also partly full of other things.) So figure at least 1.5 hours of high-quality video on an 8G card. Unless there's still a 1 hour limit. Compression artifacts (set at 50): minimal and acceptable. Nothing at all like the HIcompression in earlier builds.

Trying again on a 4G (FAT16 format) card at compression of 85. Wondering if it'll hit a 2gig FAT16 limit. ... It quit at 1.99gigs (FAT16 limit), 13.5 minutes video length. Compression of 85 appears to be less compression than 50 (never can tell which way they mean by "most" when it comes to compression). Looks like you can even get less compression than Canon has designed into their firmware. Normally 1gig would have been about 9-10 minutes. A nice addition for those videophiles that require the very best video they can get. Someone will have to compare the new compression options against the very best video cams now. These P&S cameras' video already rivaled most video cameras, I suspect they can now easily beat them, if you have the card space.

Now to try in 4G in FAT32 and higher compression (lower numbers), and lesser audio quality, to see about that 1 hour limit...

EWAVR's "VideoPlus" Version - Notes & Firmware Usage Info

I would like to start a discussion section concerning this pretty spectacular build (spectacular for those who also bought their cameras for the video capability).

I'm pretty busy this weekend, so haven't had time to test things thoroughly, but it would be interesting to have a small chart of compression levels. Things like megabytes per second (giving everyone an idea of "quality", people into video can quickly relate MB/s to video quality, if audio isn't included in that rate); some subjective comments on how much artifacts each level produces, maybe some examples on which levels of compression would be applicable to what kinds of events to video, like "10 good for boring lectures", "68 = Camera's original compression level" (just a rough guess); things of that nature.

I'll move the "notes" about it from the download page to here, so we can have a better place to share our findings.

(A huge THANKS to EWAVR for discovering these things! USB remote included! I hope he doesn't mind me coining the term "VideoPlus" to describe it.)

Some initial findings:

Initial Tests: The A710 and S3 IS experimental "VideoPlus" versions have been tested and appear to be working just fine so far.

FAT16 & AutoLoading CHDK: 2GIG Limit: If you are using SD cards larger than 2G and FAT16 to make use of CHDK's auto-loading feature, be reminded that there's still a 2GIG file-size limit for FAT16, that is a limit of FAT16 and there's nothing you can do about it. If you want to shoot video to the capacity of your SD card you'll have to use FAT32 and do without the auto-booting feature (a small price to pay for such an amazing improvement).

Compression Levels: The user selected compression setting of 1 to 99 means 1 is the most compression (lowest quality), 99 the least compression (highest quality). It appears that the default compression setting of 86 when first run is even less than the original Camera's firmware (see test notes in discussion page of this section). Meaning that you can get even better video quality than before. A compression of 50 was quite acceptable, some fine vertical artifacts but nothing like the HIcompression mode of earlier builds and afforded a little over 2x's the original camera's video time.

2GIG Limit on Non-SDHC Cards: I just tested a low-quality of 20, with a 4G FAT32 format card. The file still stopped at 1.99 gigs (43m 19s, at 640x480, 30fps, 22kHz audio). Well, that's still better than having just 1 gig limit! It could be due to not using an SDHC card. This is one of those Transcend 4G (non-sdhc) hybrid types, they fake an SDHC format for more compatibility with older cameras. Someone with a real SDHC card(s) will have to make a full file-size test. (Wow, even at that much compression the video is quite acceptable! Nice!)

_____________________________

Another bitrate test, reposted with permission:

A620 Movie Plus CHDK version tested

Vit40

Made a quick test of Ewavr's CHDK "movie plus" version on my A620. Version for A620 is dated 22.10

Camera was fitted with Kingston 120x 2GB card, with RAW write benchmark result 9.477 kB/s Average file transfer data rates at various compression ratios

50 = 1.25 MB/s

55 = 1.30 MB/s

60 = 1.40 MB/s

65 = 1.50 MB/s

70 = 1.65 MB/s

75 = 1.83 MB/s

77 = 1.95 MB/s

80 = 2.20 MB/s

85 = 2.55 MB/s

90 = 3.20 MB/s

95 = 4.70 MB/s

98 = 7.00 MB/s ! ! ! !

So, it's possible to set compression ratio of DV and even less

Quality between 50 and 55 is similar to LP mode on some new Canon digicams

It seems that default quality is 77 or somewhere near

At quality level 99, my A620 froze several times for obvious reason - camera couldn't bear the extremely high bitrate, several times higher than DV. After about 10 second, it turned off and last movie clip wasn't saved. I don't suggest using anything above 95 - gain in quality is very small and you will quickly waste free space on the card For anything above default bitrate, high speed SD card is a must!

Unfortunately, remaining time, shown on the LCD, is calculated as if camera was set to "default" video bitrate

I recorded 10 second clips of the same static scene, to get comparable results. At same compression level, bitrate depends on the scene, so I've chosen a scene that returned about 2 MB/s at default settings, which was average bitrate on my various movie clips recorded previously. Actual results on real scenes would vary, but not much, I think.

Until some future CHDK modification, only sound mode on A6x0 is 11 kHz 8 bit mono, occupying only 11 kB/s, but sound is far from Hi-Fi quality.

I wouldn't use bitrate lower than 1 MB/s; my previous Pentax digicam used that bitrate and it was just acceptable quality for me. For short clips, where card space isn't a problem, I'll probably use quality around 90. It's about 3.2 MB/s (60% more than default) and 10-11 min of video will fit on 2 GB.

Many thanx to the Author of this CHDK modification

Vit

_____________________________

Another quick test of movie compression ratios (A620), this time 10 second movie clips, taken through the window, panning from left to right, covering angle about 90 degrees. Results slightly different than yesterday

default ... 1.89 MB/s

q=90 ... 3.66 MB/s

q=77 ... 2.46 MB/s

q=50 ... 1.37 MB/s

So, this time, q=77 returned considerably higher bitrate than default movie mode. Replayed movie clips using ffdshow, enabling mjpeg, and frame quantizers (shown by OSD) were:

default ... 3-9

q=90 ... 2

q=77 ... 4

q=50 ... 9

The higher the quantizer is, the higher the compression and the lower is the bitrate and quality.

As I thought before this test, on default mode, camera is constantly warying quantizer to limit bitrate to about 2 MB/s. It works the same way as DV, or DivX/Mpeg encoders, when you select "constant bitrate" (unlike mjpeg, DV and mpeg 1,2,4 also support different quantizers on different parts of the same frame). When "My video compression" is on, quantizer is constant on all frames of the movie clip, and bitrate is warying according to complexity of the scene. It's like when you set "constant quality" in DivX/Mpeg encoder.

Thanks for the valuable contribution, Vit40!!!

Yes, it is true. The old "hicompressed movie" mode is equivalent to compression 11. For the compression close to 99, camera can unexpectedly be switched off depending on complexity of the scene.

_____________________________

(EWAVR said:) Added new feature - bitrate factor (0.25x-3x). Tested, as usually, on A710 only. Old binaries/source moved to another folder.

[mr. anon said:] Cool! Works great on the S3 version too so far. (For those that haven't checked his test page, he's ported it to several other cameras too.) But, can you explain how this is different? Does it use a different compression method? Or is this just an easier way to pick out a favorite compression ratio? On my S3 I get:

640x480 44.1kHz stereo

0.25x = ~0.624 MB/s

1.50x = ~2.87 MB/s

3.00x = ~6.05 MB/s (but the camera can only record 2 seconds before maxxing out the buffer and giving up, I've never seen that buffer guage before, that was neat!)

If there is no difference in compression methods, how do these n.nnX number relate to the 1-99 scale?

There is one difference:

• The 1-99 scale compression mode - video will be recorded with constant quality (VBR mode).
• The #.##X compression mode - video will be recorded with constant bitrate (CBR mode).

--GrAnd 18:42, 1 November 2007 (UTC)

GrAnd, thanks for that explanation! Now I see how that can be a very valuable addition. I thought it was just replicating the original compression option in an easier way. Now .... to request/hint/nudge Fingalo to plug that into his next builds ... :-) [mr. anon]

_____________________________

Test done on an S3IS with 8GB SDHC memory card using Fingalo version 121 of November 18, 2007: limits are 2GB (recording in high quality) or 1 hour (recording in low quality) video, whatever comes first.

_____________________________

Another test on an S3 IS reveals:

1 Hour Time Limit still intact. No big disappointment, it's the same on the S5 IS and others. :) You can't even $buy more time in a Powershot, this year.

Test Results:

Settings of: 320x240 15 fps, Video Quality = 1, Audio 11kHz Stereo, Camera on tripod taking a video of TV broadcast display to keep something moving with some detail in it for compression vs. artifact vs. file-size results.

1 Hour (exact) = 254MB (yes, you read that right, megabytes :) )

Compression Artifacts = SEVERE. You can test that setting of 1 for yourself by taking a quick clip then play it back in the camera. Outside of using it for some special effects, the only other use I can see is if you need script control to record audio-use-only tracks, stripping out the video from it later. Saving greatly on SD card space.

There must be a pretty steep artifact curve if a setting of 10 was GrAnd's old HiCompressed Movie mode. Because that was almost acceptable for some video uses. I've not tested the intermediate 2 to 9 settings, presently trying to test for main limits vs. bit-rates at the moment.

(Am now testing Video Bitrate = 0.25x at 640x480, 30fps, 11kHz audio, to see how that pans out artifact and file-size wize. I'll let you know how it goes. MUCH thanks to those who have tested some of these things already! Every new test data helps paint a clearer image of when (and why) these are useful settings.)

Results:

640x480, 30fps, 11kHz audio, Video Bitrate = 0.25x

Length = 1 Hour Limit

File-Size = 1.72 GB

Artifacts = Acceptable, with caution.

The video quality with this variable-bitrate setting of 0.25x seems similar to that of GrAnd's HiCompressed Movie mode. Thin vertical lines appearing in many areas. But it handles fast motion very well and details fairly well. Non-changing smooth areas show obvious vertical lines, and fast motion shows some smaller pixelation, but it's not nasty. It's a good all purpose extended video mode. About a notch below the quality you would expect from an EP speed VHS recording on an old or bargain-tape. When needing to stay beneath the 2-GIG limit and still shoot up to the maximum allowable time it might be a good option. Judging by that file-size you might get away with 22kHz or 44.1kHz audio. I was testing the lowest quality audio to check minimum file sizes and maximum length that I could get for video. 0.25x is perfectly acceptable for any informative lecture situation where visuals are somewhat important and you'd rather not have just an audio-only recording. Also if you are limited to SD card space on a long trip or vacation where you know there's going to be many things that you want to capture in video and having any video of it at all will be better than nothing. Video that can be enjoyed for its content alone, damn the quality. :)

---

EWAVR's "VideoPlus" Version not compatible with remote/motion detection

It seems that the EWAVR's "VideoPlus" Version is not compatible with motion detection and remote control on my A630. Anyone else noticed? If so, would it be possible to implement these functions on this build?

This is where it might get a bit confusing (or a lot confusing). I don't have an A630 to test the various builds. But I do know that EWAVR never added the motion detection to his code, or at least I don't think he did. The two people that were engaged in combining several key features from various sources were/are Fingalo, and Microfunguy for his SDM version. Oh, and Owen was adding some newer ones too to his latest updates. If you check Fingalo's builds at CHDK2, you'll see he added in motion detection, USB remote, and Ewavr's VideoPlus code to his builds (the A630 also supported in build #119). I don't know if Microfunguy added all 3 features to his builds or not. Are you using EWAVR's, Microfunguy's, or Fingalo's builds? It would help to know which version you are using, because those functions may not be available in the code you loaded. A simple way to tell (that I use) is to load the *.BIN file into any hex-editor then browse the file. In that I can spot all of CHDK's menu commands and uBASIC script commands available. Letting me know which one I might be working with at the time. For example, in Fingalo's build 119 for the S3 (with all features enabled), in the diskboot.bin file, I spot the string "md_detect_motion" around memory location #1b2c0 letting me know that that build has MX3's motion detection, and the VideoPlus menu text of "My Video Compression" around #120c0. That lets me know he included both features in that build. It can get quite confusing with so many builds to know which you are working with for testing and which features were incorporated from other authors. You might be testing/using a build that never had those features to start with.

Thanks a lot! Yes, I was using an "old" (yeah, everything is going so fast here!) version of Ewavr's build (from 10/30/2007). Now I tried the link you showed me, and everything works great! Well, it's starting to become a little confusing out there... but thanks a lot!

Hi

This would really be cool for us PAL users, if we could have an option to change video size to 768x576 25 fps considering a 1.33 or square aspect ratio. Currently I am up scaling the video using Apples Compressor on the MAC, video quality is better than my Panasonic NV-DS38 DV camera. It should be even better with no up scaling.

Thanks in advance

Albert mmicro@mailbox.co.za

G7 Feedback

My recent experience with CHDK for Canon G7(fw v1.00i): The CHDK firmware works perfectly with the G7. Many Raw applications won't open the G7 raw files. UFRAW doesn't display white balance "as shot"; requires manual adjustment to make images look ok. UFRAW doesn't display G7 EXIF metadata. Picasa does seem to display white balance "as shot", but white balance controls are limited. Picasa does not display EXIF metadata. For best results: convert raw files to DNG using DNG4PS-2 (a modified Adobe DNG Converter). DNGForPowerShot and Adobe DNG Converter won't work for the G7. Then open with Adobe PhotoShop + Adobe Camera Raw Plugin or Adobe Lightroom (other apps that recognize DNG may also work). With this protocol, image white balance will be displayed "as shot" and EXIF metadata will be preserved. The only issue is that Photoshop thinks that your photos were shot using a Canon A640 (not really a problem). Good luck!

Little page cleanup?

Maybe move of all "historical" build information, to Firmware_Comparisons will be a good idea?

Possibly. Do it and see how it looks.

IMVHO download page is a bit confusing. Maybe this page should be a bit more transparent?

G2mk 13:04, 13 April 2008 (UTC)

Agreed, And all that "advertising" that Microfunguy always puts in all the time for his SDM version could be truncated quite a bit, as it originally was long ago. This isn't meant to be a personal advertising page, it's meant to be a quick overview and links to downloads. That kind of verbosity should be reserved for the person's home-page. But then he's never been one to realize that his build is no better than anyone else's. Looking forward to see how your edits turn out.

ixus50/sd400 ver 101a & 101b CHDK Port - Beta version

hi, just dropping by to let you know that MPROKO has started porting the CHDK to the Ixus 50 / sd400 v101a/v101b cameras. his posts can be found here:

http://chdk.setepontos.com/index.php?PHPSESSID=1ddedef8649fe87cf6216f57ce3718f7&topic=986.0

maybe someone can update the chdk.wikia page to include Ixus 50..

..tnx..an Ixus 50 owner..

71.90.22.98 @ 13:18, 18 April 2009 (UTC)

CAUTION! Some PDF's are infected with a worm on this WIKI!71.90.22.98 13:18, 18 April 2009 (UTC)

• 71.90.22.98 - If you're sure about this, why don't you tell us which ones & what kind of worm ? _{Fe50 14:38, 18 April 2009 (UTC)}

I don't think its possible to "infect" a (PDF) document with a worm. _{Dabian 11:27, 27th of may 2009 (UTC)}

Automated transfer of Problem Report #22115

The following message was left by Anonymous via PR #22115 on 2009-05-14 07:14:13 UTC

Page leaves me guessing where to find the latest build for my camera - I know my firmware (GM1.01B)

G10

Hello all,

I've been searching this site off and on ever since I bought my G10. I was wondering if anyone is currently working on a software version for the camera.

Thank you

SX 20 IS

When are you going to release CHDK firmware for SX 20 IS

The SX20 is not that much different than the SX10,I wonder if the SX10 version might work on the 20?

• No, definitively not. _{Fe50 11:28, January 6, 2010 (UTC)}

CANON G7 - VIDEO HD

Hi to everybody!

Is it possible anyway to shot a video recording in HD quality (i.e. 720 or higher)?

Very thanks.

ROB

bertom20

Links to the "stable" downloads are obsolete.

Apparently Facebook aquired drop.io and shut it down. Are the "stable" versions available elsewhere? 216.9.11.143 19:39, November 7, 2011 (UTC)Lee

Suggestions...

This page needs a lot of unravelling, cleaning and re-styling. I still remember the first time that I downloaded CHDK (around a year and a half ago), it took me a long time before I really noticed that using CHDK was completely harmless and fine to my camera, and where to find the latest stable version.

There's a lot of "advanced" information, which ends up being completely useless and messy for begginners and intermediate users. Never forget that power or die-hard users always have the resources and knowledge to find what they are looking for, no matter how hidden it's. Don't saying at all that advanced features or information must be hidden, though, simply pointing that for them to find things is never an issue.