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

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

  • 28 Replies
  • 24358 Views
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Advertisements
/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 :D). 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 :D). 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 :D). i announce GrAnd as maintainer of this :D 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 :D useful: yes. priority: probably low. in bugtracker

« Last Edit: 16 / October / 2008, 03:18:17 by PhyrePhoX »

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX

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