ELPH300HS aka IXUS220HS - Porting Thread - page 32 - DryOS Development - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 ... 27 28 29 30 31 [32] 33 34 35 36 37 ... 90   Go Down

ELPH300HS aka IXUS220HS - Porting Thread

  • 899 Replies
  • 397803 Views
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #310 on: 27 / November / 2011, 12:40:56 »
Advertisements
Quote from: waterwingz on 27 / November / 2011, 12:19:31
... people have to just figure things out for themselves (sometimes the hard way the first time).

Sometimes the hard way is the more interesting way.  :)
Logged
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #311 on: 27 / November / 2011, 12:58:46 »
Quote from: waterwingz on 26 / November / 2011, 13:08:12
Quote from: tommi2water on 26 / November / 2011, 12:54:47
This file I also already sent to Developers with a request for integration as Alpha version into the CHDK subversion repository (http://chdk.setepontos.com/index.php?topic=650.msg76587#msg76587).
Its up to reyalp & philmoz, but it might be a little premature to add this to the autobuild - even as an Alpha ?  I'll happily make a SVN diff file for you but why not wait until you have movie_rec.c and capt_seq.c running first.  At the rate you are going,  I'd expect you will have that done this weekend !

Guys, I would like to send once again our current version of ixus220/elph300 port to the CHDK developers for integration.

Many features are working and as waterwingz already predicted we were able to adapt movie_rec.c and capt_seq.c as well. :) Okay, video recording is currently not working for 101a and 101c firmwares, but that could be fixed later.

Jstanley, waterwingz, Phil, what do you think?

I would at least wait until Jstanley has created a new movie_rec.c for 101a firmware. Then we can commit our stuff together in one package to the developers.  :)

« Last Edit: 27 / November / 2011, 13:49:14 by tommi2water »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #312 on: 27 / November / 2011, 14:22:57 »
Quote from: tommi2water on 27 / November / 2011, 08:29:32
After I changed an address from 0x413591F0 to 0x413391A0 in lib.c:
Code: [Select]
char *hook_raw_image_addr()
{

if (*((int*)0x3F04) != 0)
return (char*) 0x46000000;
else
return (char*) 0x413391A0; // before it was 0x413591F0;

}
I am able to shoot DNG pictures.  :)

But:
After restart the first DNG picture fails. That is reproducable for me. Second, third, fourth picture ... are fine.
Next restart first picture fails again.

What could be the reason for this? An wrong initialized value which gets new correct value after first shoot?


If you copy an existing port as a reference then you have to assume that every value in the platform/CAMERA files is going to be wrong and needs to be checked and fixed.

In this case the RAW buffer addresses looks OK; but the location of the active buffer is wrong.
From looking at the firmware is should probably be 0x2E94 not 0x3F04 (see sub_FF884C18 in 1.00c firmware).

Make sure you make the same changes in hook_alt_raw_image_addr

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 tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #313 on: 27 / November / 2011, 14:32:53 »
Thanks for the hint, but I cannot follow you.

How do you get to value 0x2E94 ?

At mentioned firmware location I only see 0x2E88. From where do you take the difference of 0xC?
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #314 on: 27 / November / 2011, 14:39:06 »
Quote from: tommi2water on 27 / November / 2011, 14:32:53
Thanks for the hint, but I cannot follow you.

How do you get to value 0x2E94 ?

At mentioned firmware location I only see 0x2E88. From where do you take the difference of 0xC?


Experience.
0x2E88 is loaded into R6. Further down in the function you will see it changes the value at R6 + 0xC from 0 to 1 and vice versa, then uses this to load values from a table at FFBA311C. This table contains your raw buffer addresses (among other things).

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 waterwingz

  • ******
  • 12138
    • Waterwingz
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #315 on: 27 / November / 2011, 14:47:34 »
long and painful experience if I recall that code correctly ...
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #316 on: 27 / November / 2011, 14:52:57 »
Quote from: philmoz on 27 / November / 2011, 14:39:06
Experience.

I only saw 0x18 two times and one time 0x04 and then stopped for further looking. I should have been looking for 0x0c, but that's what I'm missing: Experience.   8)

But now I can play with RAW images. Thanks, it's working fine now.

Why does nobody from 101a and 101c versions complain about such RAW issues? Because the values are the same (at least in the lib.c files). Ok, maybe they already fixed it on their own.

Update:
I found the same values in 101a and 101c firmware.

Please find attached new binaries for 101a and 101c.

Changes in these binaries only for shooting RAW images.
Please test if shooting RAW images is still working fine. From firmware point of view it should be fine.

Don't know if it is necessary but to free some disk space I will remove binaries from older posts because they contain less or no functionality.

--
Update: removed binary because no or wrong functionality, newer version available in later posts
« Last Edit: 28 / November / 2011, 15:29:39 by tommi2water »
Logged
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #317 on: 27 / November / 2011, 15:11:48 »
Binary for 100c and current source code version (for 100c, 101a, 101c firmware).

--
Update: removed binary because no or wrong functionality, newer version available in later posts
« Last Edit: 28 / November / 2011, 15:30:04 by tommi2water »
Logged
*

Offline Fux

  • *
  • 1
  • IXUS 220 HS FW: 1.00c
Bug Report: HDR Script
« Reply #318 on: 27 / November / 2011, 16:05:43 »
I just registered to give also feedback.
I am using your latest version for firmware 1.00c (ixus220_elph300hs-100c-0.9.9-r9999_assembla_assembla.zip).

At first a note: i am a starter user of chdk. So i am knowing chdk not in detail yet.

I am very interested in the HDR function: i selected the script from /CHDK/SCRIPTS/4PACK/LUA/HDR.LUA
and activated it. After pressing the release knob one photo is shot and then the camera doesn't react any more. After a while the lcd-monitor is shut off (lens still outside). Then i have to switch off the camera for working again.
Logged
*

Offline jstanley0

  • **
  • 71
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #319 on: 27 / November / 2011, 16:36:06 »
Quote from: tommi2water on 27 / November / 2011, 14:52:57
Why does nobody from 101a and 101c versions complain about such RAW issues? Because the values are the same (at least in the lib.c files). Ok, maybe they already fixed it on their own.

Well, there was my last image in this message.  I thought this was a shutter override problem, but it might be a bad RAW buffer.  Actually... it looks too "analog" to be a bad RAW buffer; I think it's more likely that the shutter never opened at all, and dcraw (the RAW conversion software I used) brightened the sensor noise into that thing*.

So I guess I can't explain why I never saw a "RAW" photo comprised of random memory contents.

*It's worth noting that dcraw automatically scales the image brightness; if you shoot the same scene at EV 0 and EV -1, you'll get nearly identical looking output files (except the one shot at EV -1 will have more shadow noise and less highlight clipping).  The Orion shot in my message looks bright because dcraw scaled the RAW pixel values up to something "visible" before truncating to 8 bits for JPEG.  In-camera, on the other hand, the fixed tone curve applied by the default firmware stuffed the majority of pixels into the bottom handful buckets in the histogram, effectively throwing out most of the faint signal.
Logged
Pages: 1 ... 27 28 29 30 31 [32] 33 34 35 36 37 ... 90   Go Up
« previous next »
 

Related Topics