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

ELPH300HS aka IXUS220HS - Porting Thread

  • 899 Replies
  • 399359 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #450 on: 04 / December / 2011, 14:14:44 »
Advertisements

I changed the while loop to look like the SX30 etc. one:

Code: [Select]
while (zoom_busy) msleep(10);
... which fixed the problem for the IXUS 220 (allowing me to zoom all the way out in the lua script with no hang), and I suspect might fix the S95 too, although I can't test that.


This fix has been confirmed to work for the S95 as well; but I haven't got around to fixing the code.

Adding the msleep(10) to the default case loop should also be done in my opinion (infinite loops are not a good practice in my opinion).

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: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #451 on: 05 / December / 2011, 07:53:16 »
Haha, I found another awesome zoom bug.  _MoveZoomLensWithPoint does not notify the JPEG engine of the new focal length, causing incorrect distortion fixes to be applied.  For example, if you zoom the lens manually to the longest setting, and take a shot, you'll end up with something like this:



But if you start at the wide end, zoom out using this lua script:

Code: [Select]
set_zoom(get_zoom_steps())
And then take a shot, you see this:



The JPEG engine thinks it needs to fix the barrel distortion that occurs at the wide end of the range, even though we're not actually at the wide end of the range.

The fix is to use _PT_MoveOpticalZoomAt() instead, like the SX30 / SX130 do.

I have a patch submitted on the other thread.  Just thought this was an interesting bug.  :)

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #452 on: 05 / December / 2011, 08:39:57 »
I've got the current Alpha version (ixus220_elph300hs-101d-0.9.9-1455) running.
Really simple question:
Does the current version support focus lock (or autofocus disable) in VIDEO MODE?
If so, how do I do it?

+ a HUGE thank you to everyone who's working on this. CHDK is the main reason I keep buying Canon point and shoots.

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #453 on: 05 / December / 2011, 09:59:36 »
I've got the current Alpha version (ixus220_elph300hs-101d-0.9.9-1455) running.
Really simple question:
Does the current version support focus lock (or autofocus disable) in VIDEO MODE?
If so, how do I do it?

The manual focus in AF lock went in 1457, so that build doesn't have it.  You can use my test build for now (the 1.01c version is compatible with firmware 1.01d).

It works the same way whether recording stills or video: Half-press the shutter and press Left to engage AF lock, and then CHDK's subject distance override functionality is functional.  In a nutshell, enter alt mode (tap the video button), press Up, then use the zoom lever to control focus (Left and Right adjust the sensitivity).  Press Up again to exit.  Focus will remain at the selected point as long as AFL mode is engaged.  You can record stills or video.

If you want to refocus while recording video - there are scripts that do that on other cameras, and *might* work for this one - I haven't tried. 


Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #454 on: 05 / December / 2011, 13:16:11 »
Do you know if exist a DNG profile lens for ixus 220 hs? Thanks a lot.

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #455 on: 05 / December / 2011, 22:14:55 »
So I've been looking into the overdraw issues--specifically, how the CHDK menu gets clobbered by the focus rectangle and other Canon UI elements. 

I tried copying functions from other cameras' implementations of lib.c.  Most of those were disastrous--specifically, those that did stuff like this:
Code: [Select]
_ScreenLock();
_RefreshPhysicalScreen(1);
... prevented Canon UI elements from working at all, from the moment you enter Alt mode.  Pressing the Menu key, for instance, froze the live view, but did not show the menu.  (This code aligns with the wiki page that says _RefreshPhysicalScreen and _ScreenUnlock are the same function; on this camera, they do not appear to be.)

The wiki page also indicates that we may need to implement vid_turn_on_updates() and vid_turn_off_updates() to prevent this from happening.  (Why don't all ports implement these?  ???)

Just adding these implementations:
Code: [Select]
void vid_turn_off_updates()
{
_ScreenLock();
}

void vid_turn_on_updates()
{
_ScreenUnlock();
}

... prevents the overdraw problem, but the screen fails to refresh after exiting the CHDK menu.  That is, the menu is still visible after it's dismissed.

So I tried replacing vid_refresh_bitmap() with the following (keeping it simple):
Code: [Select]
void vid_bitmap_refresh()
{
_RefreshPhysicalScreen(1);
}

And that seems to do the trick.  However, the camera feels less responsive.  The menu feels a little sluggish... maybe I'm imagining that?  I know I'm not imagining the fact that Canon's UI totally freezes not just when the CHDK menu is up, but during all of Alt mode ... that in itself feels a little suboptimal.

I've never used CHDK on another model camera, so I really don't have an idea how smooth it should be.

In any case, I've attached some builds so others can try this out and provide feedback.
« Last Edit: 05 / December / 2011, 22:16:36 by jstanley0 »

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #456 on: 06 / December / 2011, 02:44:02 »
So I've been looking into the overdraw issues--specifically, how the CHDK menu gets clobbered by the focus rectangle and other Canon UI elements. 

This is normal; but annoying - CHDK isn't integrated into the Canon display system.
CHDK attempts to detect if the screen gets completely erased and will redraw the menu; but parts if it can still get erased.

Quote
The wiki page also indicates that we may need to implement vid_turn_on_updates() and vid_turn_off_updates() to prevent this from happening.  (Why don't all ports implement these?  ???)


Thanks for pointing this out - I hadn't come across this before.
A quick check shows that these are only implemented for two cameras - IXUS 120 and IXUS 870.
At least one other camera has commented out these functions with the comment they make things worse.

When I get some time I'll play around with these on my cameras.

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: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #457 on: 06 / December / 2011, 07:59:42 »
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???)


Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #458 on: 06 / December / 2011, 08:18:24 »
A quick check shows that these are only implemented for two cameras - IXUS 120 and IXUS 870.
I think I can safely say that that IXUS120 code is just random guesses put in there when the original port was in a sorry mess and vid_bitmap_refresh() was not working at all.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #459 on: 06 / December / 2011, 12:22:34 »
Do you know if there's a ixus 220 hs DNG profile, to correct RAW distortion and vignetting in camera? Thanks a lot.

 

Related Topics