Adding new cameras, applying patches into trunk (with source code prepared)

  • 1479 Replies
  • 180369 Views
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #140 on: 20 / February / 2011, 20:18:25 »
Advertisements
<posted in the wrong place - sorry - moved to the correct thread>
« Last Edit: 25 / February / 2011, 06:54:23 by waterwingz »

*

Offline philmoz

  • *****
  • 2936
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #141 on: 25 / February / 2011, 02:06:03 »
Another small update for G12 & SX30 (patched against changeset 1067).
- updates for exmem memory allocation to allow these cameras to exclude video buffer memory
- fixed set_zoom function to correctly wait until zoom is finished before returning
- fixed startup code for SX30 so that init_file_modules_task gets called correctly in all cases
- changed startup code for SX30 so that short on/off button press starts in record mode and long press starts in review mode (previously was the other way around).

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)

Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #142 on: 25 / February / 2011, 20:31:14 »
Hi Phil.


I cannot find the thread where you discussed using DNG4PS2 calibration feature so I will just ask here.

An IXUS105 user presented me with a RAW file of the palette image.

The JPG compression artefacts are quite pronounced even at lowest ISO.

Anyway, I was eventually able to get all phases of the calibration to run but only seven areas from 22 had an error less than 10 %.

What was your experience of this ?

*

Offline philmoz

  • *****
  • 2936
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #143 on: 26 / February / 2011, 01:32:05 »
Hi Phil.

I cannot find the thread where you discussed using DNG4PS2 calibration feature so I will just ask here.

An IXUS105 user presented me with a RAW file of the palette image.

The JPG compression artefacts are quite pronounced even at lowest ISO.

Anyway, I was eventually able to get all phases of the calibration to run but only seven areas from 22 had an error less than 10 %.

What was your experience of this ?

I was unable to get DNG4PS2 to work for the SX30. Instead I used the 'colorcheck' option in dcraw to create the calibration table (you have to compile your own version of dcraw to enable this).

I have not done this yet for the G12 (it's is using the G11 calibration matrix).

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)


*

Offline reyalp

  • ******
  • 10057
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #144 on: 26 / February / 2011, 18:31:46 »
Another small update for G12 & SX30 (patched against changeset 1067).
- updates for exmem memory allocation to allow these cameras to exclude video buffer memory
- fixed set_zoom function to correctly wait until zoom is finished before returning
- fixed startup code for SX30 so that init_file_modules_task gets called correctly in all cases
- changed startup code for SX30 so that short on/off button press starts in record mode and long press starts in review mode (previously was the other way around).
Added all except for the startup change in changeset 1068

I'm hesitant to add the startup change because
- It's inconsistent with all other cameras.
- Unexpectedly opening the lens is less friendly that unexpectedly not entering REC mode.

I'm open to being convinced otherwise. Ideally this should be a user option, but it happens before we can read the CFG file.

Possible solutions:
1) We now have the ability to switch modes from normal CHDK code. This didn't exist when the "long press to start in rec mode" feature was initially added.

We could check a cfg value in main startup, and switch to the desired mode. We could still capture the button state as early as possible to detect a long / short press. This would probably result in slightly longer startup times, since the camera would start fully in play and then switch to REC.

As an aside, it should be possible to capture the switch state earlier, before copy_and_restart and stash the value somewhere (data TCM ?). This should reduce the length of the required press slightly, not clear if it is worthwhile.

2) Make it a compile time option.

3) store the value somewhere else. This would have to be
- a specific disk sector
- in the CHDK image itself (requiring proper encoding when updating)
- in camera flash
None of these are very attractive.
« Last Edit: 26 / February / 2011, 18:33:38 by reyalp »
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 2936
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #145 on: 26 / February / 2011, 22:13:43 »
Added all except for the startup change in changeset 1068

I'm hesitant to add the startup change because
- It's inconsistent with all other cameras.
- Unexpectedly opening the lens is less friendly that unexpectedly not entering REC mode.

Thanks reyalp,

I change the SX30 because that's the way the G12 was working so I thought I had the SX30 wrong.
Attached is a patch to make the G12 work consistently with the standard (long press of on/off to start in record mode, otherwise start in playback mode).

Ideally it would be good to use the value the camera determined during the pre-CHDK startup; but this gets overwritten by the load of diskboot.bin.

One idea I've been thinking about is to not embed the CHDK code into diskboot.bin; but instead load it from another file on the SD card (in the diskboot.bin code).
This might speed up the boot process since the CHDK code would not need to be decoded/decrypted and the memory copy could be avoided (by loading the file directly to the correct location).
If the resulting diskboot.bin is small enough it would also mean that the original startup state value would not get trashed.

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)

*

Offline reyalp

  • ******
  • 10057
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #146 on: 26 / February / 2011, 22:55:06 »
One idea I've been thinking about is to not embed the CHDK code into diskboot.bin; but instead load it from another file on the SD card (in the diskboot.bin code).
This could be a good thing in many ways. However, the fact that you don't have the normal filesystem functions available will make it difficult. Even loading a small diskboot trashes enough of the OS that you really don't want to rely on anything working. Maybe you can boot enough of the canon OS the first time around, but the hooked tasks might give you trouble.

There are enough filesystem functions in the romstarter to load a diskboot, but these will only work with fat16. This might still be OK with multipartition setups, as long as they have the same behavior as the regular OS code with the "first" partition. May be worth investigating.

This is definitely something I've thought about. On the other hand, some kind of generic loadable binary support (like the currently stalled elf project) might be a better use of the effort. The "bootloader" might be a bit bigger, but the other benefits would be large.
Quote
If the resulting diskboot.bin is small enough it would also mean that the original startup state value would not get trashed.
Possible. Be aware that many cameras fail to boot an extremely small diskboot.

edit:
added in changeset 1070

FWIW, quite a few people have requested starting in REC mode as the default. Having this a compile time option would be a step in the right direction.
« Last Edit: 27 / February / 2011, 14:16:09 by reyalp »
Don't forget what the H stands for.

*

Offline quid

  • **
  • 67
  • SX130IS
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #147 on: 27 / February / 2011, 04:56:40 »
3) store the value somewhere else. This would have to be
- a specific disk sector
Maybe we can do this like Canon, and store this value in the FAT16 Boot Record's executable code (0x3E-0x1FD), which is already destroyed by BOOTDISK string.


Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #148 on: 27 / February / 2011, 11:31:31 »
IXUS120-SD940 :  Found a broken jump table and a small typo in Makefile.  Probably not worth a trunk update on its own but would be nice to add into the next rolling update ?

*

Offline reyalp

  • ******
  • 10057
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #149 on: 27 / February / 2011, 15:07:47 »
IXUS120-SD940 :  Found a broken jump table and a small typo in Makefile.  Probably not worth a trunk update on its own but would be nice to add into the next rolling update ?
Added. I like small changes ;)

changeset 1071
Don't forget what the H stands for.

 

Related Topics