Suggestion for revision of the current 'camera.h' system. - General Discussion and Assistance - CHDK Forum

Suggestion for revision of the current 'camera.h' system.

  • 26 Replies
  • 14246 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Suggestion for revision of the current 'camera.h' system.
« on: 05 / April / 2011, 23:48:57 »
Advertisements
I'm thinking that the current system of storing camera specific settings in 'include/camera.h' for all cameras needs to be revised.

While this probably worked well when there were a handful of cameras, with the number of supported cameras in CHDK today, it's getting a bit cumbersome.

Personally, I find it difficult to find the right section if I need to check and/or modify a setting - as new cameras are added or settings are changed the location in the file where my cameras are stored changes, so I have to keep searching for them again. In addition the camera.h files across CHDK, CHDK-DE and SDM are all different, with the cameras being listed in different orders, and with different settings in some cases. Synchronising changes across the various incarnations of CHDK is a difficult process.

I am proposing that each of the camera specific settings be moved into a separate 'platform_camera.h' file, in the platform/XXX directory for each camera. The 'include/camera.h' file would contain the default values for each setting, along with the documentation on the purpose and usage of each setting.

At the end of the include/camera.h file there would be a line:
    #include "platform_camera.h"
which would then load the camera specific settings for the current camera version being compiled.

In order for this to work the compiler needs to know how to find the correct platform_camera.h file. The easiest way to do this is to modify the makefile.inc file by changing the line:
    CFLAGS+=-I$(topdir)include $(PLFLAGS) $(CPPFLAGS)
to
    CFLAGS+=-I$(topdir)include -I$(topdir)platform/$(PLATFORM) $(PLFLAGS) $(CPPFLAGS)

This will add the platform/XXX (for camera XXX) to the search path that the compiler uses to find the header (.h) files. The compiler will then automatically use the correct file.

Appropriate comments should be added to include/camera.h and each platform_camera.h file on the purpose of the files and how to go about adding new settings (e.g. place the default value with documentation in camera.h, and override values in platform_camera.h, using #undef and #define).

This change could be done gradually by replacing the existing final error message in camera.h with the #include line above. Over time cameras could be moved to individual platform_camera.h files.

However I think a better approach would be to write a program (possibly a perl or php script) to take the existing camera.h and create all the platform_camera.h files automatically, then re-write camera.h with just the defaults and #include line. Once this is done the resulting patch can be applied to the main CHDK code trunk in one change, ensuring all cameras now use the new system and with the correct values - this eliminates any potential human error arising from manually migrating cameras to platform_camera.h files.

This program could also be used on CHDK-DE and SDM as well as CHDK so that all three can be converted to this model. Ultimately comparing and synching camera settings across the CHDK variants will be lot easier and, in my view, adding new cameras will be easier as well.

I'd appreciate any feedback on this idea (both for and against).
If there's enough support I'll start working on the conversion program and CHDK patch.

Regards,
Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: Suggestion for revision of the current 'camera.h' system.
« Reply #1 on: 06 / April / 2011, 00:06:54 »
easy for me to say as it will not be me doing the work, but I support this 100%

Ported :   A1200    SD940   G10    Powershot N    G16

Re: Suggestion for revision of the current 'camera.h' system.
« Reply #2 on: 06 / April / 2011, 05:51:16 »

I am proposing that each of the camera specific settings be moved into a separate 'platform_camera.h' file

Makes it easier to maintain and compare.

Quote
The 'include/camera.h' file would contain the default values for each setting, along with the documentation on the purpose and usage of each setting.

SDM does not use many of the CHDK settings but that does not matter.

Quote
This program could also be used on CHDK-DE and SDM as well as CHDK so that all three can be converted to this model.
If there's enough support I'll start working on the conversion program and CHDK patch.


Well, a nice little project for your Winter, it is Spring here and I would like a rest so carry on  :)

Incidentally, CHDK developers are probably tempted by the possibilities of extended memory.

I will be going in the opposite direction and creating a leaner, simpler SDM.


David

*

Offline reyalp

  • ******
  • 14126
Re: Suggestion for revision of the current 'camera.h' system.
« Reply #3 on: 06 / April / 2011, 12:41:27 »

I am proposing that each of the camera specific settings be moved into a separate 'platform_camera.h' file

Makes it easier to maintain and compare.
Agreed.
Quote
Incidentally, CHDK developers are probably tempted by the possibilities of extended memory.
Well exmem does give us enough RAM for a DOOM port. Just sayin ;)
Don't forget what the H stands for.

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Suggestion for revision of the current 'camera.h' system.
« Reply #4 on: 06 / April / 2011, 17:45:45 »
Agreed, camera.h is sort of a mess.

Whatever is done, it would be really neat if settings could be easily parsed into a table to document which cameras currently have (e.g.) a new feature enabled or lack aperture -- something that really should be in the wiki/whatever, updated by the autobuild site scripts for both developers and users to see (this isn't impossible even with current camera.h but it really doesn't invite one to cook it up...)

And while we're at it...for porting a new camera, I imagine it would be useful to have a master camera.h template that has all potential #defines documented and commented out. It could be automatically created with a script that harvests unique entries from all platform camera.h files.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Suggestion for revision of the current 'camera.h' system.
« Reply #5 on: 06 / April / 2011, 18:13:24 »
Well exmem does give us enough RAM for a DOOM port. Just sayin ;)

or:
- MAME
- Web browser (with an eye-fi card)
- Video conferencing (for cameras with a swivel screen, and an eye-fi card).
- ...

but probably getting too far off topic now :D

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Suggestion for revision of the current 'camera.h' system.
« Reply #6 on: 06 / April / 2011, 18:23:53 »
Whatever is done, it would be really neat if settings could be easily parsed into a table to document which cameras currently have (e.g.) a new feature enabled or lack aperture -- something that really should be in the wiki/whatever, updated by the autobuild site scripts for both developers and users to see (this isn't impossible even with current camera.h but it really doesn't invite one to cook it up...)

Funny you should mention that - I wrote a (very) quick and dirty program last night to create a .CSV file from the current camera.h, with settings as rows and cameras as columns. The idea was to do the same after the split into separate files and compare the two to make sure there were no changes introduced.

It's not a trivial task, and I made some assumptions based on the current file contents (around comments, formatting etc) in order to parse the file. To be able to do it automatically regardless of what gets put into the files would be quite hard.

I'll post the result tonight if anyone's interested.

Another approach (suggested by reyalp) would be to turn the problem around, and use some sort of 'configuration management' system to store all the camera settings. Then generate the camera.h file on the fly when compiling each camera. This would be good; but could be quite complex - it would need to be platform independent (Linux, Windows, OS/X, ...) and also have SVN integration (updates, merging, & patching).

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 14126
Re: Suggestion for revision of the current 'camera.h' system.
« Reply #7 on: 06 / April / 2011, 22:00:59 »
It's not a trivial task, and I made some assumptions based on the current file contents (around comments, formatting etc) in order to parse the file. To be able to do it automatically regardless of what gets put into the files would be quite hard.
FWIW, there are already my horrid sed scripts that generate lua from the propset*.h and modemap.h headers, which have similar restrictions.

Having the camera.h stuff split between cameras will make it significantly easier to do this kind of thing.
Quote
Another approach (suggested by reyalp) would be to turn the problem around, and use some sort of 'configuration management' system to store all the camera settings. Then generate the camera.h file on the fly when compiling each camera. This would be good; but could be quite complex - it would need to be platform independent (Linux, Windows, OS/X, ...) and also have SVN integration (updates, merging, & patching).
My idea was to keep the settings in a flat file that was even simpler to parse than a .h file (one file per camera). You'd the build process would use that to  generate .h and makefile includes etc as needed. I wasn't thinking of it at the time, but it would certainly make human readable output like wikitext easy too. All of this should be doable (though not pretty) with shell / sed / grep, which are already required.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Suggestion for revision of the current 'camera.h' system.
« Reply #8 on: 07 / April / 2011, 04:48:39 »
Attached is the spreadsheet I generated from the current camera.h showing all the values set for each camera (and the defaults). I've made the rows the cameras and the columns the settings.

In each cell 'undef' means that the value is defined as '#undef XXX', blank means the value is not present.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Suggestion for revision of the current 'camera.h' system.
« Reply #9 on: 07 / April / 2011, 06:12:50 »
OK, I've written a perl script to split camera.h as described above (attached in case anyone is interested).
I've run this against CHDK (1132), CHDK-DE (619) and SDM (1.85) and it seems to work correctly for all versions (run on Windows 7 64 bit using ActiveState PERL 5.12.3.1204).

When I create the spreadsheet (previous post) from the original camera.h and the split files I get identical results so it looks like the split works (unless anyone can see any mistakes in the spreadsheet).

Does anyone see any reason not to submit this as a patch for CHDK?
Speak now or forever hold your peace :)

Phil.


CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics


SimplePortal © 2008-2014, SimplePortal