ELPH300HS aka IXUS220HS - Porting Thread - page 69 - DryOS Development - CHDK Forum  
« previous next »
Pages: 1 ... 64 65 66 67 68 [69] 70 71 72 73 74 ... 90   Go Down

ELPH300HS aka IXUS220HS - Porting Thread

  • 899 Replies
  • 399400 Views
*

Offline frojnd

  • *
  • 45
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #680 on: 27 / February / 2012, 18:34:03 »
Advertisements
Hi there :) Again thanks to all the people who makes this camera more and more great as it is :) Thank you all!

I just found after plugging the usb cable into camera with lock mode on error:

"A camera error was detected. Will shut down automatically. Restart camera. Eror E41"

I saw a few posts above user c10ud found out what cause this and he apperantly solve it? My question is: is this issue solved for 100c version?

My current CHDK version: 1.00-1651 firmware 100c. I saw on autobuild: ixus220_elph300hs-100c-1.0.0-1699_ALPHA.zip does this version solve this issue?

The reason I'm asking this is because I'd like to try ptpcam for this camera.

Thanx!
Logged
*

Offline danistuta

  • *
  • 37
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #681 on: 02 / March / 2012, 07:17:50 »
With chhdk, possible put screen off during video recording? Thanks.
Logged
*

Offline reyalp

  • ******
  • 14082
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #682 on: 02 / March / 2012, 22:41:22 »
Quote from: danistuta on 02 / March / 2012, 07:17:50
With chhdk, possible put screen off during video recording? Thanks.
You may be able to turn off the backlight with set_backlight in script. You can probably also disable it by plugging in the video out cable.

If you are looking to save battery, neither of these will help much. If you want to avoid stray light from the display, it may do what you want.
Logged
Don't forget what the H stands for.
*

Offline danistuta

  • *
  • 37
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #683 on: 03 / March / 2012, 08:09:46 »
I'd like to put off my display to save battery, any way to do this? Thanks.
Logged
*

Offline cppasm

  • **
  • 92
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #684 on: 03 / March / 2012, 10:00:58 »
Quote from: philmoz on 26 / February / 2012, 04:21:07
I've added the fix to the SVN repository. It should be in the autobuild version in a little while.
Come on guys, pay a little more attention when commiting sources - they getting worse and worse with a time... :(
Badpixel patching in a raw.c is wrong after this update, and even before this update it was broken for a long time, reported but noone wants to fix it - should be patched too.

248   void patch_bad_pixel(unsigned int x,unsigned  int y) {
249       int sum=0;
250       int nzero=0;
251       int i,j;
252       int val;
253       if ((x>=2) && (x<camera_sensor.raw_rowpix-2) && (y>=2) && (y<camera_sensor.raw_rows-2)) {
254           if ((conf.bad_pixel_removal==1) || (conf.save_raw && conf.dng_raw)) {  // interpolation or DNG saving
255               for (i=-2; i<=2; i+=2)
256                   for (j=-2; j<=2; j+=2)
257                       if ((i!=0) && (j!=0)) {
// Wrong!! Should be OR, not AND - just draw a CFA pattern and check out
257                       if ((i!=0) || (j!=0)) {
258                           val=get_raw_pixel(x+i, y+j);
259                           if (val) {sum+=val; nzero++;}
// Wrong!! Should check for DNG_BADPIXEL_VALUE_LIMIT, not for zero. And possibly rename nzero too.
259                           if (val>DNG_BADPIXEL_VALUE_LIMIT) {sum+=val; nzero++;}
260                       }
261                   if (nzero) set_raw_pixel(x,y,sum/nzero);
262           } else if (conf.bad_pixel_removal==2)  // or this makes RAW converter (internal/external)
263               set_raw_pixel(x,y,0);
264       }
265   }

And the whole process is not optimal for the badpixels in a GREEN channel.
Draw CFA pattern to checkout - there are  GREEN pixels closer to broken one than pixels that are used for patching (diagonal pixels).
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #685 on: 03 / March / 2012, 15:59:33 »
Quote from: cppasm on 03 / March / 2012, 10:00:58
Come on guys, pay a little more attention when commiting sources - they getting worse and worse with a time... :(

Statements like this will only serve to annoy the people who actively contribute to CHDK, and may get you banned. Try being more polite and less insulting in future.

Quote
Badpixel patching in a raw.c is wrong after this update, and even before this update it was broken for a long time, reported but noone wants to fix it - should be patched too.

Was a patch submitted to the appropriate topic? I don't recall seeing one.
Occasionally patches will get missed, so just post a polite reminder.

Quote
248   void patch_bad_pixel(unsigned int x,unsigned  int y) {
249       int sum=0;
250       int nzero=0;
251       int i,j;
252       int val;
253       if ((x>=2) && (x<camera_sensor.raw_rowpix-2) && (y>=2) && (y<camera_sensor.raw_rows-2)) {
254           if ((conf.bad_pixel_removal==1) || (conf.save_raw && conf.dng_raw)) {  // interpolation or DNG saving
255               for (i=-2; i<=2; i+=2)
256                   for (j=-2; j<=2; j+=2)
257                       if ((i!=0) && (j!=0)) {
// Wrong!! Should be OR, not AND - just draw a CFA pattern and check out
257                       if ((i!=0) || (j!=0)) {
258                           val=get_raw_pixel(x+i, y+j);
259                           if (val) {sum+=val; nzero++;}
// Wrong!! Should check for DNG_BADPIXEL_VALUE_LIMIT, not for zero. And possibly rename nzero too.
259                           if (val>DNG_BADPIXEL_VALUE_LIMIT) {sum+=val; nzero++;}
260                       }
261                   if (nzero) set_raw_pixel(x,y,sum/nzero);
262           } else if (conf.bad_pixel_removal==2)  // or this makes RAW converter (internal/external)
263               set_raw_pixel(x,y,0);
264       }
265   }

And the whole process is not optimal for the badpixels in a GREEN channel.
Draw CFA pattern to checkout - there are  GREEN pixels closer to broken one than pixels that are used for patching (diagonal pixels).

While this may not be the way you would do it, it works.
I did not write the original; but I understand the logic behind it and don't see an issue.

The code samples the four pixels of the same color diagonally at offsets -2 and +2 from the original.
For red and blue these are the nearest pixels diagonally.
Your change (line 257) forces it to also sample the pixels vertically and horizontally but this would be slower (averaging 8 pixels instead of 4) and often the bad pixels are clustered in horizontal or vertical lines.
Sampling the diagonals is a good compromise.

For the green channel there are closer pixels at offsets of -1 and +1 from the original. The problem is that this would significantly increase the code complexity (handling green differently from red and blue), and also requires different code paths for the two CFA patterns. These closer pixels are also more likely to also be bad, so again the existing code is a reasonable compromise.

The change on line 259 to use DNG_BADPIXEL_VALUE_LIMIT is technically correct; but in practice probably won't make any difference to the result (the majority of sampled pixels are not bad).

Phil.
Logged
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 cppasm

  • **
  • 92
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #686 on: 04 / March / 2012, 07:40:32 »
Quote from: philmoz on 03 / March / 2012, 15:59:33
Statements like this will only serve to annoy the people who actively contribute to CHDK, and may get you banned. Try being more polite and less insulting in future.
Ok, sorry.
I didn't want to offend anyone, maybe I need to be more restrained in the future.
Sorry once more.
Logged
*

Offline jstanley0

  • **
  • 71
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #687 on: 04 / March / 2012, 09:26:20 »
Quote from: ray on 25 / February / 2012, 08:42:41
first of all thank you for the great work you are doing. i`m using an older ixus with chdk for years now and it works fabulous, especially the autoiso-function. i recommended the elph300hs to a friend of mine and because his son can`t stand still for a 1/60th of a second i installed your alpha-version of chdk but enabling the auto-iso function will lead to a systemcrash (vers. 101a-1.0.0-1659-full_ALPHA).

I've got the same camera and I can't reproduce the crash (using build 1699).  Can you provide a bit more detail on how you reproduce this--what mode the camera is in beforehand, and what sequence of menu items you go through to get there? 

It would also be helpful if you could attach a crash log.  In the CHDK menu, go to Miscellaneous Stuff -> Debug parameters -> Save ROM crash log, then grab the ROMLOG.LOG file from your SD card and attach it to a post here.

(Actually, enabling the custom auto ISO function does not seem to do anything at all for me; auto ISO does not respect the boundaries I put in - but I admit I haven't seen a use for this; the "kids and pets" scene mode may be all your friend really needs here...)
Logged
*

Offline mojo43

  • *
  • 24
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #688 on: 05 / March / 2012, 00:00:53 »
Thanks so much for all of the hard work on this CHDK.... I am wondering if there is a way to shut off auto exposure on video recording? I would like to start a video recording and not have it fluctuating with shutter, iso and aperture changes if possible?

(AE Lock)

Thanks in advance...
« Last Edit: 05 / March / 2012, 01:39:17 by mojo43 »
Logged
*

Offline imtheguy

  • *
  • 25
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #689 on: 05 / March / 2012, 00:18:41 »
First, many thanks to the those that spend the time making toys like this to keep me entertained in retirement.  Thank you again for the time spent on this forum helping folks solve their issues.  My small one is only on the Elph300, now using 101g-1699.  Under no circumstances can I turn off DFS (Dark Frame Subtraction) like I can with my A560, even with all settings identical.  My question is if DFS is a known issue with the Elph300HS or does anybody else have it turned off with FW 1.01g in which case its likely my user error?  I love the camera for its 24mm width but can't shoot at night yet.

Because a search did not bring it up I tend to think its me error and it works different than the A560 CHDK.

Thanks all!
Logged
Pages: 1 ... 64 65 66 67 68 [69] 70 71 72 73 74 ... 90   Go Up
« previous next »
 

Related Topics