for devs: vacant jobs, must-have features, status & overview / for users: a poll

/edit3: MOST THINGS EITHER already implemented in trunk OR added to the bugtracker!
/edit: finally it is done. actually i think about seperating this thread into the poll/features and thread for discussion - opinions, anyone?
/edit2: will open a new thread in feature request forum about the features. it will not be stickified though, as it will only be linked to from this very thread.hm.. or will it?
Link to poll: CLICK ME!

Hello everybody,

today i want to put some structure into the development of chdk. chdk continually grows larger (as in larger code base/more features, larger list of compatible cameras, larger group of developers and finally a much larger group of "customers/users"). This is happening for a lot of reasons, however this development also introduces some problems.

To adress some of the problems some threads have been created already (1 2 3)

Now for the actual intention of this thread: it *should* depict the current status quo, as in what features are currently in the making, how is the progress and who is doing it. it also should list all the features that either are requested by the community, by other devs (including me), including an estimate on the possibility of such a feature. it *should* also list some kind of "dependency list", as in for example for a slideshow function CHDK needs to know the filetype of the current shown item (need function in asm for this feature to work). it *should* give potential developers an overview over "vacant jobs" or "pending jobs". it should also list if coding will be easy or hard, time consuming or fast, needing good ASM/IDA pro skills or other skills. some features will depend on other features to be implemented first. i hope i can create such a table. i also will supply links to corresponding threads (if existing). Some features are even coded ready yet & just need to be put into trunk. i will mostly (not only) add features here I think are POSSIBLE to implement and to some extent - useful. My assumptions are derived from my work with either chdk, the camera itself and my experience as a coder (also from reading so goddamn many posts in this forum). mind you, i am a human and humans often make mistakes. i will also in a lot of cases supply info on how something could be implemented or where (in the code). a feature description in more detail.
i know this would actually better work and of course be more comfortable with a fully fledged bugtracker. this is already in the making.

As for the developers, please comment, rectify, validate my post or add valuable information. This is NOT supposed to be a feature suggestion thread, so please refrain from posts like "i need this and that". this thread *should* be dev only (dev as in: someone who considers himself a dev, be it an "official chdk dev", an inofficial or even someone who is capable of coding but hasnt touched chdk yet), the average user can use the poll to express his opinions though.
If you have found some threads that can be linked to a specific feature, please tell me. also tell me if you have a feature that has to be included in the "must-have" list, and please state why.if you are a developer, please also state your estimation on feasibility.

As of now i see these main fields:

• Interface Optimizations/Optics/Look & Feel
• Actual Functions
• Information, Help system, Documentation (not *really* a classical DEV field, but should be mentioned anyway)
• Misc. Stuff

okay, i tried to categorize each feature/requirement, and also somehow sort them, but since these are so many, this is was very difficult for me. comments welcome. mind you: the "priority" estimations are based mostly on my OWN personal opinion, they are prone to being different from yours, i NEED comments on these.

PLEASE don't bash me if i havent listed your feature request. Or if i listed it but rated it with a low priority. Or if i listed it and provided wrong information or made wrong assumptions regarding it. Or if you think this thread sucks. Please be reasonable and always provide arguments should you criticise something

Link to poll: CLICK ME!

colors:
red - no implementation yet (needs maintainer & code)
green - implementation ready (has "maintainer"), needs more testing and/or adding to trunk
orange - sort of already written (basic functionality present), needs maintainer & more coding/testing & ideas
brown - the "stupid" jobs that nobody wants to do, usually afford no great skills. still need time & energy though, and some social skills
/edit: i know i didnt do the colors right in every item, i will update them later sometime.

Interface Optimizations/Optics/Look & Feel - to look more "professional" and pleasing to the eye - overall average importance - above low.

01 - osd text size - chdk as of now does NOT allow the changing of the OSD font or size. for some people the font is too small. rating: difficult, alot to change, but possible. priority: well, _I_ can read the font, but i understand it is too small for people - added to bugtracker

02 - symbols in menu - in the making @ here. maintainer: CHDKLover. Status: Pretty much done, needs finetuning maybe. Lot of code additions/changes, thus difficult for adding to trunk - but possible and certainly very useful. Update: IS IN TRUNK!

03 - symbols in OSD - right now CHDK uses very few symbols (battery for example) in the OSD, the more the better, maybe even with colors (more friendly to the eye, professionally looking), like the canon symbols. rating: requires good imagination & some skills using the DRAW functions. NOT important though added to bugtracker

04 - overall "smoothness", "round corners" - again pleasing to the eye. like CHDKLovers mod which enhanced the beauty of the CHDK menu vastly. he introduced draw_round_rect (dont know the exact name right now)




Information, Help system, Documentation - without proper documentation, every product is only worth a quarter of it's full potential - no users, no income (exception: Microsoft, their budget on adverts excels proper documentation ). while this is an opensource project with no income, it still needs users. For this, we need proper documentation and maybe a help system.

05 - on screen help - in the chdk menu, for every item there *should* be an entry telling you what it is for, much like the help-popups in MS windows. these entries should be language-dependent and also be switched off (for the advanced user). depending on the actual implementation the difficulty for this ranges from easy to difficult. possible: yes. would greatly enhance usability.  Update: Microfunguy does something similar in StereoDataMaker, maybe it will find its way into trunk/branch as well added to bugtracker

06 - beginner or advanced user - When CHDK is first installed, it should be set to "beginner" mode, activating the on screen help and maybe deactivating some "dangerous" or confusing items (like debug menu). you can also colorcode the "features for the experienced users". useful for new users or your little sister when you give her your camera so that she can play reversi (and NOT change all your chdk settings). maybe add a special "locked" mode, a mode you can only use preselected items (like games), and access to the original canon menus is forbidden (i.e. format is disabled). possible: yes. difficulty: somewhere in the middle between easy and difficult (imho), depending on actual implementation. added to bugtracker

07 - more languages - not really a coders job, but a dev imho has to integrate these into trunk, so that the autobuilds/release will have the languages already included (no need to search the wiki!). easy (well of course you need to speak a language different from english ). also, put some of the best scripts into trunk and subsequently into an autobuilded archive.  Update: INCLUDED IN TRUNK!

08 - archives with readme files included - talked about damn, i can't find the link anymore..., well basically it was like this: include a readme.txt file directly into the archive (for this the makefiles need to be changed and of course a readme must be written in TEXT form, maybe also multilanguage and depending on camera, at least dryos or vxworks), perhaps adding a new command for compilation, like "make batch-zip-doc" (includes docs, lang, and maybe scripts etc - compressed easily). i nominate GrAnd as the maintainer as he is the GrAndmaster of Funk, uhm, of Trunk! possible: yes. difficulty: needs makefile skills and some documentation skills. priority: pretty high i would say.  Update: INCLUDED IN TRUNK!

09 - readme files automatically created on sd card - kind of obsolete as soon as the previous item/feature is implemented, still can be of use. autocreation of readmefiles (and maybe even scripts), so they can be read in textreader. this requires them to be HARDCODED into chdk, which in general is NOT a good idea. maybe it is useful for a small "basic guide for chdk noobs". possible: yes. difficulty: easy. priority: very low.

10 - documenting the existing code - well, that has to be done, in order for future devs to not have such a steep learning curve. somebody has to do it though. possible: well, yes, sir! difficulty: easy. skills needed: knowledge of chdk, C and ASM (and makefiles). priority: low (come on, most coders can read sourcecode :p). added to bugtracker

11 - writing readmes, tutorials, faq in wiki - see 1 2 3 - has to be done to minimize confusion and to get more users. easy, yet a "stupid" job, very boring.

12 - translating all this stuff from the previous item - (apart from the dev stuff) into other languages.



Misc. Stuff - stuff that doesnt fit any description

13 - create ONE chdk - this is a personal feature request i hope some devs will find useful: minimize confusion, rename the current trunk/build to just "CHDK". As of now, the last 1000 revisions have all been added to the allbest trunk (or so it is called in public), and the people seem to use either chdk allbest or SDM. so my vote is to rename "CHDK allbest" into just CHDK. So the only thing we need in bugreports in the future is the buildnumber and the cameramodel, not the "chdk flavor". it is very confusing for beginners. no, i dont want to steal Allbests fame or somehow criticise anyone! just make things easier. that said, my role of being mod also forces me to question the existance of all the subforums for all the other builds (most of them are dead, the allbest one can be made the "default one", SDM basically has the yahoo group) - to not clutter up the forum. difficulty: easy. priority: IMHO quite in the middle. skills: being an SVN admin, makefile skills. Ability to let go of ancient traditions (j/k ). i announce GrAnd as maintainer of this Update: INCLUDED IN TRUNK! YAY!

Actual Functions - this is what it's all about - the actual features of chdk. be it small gadgets (games), functions for photographers (overrides) or things like LCD energy saving options. these items are in NO particular order, mind you. they may be sorted later, depending on difficulty, status or priority.

14 - camera benchmark - not only lcd screen and write speed on sd card. i'm thinking more of speed as in how long does it take to take 10 shots burst? how long will the battery last? how many shots before battery fails? some sort of generic benchmark. before this can be useful, the mode dial override has to be implemented (to simulate the different modes) and also override of the playback/rec switch (this feature will be explained later). it somehow could be implemented as a script, but for this to work one would have to override a lot of settings (review time for example). difficulty: high. priority: very low. useful: probably. in bugtracker

15 - shutter activation through microphone - remote shutter by shouting for example. needs great skills in ASM, as for this the binaries have to be analyzed in IDA pro. Find out if the mic can be activated not only during movie mode, find out if the mic can be accessed regarding its output, gain. on S-series, the gain can be set to one of 5 levels, just a hint. possible: i don't know, maybe. difficulty: high. useful: yes, very much (clap-o-photo). priority: well, if the mic can be accessed, this will not only lead to the remote shutter feature, but to probably a lot more useful features (for example: MUTING the microphone when taking a picture while you are shooting a video on s-series. as of now, the mic records the mechanical shutter, which is annoying when you record a concert of classical music). update: jus read changeset 395, ewavr found a way to mute the microphone. yay. thus the spwaning of the next feature request: in bugtracker

16 - muting the microphone - in s3is, when you record a video and take shots during that, the shutter is recorded to the audio track of the video. this is very annoying. please EWAVR, find a way to mute the mic in the moment you fullpress the shutter for about a second. there might be other benefits: for example when you want to record JUST a video, with no sound at all - mute the whole video. *Maybe* you can even save some space this way? disable wav recording alltogether... i'm just dreaming here Maintainer: i announce EWAVR. difficulty: for EWAVR, nothing is impossible useful: yes. priority: probably low. in bugtracker

17 - more commands in ubasic - in order for scripts to be more versatile and universal (a script that runs on ALL platforms, yet uses/activates functions that are only existing on a subset of these platforms). i already took care of this here. things like get_drivemode (uses different props on digicII/digicIII) or get_nd_present. actual implementation is easy, needs some more testing though (performance impact? whats the maximum number of commands to be included in ubascic?). maintainer: PhyrePhoX. priority: high (imho the huge amount of different scripts for each platform is VERY confusing to beginners, and even to me, as i have an a620 and an s3is, which for example have different zoom_steps). useful: very useful.  in trunk

18 - another scripting language - LUA integration is just in the making by Velo (maintainer). see here. LUA is *supposed* to be the better scripting language in terms of difficulty for beginners and also has some more powerful things in advance to ubasic. needs more testing, interest and finally being put into trunk. most of the code is already present. useful: yes. priority: it's almost done, so i guess priority is pretty low - as it "just" needs adding to the trunk.  in trunk

19 - better ubasic syntax - jucifer as of now is on a crusade to improve ubasic syntax. find examples here. this will certainly BREAK compatibility with a lot of old scripts. since he also renamed the commands, it may be possible to just ADD them, instead of renaming. thus compatibility will be retained, PLUS the new syntax could be used. useful: yes. difficulty: low.  in trunk

20 - summertime, DST - i still havent been able to find out where in the s-series the flag for "summertime active" is set. this will be needed so that the CHDK clock reflects the actual systemclock (when summertime active). it's also important for the timestamp rawfiles get. there is also a "vacation time" flag in s-series. see here. i would implement this, if only someone can look into the asm sources. difficulty: requires knowledge of asm/ida pro. useful: yes. priority: low. if this gets implemented for the s-series, i will somehow devise a way to introduce that feature to the other series as well. maybe even automatically switching to summertime/wintertime on a given date. in bugtracker

21 - in playback - which item is currently shown? - needs master of ASM. what i mean in detail: when in playback, we need to find out the filename of the currently shown item (1234.jpg or 2333.avi for example). along these lines: IS a video being played? what display mode is it in (histogram shown, info shown?). this command will be useful for: advanced slideshows (for cams that dont have it built in yet, like s-series). to be able to "mark" files. for example you slide through your pictures and press a special designated button - chdk marks these files in a buffer. later in a dedicated chdk menu you can decide what you want to do with these marked pictures, for example "delete all pictures but the marked ones". or later "encrypt or hide these pictures". also possible: by knowing what item is currently shown, chdk MAY be able to indicated in OSD IF a raw file of the same name is present. priority: high, as when this is found out, it will spawn lots of new USEFUL features. difficulty: probably high. possible: certainly.  Update: progress here and here.
also see Accessing full resolution image data in playback mode?
in bugtracker

22 - adjustments to default script - default script has to contain one print statement like "you just started the default script. are you sure about that? exit altmode by pressing get_altkey and read the manual please"
in bugtracker

23 - on screen keyboard - one of the most requested features. if this gets implemented, even in its simplest form, this will spawn a whole lot new features. i think i dont have to mention these, but i will mention a few just anyway: built-in ubasic debugging, writing scripts, writing texts, writing captions, writing exif data, etc. i announce wontolla as maintainer, as he put the most brains into it so far. see here. there is no actual implementation yet, it could be difficult. the way i see it, the most "easy" way to have an on screen keyboard would be to copy the code from the color-chooser (in the visual menu) and rewrite it so that instead of colors, you choose letters (or even complete words for ubasic for example). priority: high. useful: well, yes, sir!
in bugtracker

24 - being able to load presets for both CHDK AND the camera itself - another very important feature. Being able to write & read different configuration files (and being able to name theses configs, via the on screen keyboard). This should be fairly easy to implement, you just have to replace the "load_chdk_configfile_function" with "load_CUSTOM_chdk_configgile_function", probably included into the filebrowser. also saving of these settings.
ALSO very important: Saving (AND restoring) of actual CAMERA settings. these can range from simple things like zoom to more advanced ones like "macro-mode" or "AiAF". A lot of these settings the camera normally forgets, and also a lot of cameras dont seem to have the "custom mode" (which is not enough for me). With this feature it will be possible to load a "macro-stack-with-flash-manual_focus-usb-remote" setting, which sets zoom, macro, manual focus and the like. this feature will be very difficult to implement, BUT it is possible. priority: CHDK settings - high. Camera settings: not so high needs skills in ASM and C. useful: YES! for this topic exist a lot of posts, none with an implementation though. in bugtracker

25 - jumping between chdk versions - on the fly switching between CHDK versions (and/or SDM). THis should include config files and maybe scripts etc. i announce Whim as the maintainer, as he has spent alot of brains on this already (look here for example). the actual implementation could be easy and fast, depending on how you do it. without rebooting (the user can do that himself) this should be pretty straightforward: move/copy binary & fir from some directory to the root of the card. if there are more files to it, copy them as well (a whole chdk folder). before that, maybe backup the existing binaries to a predefined folder. needs the fileexplorer to be implemented. also the virtual keyboard would be nice. also would be nice if this feature reads out the version string of the binary that is to be put into root: to see which camera it is for, which version and which flavor. the use of that would be immense. for example i can keep SDM and CHDK on my card and when in the forest i can switch between them seamlessly. also useful if you happen to meet someone with a P&S canon (without chdk) and you want to show him what his camera is capable of (if you have chdk for his camera SOMEWHERE on your sd card). along those lines: find out if it is possible (needs ASM skills) to override the "card slot is open detection". it cant be a hardware switch, as when the camera hangs and i open the cardslot, the camera is still powered on. this will be useful when you for example want to copy CHDK to another sdcard when youre in the middle of the road with no computer. Copy CHDK (and chdk folder probably) into RAM, switch cards, copy RAM content to card, set bootable flag. in bugtracker

26 - udumper being able to write more than one file - as of now, when you use udumper and you want to dump more than one camera, you have to use several sdcards (when you dont have a computer). is it maybe possible to dump more than one binary to the card? possibility: maybe. difficulty: probably high. useful: yes. priority: low in bugtracker

27 - usb detection not only in script - like in SDM, it should be possible to use USB remote shutter without script. there should be an option in the chdk menu, that you can decide between "script only, non-alt-mode only, both, none (last setting is for when you connect cam to computer). if set to both or non-alt-mode only, pressing the usb shutter should perform a predefined action (setting should be in the menu as well), such as shutter_full_press or halfpress+fullpress (of course NOT in scriptmode, as in that you decide via the script what will happen). useful for when you for example want to be able to use other buttons like zoom while using usb remote. difficulty: the code is in SDM already, can't be too difficult to port. useful: yes. priority: someone "only" has to port it. another idea: there *should* be an icon on screen telling you what mode you are in. if you connect the camera to the pc and nothing happens you then know why. also: if set to "script only", it should really only be used in script, this means you can connect cam to PC in this mode.  in trunk

28 - raw develop - move into filebrowser - move the raw develop function into the filebrowser (where raw average etc already are). small change, requires C skills though, as the filebrowser menu is "full" (see here. along those lines: remove "noise reduction" from the Raw menu and put it into overrides. reason: NR does NOT only affect raw, but jpegs as well. priority: low. useful: yes (less confusing, better structure).in trunk

29 - erase jpg with corresponding raw - read about it here. Maintainer: Wontolla. Status: almost done. needs a few optimizations (adressed in thread) and maybe some debugging. Shouldnt be too difficult, can be put into trunk. useful: certainly. maybe pair it with options like "delete ALL raws" or "all avis" and the like (hint: batch erase, delete jpegs in given range (date, number, etc)).  in trunk

30 - Format SD card in camera and retain CHDK on card - will be difficult, needs deep knowledge of asm and the inner workings of chdk and the cam. what needs to be done? copy chdk binary & chdk folder to RAM, format sd card, move stuff from ram to sdcard, set bootable flag. this is of course different on cards with more than one partition. difficulty: very difficult. useful: when on the road and you forgot to delete some pics you already copied to pc, this comes in handy (when you have a lot of pics so manually deleting them is not an option). also it is some kind of defragging. priority: low.
also on this matter, when sdcard slot open, disable the check that instantly shuts off camera, so maybe you can change sd cards on the fly, copy chdk to new card. for those occasions on the road without computer, but with "fresh sd card". (also in "jumping between different CHDK versions") in bugtracker

31 - in playback - better indication of script running/ending - as of now, using scrips in playback is not as easy as in rec mode, for example it is lacking the blue "console" that for example says "script interrupted". makes debugging and general use of scripts in playback mode difficult. before you ask: yes, using scripts in play mode IS helpful. especially later when you can override the rec/play switch via script (and the modedial). difficulty: i *suppose* it is quite easy, as the code is already there in rec mode. priority: low as of now, can rise when the mentioned rec/play switch override is arrived. useful: yes (to me at least ) in bugtracker

32 - elf edition - see here. will be very important soon. reason: chdk can not grow in size forever. to maximize features and usability, some sort of "on the fly loading of code" has to be introduced. thus the elf edition was born (not really born yet, but the idea and some code is there!). if you are an asm & c freak, please support mx3. Will definitly spawn a whole lot new features. difficulty: very difficult. useful: of course it is useful, dummy! priority: very high. go coders, go! update: mx3 confirmed that chdk ELF will be there soon... in bugtracker

33 - more info in splash/about/info screen - integrate info from vers.req into a "information page" (total shoot count, owner and the like). either integrate it into the chdk splash loading screen or create a dedicated screen in the menu. speaking of the splash screen: customizable duration of being shown, and/or maybe a toggle if the screen should vanish only after a button press (or after some time AND button press if time isnt run down yet). sounds difficult, but it is easy (in my eyes) code-wise. priority: low (it's a bit of eye candy). while on the subject, maybe the splash screen can be customized (color etc). and we need adverts in it, like in SDM (bigger splash screen, provided an "image" and an url in it too!). in bugtracker

34 - zoom bar (on cameras that dont have any) - one of my personal wishes. on my a620 i lack the zoombar. in s-series when you zoom in and out you have a fancy bar indicating how much "Zoom range" is left and where you are right now (for example when you have 12x zoom capabilities, you see you are at 4x without having to read a number, you see it directly on the bar). under the bar canon wrote (in my s3is at least) the maximum/minumum focus range. also incorporated should be the option to have it shown all the time or only when zooming in/out. i have the code already, stalled at 80% because of some issues with refreshing of the screen/drawing. will open a thread about it eventually. difficulty: not really difficult. useful: i guess to some. priority: low. in bugtracker

35 - edge overlay - currently being worked on by hiker_jon. see this thread. if done there are A LOT of applications that will benefit from it: stereo shooting (with a single camera!), stop motion ("onion-skinning"), panorama. Also by directly drawing on the screen it may be possible to introduce some high quality icons for the CHDK OSD. maintainer: hiker_jon. difficulty: difficult. priority: high. useful: yes.  in trunk

36 - control sounds in scripts - as far as i can tell EWAVR already found out most of what is needed to accomplish that here. goal: to have in script commands like play_beep or some other predefined sounds (probably the custom sounds you can configure in the canon menu only - maybe other wav files later??). useful for example for group shots (play the sound of a giggling child, everyone in the room will smile!) or for bird-watchers (run script that periodically plays sounds of some birds, also run motion detection, come back later to find pictures of birds making love to your camera!). there are ALOT OF possible uses here, thus usability: high. priority: somewhere in the middle. difficulty: EWAVR seems to have found most of it already. along those lines: mp3 player (or at least wav player), but not as important.  in trunk

37 - anti-theft protection - name says it all. As of now we have a partial solution in creating grid files (see here and here. for this to be useful we have to enable grids in playback as well. also a shortcut has to created in order to quickly "disable" the antitheft protection. probably a toggle for the grid ala "run EVERY startup" too. up to here i can easily implement this myself. next step: two grid settings, one for normal grid use, one for startup (protection). this is merely a workaround though (and misuse of grids), also when the antitheft grid is shown, we need to disable ALL other chdk icons (as these will flicker!). another way: code a dedicated antitheft function, where you can either enter the information that will be shown on screen (virtual keyboard anyone?) or supply it via a text file. it can be disabled by a special shortcut. the icing on the cake would be of course to use the new edge-overlay feature to display a predefined jpg, as in thise case you can really run wild in your imaginations on what you could do. idea: maybe ewavr finds a way to delay the canon startup image (which can be custom set in the canon menu) until a button is pressed. other uses, besides anti-theft: you're at a party or wedding and people constantly want to see the pics or take some own pics when you leave your camera somewhere (hey, photographers have to take a drink sometime too). this would lead to your camera being left alone. other application: when you take pictures of girls (often your own girlfriends or wives) they are constantly nagging about "hey, i think i look ugly on this picture" and are secretly deleting them from the camera when you are not looking (really, this happened a few times before ). priority: low. difficulty: depending on implementation: low to high. useful: yes.
 in bugtracker

38 - USB stuff - very controversial topic. What we know so far: up to now the usb protocol in the firmware was not identified, we dont even know if it is handled by hardware or by software. we can only check for voltage. If we could SET some usb bits we could control external devices, without the use of LED blinking. if we could use the full USB speed (thus the whole protocol) and also activate USB in record mode, we could turn every camera into a fully fledged remote capturing device, including control over all camera parameters. this is depending on great ASM skills. thread USB gets talked about a lot can be found here. This is mainly about the use of external USB mics, but has a lotta in-depth thoughts as well. Maybe by analysing the canon sdks we could deduce some information on how usb is used in these cameras, and MAYBE code a virtual usb host. difficulty: difficult, up to impossible. Useful: very useful. priority: hm, not easy to say. Hint: Universal Remote-capturing abilities can also be achieved when we implement the rec/play button override, as then you could always switch between taking pics and uploading them (in some cams you can also upload (to the camera) files other than images, which means you could send simple commands to chdk) in a script. in bugtracker

39 - time-related functions - for photographers: sunset/sunrise for a given set of coordinates and a given date (should also be accessable in scripts). this isnt difficult to implement (codewise), however i dont have a clue about sun, moon & astronomy. probably needs skills of a mathematician, c coder & astronomist. Also a time function: Implement some kind of stopwatch (for events like formula one - 1st shutter activates stop watch, 2nd press sets "lap" and so on. with this it should be easier to anticipate when to press the shutter). difficulty: low. priority: low. useful: not for everybody. in bugtracker

40 - in-camera curve editing/applying - already in the making here - maintainer: toinech. read more about it in the thread. this probably is more of a "pro-feature", as most p&s owners never even heard of a curve before. still a nice feature though. difficulty: i dont know.  In Trunk now!

41 - another photographer's dream: Best shot selector - read about it here. also dubbed "poor man's IS". as i am no photographer, i wont go into details here, read all about it in the thread. should be possible to implement in theory. difficulty: probably high. useful: *i* doubt it will be used that often, but i may be wrong. 
bugtracker

42 - customizable script console - customizable as in size (bigger/smaller font, more/less lines, longer/shorter lines, position), maybe even not only in script menu but also directly via a script.
difficulty: havent looked at that part of the code yet, i supposed it cant be easy, otherwise someone would have already done at least the length of the lines part. debugging and overall comfort would greatly rise if someone codes this. priority: low. difficulty: unknown. useful: certainly. bugtracker

43 - ubasic command: print_to_screen - as in for example print_to_screen("hello",10,10,5), whereas "hello" is the text to be printed, "10,10" the position and 5 the size of the font (more parameters welcome). this can and will be useful for things like counters, or debugging when you are faw away from the screen, or for advanced slideshows (!!!). difficulty: should be possible to code. priority: low. useful: yes, wouldnt be used that much though. bugtracker

44 - ubasic command: get_file_counter - Jucifer already created such a command in [http://chdk.setepontos.com/index.php/topic,688.0.html]here[/url]. Useful for things like bracketing etc. However it needs to get into trunk While we are at it, it might be a good idea investigating in terms of "canon jpg counter" that is displayed in playback in the info when you press the display button. but i think it is not possible to get this value in rec mode, as it is calculated only in playback (see here). useful: yes. priority: middle (for only a few scripts).  Now in Trunk!

45 - jucifers other features - see the whole thread here. some of these i maybe already described here. please, devs, include these into official trunk. difficulty: code already written.  now in trunk!

46 - ubasic: random - i already wrote most of it. my math skills suck though, so i need a mathematicians help here. you can use random in a lot of cases. right now my random isnt as random as random is ought to be. maintainer: phyrephox. difficulty: low. priority: low. example where it is needed: click me.  now in trunk!
 
47 - exif data - write either more (or more accurate) data into the exif fields, or - if not possible - into extra textfiles (either a small database or a corresponding txt to each jpg). you could write down all chdk settings that are somewhat relevant for photography. with better tagging i mean all tagging of the overrides, including for example lens override (teleconverter etc). makes comparing different settings very efficient. also has a lot more advantages. difficulty: i dont know. priority: people need better exif tagging. useful: yes.
update: at least include something like "this pic was taken on a camera that was enhanced by CHDK. you can get it from (insert link). chdk needs ads
bugtracker

48 - lens override - maybe add some presets to the lens override settings (for example for fisheye, WA and tele) that people might either define themselves or we have a small database of (canon) converters included. while you are at it, create a small icon that will popup on the screen when you have the lensoverride to a setting other than 100 (if lower than 100, draw a WA icon, if higher... you do the math). MAYBE even let that override setting influence tv/av setting, to compensate for blur. difficulty: depending on implementation ranging from mid to high. prio: low. useful: to people who use convertes frequently (like me).
bugtracker

49 - during moviemode: override of shutter, aperture, iso - has been requested a lot of times, it is unknown if it is even remotely possible to do that. needs ASM skills. priority: probably high. useful: yes!  bugtracker

50 - overrides during long exposures - Dataghost gave me the idea here, as he found out a way to control shutter to create darkframes. maybe it is possible to unlock zoom during long exposures? normally you can only do that by hand with a dslrs lens. would allow for more creativity for photographers. maybe other things can be overridden as well during long exposures, who knows. requires deep asm knowledge. prio: low. useful: for hardcore photographers.
bugtracker

51 - creation of darkframes - "custom" creating of darkframes, a long awaited feature. Since DG found out how to control the shutter (see previous entry) this should be possible for all models. creating a darkframe should be a simple as pressing a menu entry and a desired shutter time. would allow for substraction of darkframes at home on the pc (better output than using cameras own DF substraction). i suppose most of the basic functionality is written/found already by Dataghost. useful: yes. prio: low.
bugtracker

52 - IS features - by using the orientation sensor it *might* be possible to somehow include a kind of IS feature on cameras which dont have IS. possible a small warning icon or something. it would be very useful to display current camera shake, maybe even with some small statistics to be able to compare different holding techniques. Dataghost (see here) recently found a ton of useful applications using IS, and even more can be built around IS. for example by squeezing the sensor into each corner of the picture you can create some kind of panoramas without even having to move the camera. or you can recenter the IS mechanism, in case it is off center a little. one of the most useful features: artificial horizon (might be even possible on cams without IS). see his thread. priority: high (will spawn a lot of useful features). difficulty: probably high (ASM!). bugtracker

53 - zoom override - put some kind of zoom override into the override menu. useful for when you want to take your pictures on a fixed zoomlength. a feature that might also be possible then: zoom bracketing. priority: low. difficulty: it is possible, i guess even somehow easily "implementable". useful: certainly. bugtracker


54 - autoshutdown on disk full or low battery in script execution - you can either shutdown cam in script (needs fingalos shutdown command!) or tell the cam to do it automatically when it is in script mode. there should be a submenu in the script menu, in which you can activate a certain behaviour (shutdown, stop script, fire flash, beep (when it is implemented)) on certain situations (free filespace below a defined range, battery below defined range). this is extremely useful for when you do for example timelapses or the likes where you dont have access to the camera all the time. the flash might be useful for situations like when you attached the cam to a kite and you dont know if the sdcard is full yet. might need asm skills (fire flash without taking picture!). prio: low. useful: yes. bugtracker

55 - override modedial & playback/rec switch - a lot of this feature has been implemented here already by Jeff666. needs to be done for all camera models though. as soon as this is done, this will spawn a lot of cool features, for example the possibility to have the camera switch between playmode/recmode in order to upload images to pc - and maybe commands from pc to chdk (upload special formatted txt files). especially useful for automated tasks like when your cam is attached to kite and you want to be able to record movies AND take pictures. difficulty: most of the code is there already. priority: high. useful: yes. bugtracker

56 - lcd brightness / LCD control (on/off) - DG already found most of it here. useful for energysaving. difficulty: cant say. priority: high. useful: everybody will use that in future, for example to dim down the light in the night. bugtracker

57 - changes regarding alt-button - maybe include a toggle in menu to switch between "alt mode on LONG click?" or "alt mode on short click". i often (and i am not even a "newbie" anymore) press the alt-button accidentially. this would prevent it, as you would have to press it longer. on my s3is the default alt-button is the printbutton, which also serves as shortcut button in rec mode. when i press it long enough, i DON'T enter altmode but the shortcut button actually is pressed. while we are talking about the alt-button - make it more configurable on all camera models, not only the ones with a lot of buttons. especially useful with the "on long press" trick. a lot of underwater cases dont have a button for the direct print button (just an example). priority: low. difficulty: somewhat low. useful: yes, to some.  bugtracker

58 - offline raw compression (dng/zip) - maybe even "online" (before writing the raw to sd - but i doubt that its possible!). include a new entry in filebrowser that enables user to compress a given set of raws to either DNG or zip. should be easy to implement, however it will be a huge algorithm and will blow up chdk in size. also it uses ALOT of cpu, camera will get HOT. and there always is this argument: you can do it on the pc. priority: low. useful: yes. difficulty: easy (offline). bugtracker

59 - assigning buttons with new functions. find out which buttons arent used in which modes (will be tedious work, needs probably work done by a lot of forum members) and reassign them new functions. FOR EXAMPLE i did this in here for fast ev switching (up & down buttons). should be configured in an extra menu. priority: low. useful: yes. difficulty: to me it was very difficult, for experienced coders this can be done in a jiffy. bugtracker

60 - "steal some features" of some other branches - SDM has a lot of nice features, for example USB remote not only in script, rangefinder and the XML data. Fingalo also has AFAIK some stuff that hasnt been included in main trunk yet. very useful for example from the SDM build: the ability to flip screen and ALSO the chdk menu/osd. he reads out orientation sensor, this way you can read chdk in every which way. most of it is written already, so there is no difficulty (besides porting/copy & pasting). priority: ranging between low to high. useful: all of it. bugtracker

61 - more & better control over leds - see Dataghosts Minidisco here. if this can be done via script, there can be a lot of creative uses. Also useful for anti-theft. difficulty: code is there already, needs ASM skills to port to other cams. useful: yes. priority: low. bugtracker

62 - built-in intervalometer - in my s3is, i have a built-in intervalometer that sends the camera to sleep in between shots (when it wakes up, it sets all options to the settings it had before going to sleep, including zoom and the likes). we need to find out if this sleep mode can be used outside of the intervalometer, if it consumes a lot of energy and most importantly - does it exist on other cameras as well? Also: Can the intervalometer settings be overridden, as in "take more than 100 pictures (or shorter/longer interval)". difficulty: probably needs asm skills. priority: low. useful: to some. bugtracker


63 - enhance motion detection - speed is being worked on. what about gestures? reacting on colors (face-color)? at least the reaction on colors is feasible, quite difficult to implement though. i rate this as very very low priority. bugtracker

64 - built-in image/video viewer - i understand divx videos cannot and probably will never be played. and also tiff files can never be shown. However, i do not understand why the camera displays files ONLY if they are named after in a special formatted way (some ISO standard), even if they have been recorded with the same camera. same applies to movies. it is very annoying copying my vacation pictures to the sdcard only to find out (when i'm at friends) that the camera does not show them. maybe some ASM guru finds out the image/video "filter" of the cameras and kind of disables or enhances it. this way we ultimately have a portable imageviewer/movieplayer without having to rename/reorganize all media first. difficulty: high. priority: low. useful: very useful. bugtracker

65 - extras - some useful extras, not really neccessary though: more games (tetris, snake..), some IS orientation sensor fun (i've seen many applications of something like that on my nokia n95...), worldclock for cameras that dont have it already... very low priority, yet useful.

66 - my own small bugfixes, features - last but not least i feel my own modifications should not be forgotten , see them here. features bugfixes and a set of new useful features. most of the code is finished, ugly though. needs documenting, cleaning and being put into trunk. in trunk now!

i just noticed we have a lot of stickies everywhere, we gotta reduce these or reorganize them in order to prevent confusion and "too much of information" for newbies.

Link to poll: CLICK ME!
                                             

Wow, what a list!

Why not move this list to Trac and start building a proper roadmap, feature list as well as track bug reports there?

The project is large enough to warrant such treatment. Also, allowing more people (e.g. Jucifer) to branch in Trac will allow easier merging later on into trunk (by the "maintainers").

The feature descriptions themselves could move to the Teac wiki after decided in the forums, making it easier to create proper user documents.

Also, splitting into major/minor releases might make it easier to drop things into trunk w/o hurting less adventurous users.

Maybe even subnumbers for stable/uneven for testing? e.g 1.2 is stable maintained while 1.3 gets all the test features which are later tuned into 1.4 stable? (ring a bell?)

I also think we should focus more on projects like ELF support and other options to enable customizations of CHDK w/o burdening trunk with too many features. A good example is scripting languages, there're a zillion options (uBasic, Lua, Pawn, Ruby, Python, whatever) - Why should this be compiled in and not run externally? Same for games, curves & filters, etc.

mkmenuts

you are right about everything. BUT: the devs decided against trac, as it really isnt flexible enough to handle all that. acseven is working on a bugtracker that will be integrated right into the forum. this will also take care of the other things you mentioned - i hope. since integration of the bugtracker is not done yet, i created this thread to make sure features don't get lost (a lot of these feature requests i found in abandoned threads). the poll was created to somehow gauge people's priority, not really to put some kind of "pressure" on the devs. to get feedback maybe. voting for features might also get integrated into the bugtracker.
yes, ELF is one of the most important features to be developed, however development hasnt even started yet. in the meantime, people with c skills can pick one or two of the mentioned features (that i rated "easy) and implement these themselves, and also get to know CHDK and it's inner workings. by the time ELF is ready we will have bugtracker, roadmaps etc.
perhaps i'm just dreaming

About this ELF support. My opinion is to make more use of Lua inside CHDK itself. Not only for simple user scripts. E.g. It can easily be used to replace nearly everything that hides behind the "Miscellaneous" menu.

There will be no need to learn C or how to use a cross compiler to make extensions to CHDK. The entry barrier to write extensions in Lua is so much lower than with C.

And I write this not only because I am a fan of Lua. If you want you can take any script language you like (well, not uBasic) and have the same effect on possible developer contributions.

But to rely on dynamic ELF loading to do the job will not bring you the masses of contributions you will get with a script language.

I'm willing to do more Lua integration into CHDK. But there needs to be a decision that CHDK wants to go this way. I'm not in favor in doing all the work just for my own CHDK/Lua version I'll have to maintain then.

My belief about "13 - create ONE chdk" is pretty close to yours. This must be one of the top priority points to make happen. But as I see it this is more a political thing than anything else, or not?

yes, ELF is one of the most important features to be developed, however development hasnt even started yet. in the meantime, people with c skills can pick one or two of the mentioned features (that i rated "easy) and implement these themselves, and also get to know CHDK and it's inner workings. by the time ELF is ready we will have bugtracker, roadmaps etc.
perhaps i'm just dreaming

but ELF project almost complited.
it laks just one ported function

very well then, didn't know that
keep us informed when it is done

very well then, didn't know that
keep us informed when it is done

I did nothing to continue project
it is in the same stage as I published it

uh okay, should have followed that thread more intensively. anyways, updated the colorcode of the ELF entry to reflect current development.
still: let us know when you have progress or in case you need anything (i for one can test, and later sure as hell code a small module).