ELPH300HS aka IXUS220HS - Porting Thread - page 47 - DryOS Development - CHDK Forum
supplierdeeply

ELPH300HS aka IXUS220HS - Porting Thread

  • 861 Replies
  • 200710 Views
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #460 on: 06 / December / 2011, 12:25:36 »
Advertisements
Do you know if there's a ixus 220 hs DNG profile, to correct RAW distortion and vignetting in camera? Thanks a lot.

No, you have to create one on your own.

Maybe this makes it easy for you to create a profile: http://labs.adobe.com/technologies/lensprofile_creator/


Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #461 on: 06 / December / 2011, 13:08:18 »
Ixus 220 has a 24 - 120mm zoom lens...which focal lenghts should I make, to use settings correctly for all camera zoom?

*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #462 on: 06 / December / 2011, 14:08:47 »
In any case, I've attached some builds so others can try this out and provide feedback.

The build on my camera just got into a state where it failed to refresh the screen after closing the CHDK menu.

So, although vid_turn_off_updates() -> ScreenLock() is promising, there are still some kinks to work out.

It'd be nice if we could hook in somewhere and get the opportunity to draw our stuff on the back buffer right before the firmware swaps buffers, but I have no idea whether that is feasible (or whether the original firmware actually operates that way, for that matter).  Failing that, at least doing ScreenLock while the menu is up would prevent the worst of the visual issues, provided we can make it work reliably.  (It strikes me as odd that pretty much no two models handle screen updates the same way.  This isn't something I think Canon would do differently with every iteration???)

I tried it on the G12 and although it does make the CHDK display a lot more stable it also causes major problems.
For example if a script uses the 'shoot' command the camera tries to switch to review mode after the picture is taken. The screen goes black and the review is not shown (because of the lock presumably). The screen stays black and nothing is displayed again until the script exits.

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)

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #463 on: 06 / December / 2011, 16:52:34 »
I tried it on the G12 and although it does make the CHDK display a lot more stable it also causes major problems.
For example if a script uses the 'shoot' command the camera tries to switch to review mode after the picture is taken. The screen goes black and the review is not shown (because of the lock presumably). The screen stays black and nothing is displayed again until the script exits.

Hmm.  I was afraid there'd be trouble if we lock the screen.  Thanks for trying it out, though.  I think I'll just learn to accept the flicker.  (Staying out of Auto mode helps a lot...)

So, remaining work to be done for this port?
  • One pending patch for a remaining scripted zoom issue
  • The fact that DISP and DOWN are the same key: some CHDK functionality depends on a DISP button, and we don't have an independent one. I'm thinking we could click the button for DOWN and long-press it for DISP?
  • .DNG metadata is still a bit messed up.  in particular, the camera model name doesn't appear to be terminated properly.

Any other known issues to work on?

Wondering what the criteria are to progress to BETA.



Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #464 on: 06 / December / 2011, 21:38:16 »
  • .DNG metadata is still a bit messed up.  in particular, the camera model name doesn't appear to be terminated properly.

This isn't specific to our port; it's part of core/dng.c.  I've compared the camera name tag in Canon's JPEGs and CHDK's DNGs.  Both write the same 32-byte buffer, "Canon Powershot ELPH 300HS\x00\xff\xff\xff\xff\xff".  But there's a difference--the JPEG gives the size of the item as 27 bytes (not including the FF padding), whereas CHDK's DNG gives the size as 32 bytes (including the padding).

*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #465 on: 06 / December / 2011, 21:43:28 »
  • .DNG metadata is still a bit messed up.  in particular, the camera model name doesn't appear to be terminated properly.

This isn't specific to our port; it's part of core/dng.c.  I've compared the camera name tag in Canon's JPEGs and CHDK's DNGs.  Both write the same 32-byte buffer, "Canon Powershot ELPH 300HS\x00\xff\xff\xff\xff\xff".  But there's a difference--the JPEG gives the size of the item as 27 bytes (not including the FF padding), whereas CHDK's DNG gives the size as 32 bytes (including the padding).

If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.

What program is having trouble with the field?

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)

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #466 on: 07 / December / 2011, 08:02:02 »
If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.

Not according to the TIFF specification:

Quote
2 = ASCII   8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary 0).
...
The value of the Count part of an ASCII field entry includes the NUL. If padding is necessary, the Count does not include the pad byte. ...

Each tag has its own offset field, so it's not necessary to know the true size of a tag on disk in order to find the next tag.

What program is having trouble with the field?

Picasa 3.5.  I also remember reading about this problem somewhere else, but I've been unable to find where...

*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #467 on: 07 / December / 2011, 14:23:53 »
If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.

Not according to the TIFF specification:

Quote
2 = ASCII   8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary 0).
...
The value of the Count part of an ASCII field entry includes the NUL. If padding is necessary, the Count does not include the pad byte. ...

Each tag has its own offset field, so it's not necessary to know the true size of a tag on disk in order to find the next tag.

What program is having trouble with the field?

Picasa 3.5.  I also remember reading about this problem somewhere else, but I've been unable to find where...

Thanks, I wasn't aware of that. It's been broken for a long time then.
Shouldn't be hard to fix. Will take a look tonight.

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)


*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #468 on: 08 / December / 2011, 07:35:24 »
If the DNG code is writing 32 bytes to the file then the size of 32 is correct.
The 0 terminator on the string should make sure that any program processing the DNG ignores the padding bytes.

Not according to the TIFF specification:

Quote
2 = ASCII   8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary 0).
...
The value of the Count part of an ASCII field entry includes the NUL. If padding is necessary, the Count does not include the pad byte. ...

Each tag has its own offset field, so it's not necessary to know the true size of a tag on disk in order to find the next tag.

What program is having trouble with the field?

Picasa 3.5.  I also remember reading about this problem somewhere else, but I've been unable to find where...

Try this change to create_dng_header in dng.c (the 2nd and 3rd lines are new):

Code: [Select]
    switch (IFD_LIST[j].entry[i].tag) {
     case 0x110 :                                                                                       // CameraName
     case 0xC614: IFD_LIST[j].entry[i].count = strlen((char*)IFD_LIST[j].entry[i].offset) + 1; break;   // UniqueCameraModel
     case 0x132 :
     case 0x9003: IFD_LIST[j].entry[i].offset=(int)get_date_for_exif(exif_data->time); break; //DateTimeOriginal

This doesn't cause any problems for me; but I've never seen the problem happen.
If this works for you I'll update SVN.

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)

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #469 on: 08 / December / 2011, 22:36:57 »
Great work guys. I have it working on my camera.

Anyone know any time lapse scripts that work?

could you recommend one please.

Thanks.

 

Related Topics