IXUS 1000 HS Porting Thread - page 22 - DryOS Development - CHDK Forum

IXUS 1000 HS Porting Thread

  • 440 Replies
  • 167538 Views
*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: IXUS 1000 HS Porting Thread
« Reply #210 on: 26 / December / 2010, 13:22:32 »
Advertisements
I'm trying difrent address, also checkink out with the memory browser (inside the debug menu),

but no clue for now

You can move through the memory to find stuff using it,
I had to change gui_debug.c to allow bigger jumps when browsing, due to the lack of Display key in ixus1000 I change this to use the  up key for that purpose:
Code: [Select]
void gui_debug_kbd_process() {
    switch (kbd_get_autoclicked_key()) {
    case KEY_DOWN:
        //Testig ixus1000
        switch (step) {
            case 0x00000004: step = 0x00000010; break;
            case 0x10000000: step = 0x00000004; break;
            default: step<<=4; break;
        }

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: IXUS 1000 HS Porting Thread
« Reply #211 on: 27 / December / 2010, 06:35:09 »
Ok, I find the other RAW buffer,

In 100F:
Is one of the addreses in a table starting at FFB8ECF4  ,   in 100D: at FFB8ECF0

Its very easy to find looking at the definition of
aSsimgprocbuf_c DCB "SsImgProcBuf.c",0

and then the next unk_---- points to the table where all the buffers are

So in 100F the two raw buffers are:
First:  0x46000000
Scnd: 0x4132CD20

I still was unable to fix the color issue with the raws

This is the code for the 2 firmwares of the ixus100, Bernr can you test it?
Code: [Select]
char *hook_raw_image_addr()   //ASM1989  DONE FOR IXUS 1000
{
if (*((int*)0x34D0) != 0)    //  34C4 + C  ->   FF885154  ->FF885180   (ixus 1000)
return (char*)(0x46000000); // at FFB8ECF4  pointed at aSsimgprocbuf_c DCB "SsImgProcBuf.c",0
else
return (char*) 0x4132CD20; // found at[search CRAW BUF]
}
« Last Edit: 27 / December / 2010, 07:06:19 by asm1989 »

Re: IXUS 1000 HS Porting Thread
« Reply #212 on: 27 / December / 2010, 13:37:35 »
thanks, now the buffer addr is correct.

I do testhoot at ISO 125 and 0.5 sec exposure time.
I see on first raw when CCD is cold, (26 ) there are much less bad pixel.
when i do 3 shoots CCD get (39 ) and much more bad pixel are see.

So i think only a badpixel file with fixed values for bad pixel is not enough for this camera.
seem the CMOS sensor have lots of bad pixels and this depend on temperature too.

I think there need always a dark frame create for this camera and this should subtract from RAW.
this camera support 2 buffers, so is it possible to do a dark frame shoot, that is in 2. buffer ?

Ixus 1000 HS

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: IXUS 1000 HS Porting Thread
« Reply #213 on: 27 / December / 2010, 14:25:30 »
But you still get a pink color in the raw files ?


*

Offline reyalp

  • ******
  • 14082
Re: IXUS 1000 HS Porting Thread
« Reply #214 on: 27 / December / 2010, 16:08:49 »
I do testhoot at ISO 125 and 0.5 sec exposure time.
I see on first raw when CCD is cold, (26 ) there are much less bad pixel.
when i do 3 shoots CCD get (39 ) and much more bad pixel are see.
It has been previously noticed that other cameras return different numbers of bad pixels depending on exposure setting, doing it based on temperature as well isn't a surprise.

It is safe to use the bad pixel file form the worst case, because CHDK only patches the pixel if it the value is zero (already marked by canon OS). The only cost is a bit of wasted time and memory. The only reason we need a badpixel list at all is because scanning the entire raw buffer would be too slow, otherwise we could just look for zeros.

Quote
I think there need always a dark frame create for this camera and this should subtract from RAW.
this camera support 2 buffers, so is it possible to do a dark frame shoot, that is in 2. buffer ?
Dark frame is already a standard CHDK feature (maybe not implemented on this port yet), you could force dark frame always if you wanted. Obviously this applies to both raw and jpeg, because jpeg is made from the raw.

As an aside, I strongly suggest concentrating on getting the port fully working with standard CHDK functionality so it can be added to the trunk before adding significant new features.
Don't forget what the H stands for.

Re: IXUS 1000 HS Porting Thread
« Reply #215 on: 28 / December / 2010, 04:45:00 »
@asm1989
>But you still get a pink color in the raw files ?

yes color is still wrong.

@reyalp
>It has been previously noticed that other cameras return different numbers of bad pixels depending on >exposure setting, doing it based on temperature as well isn't a surprise.

thanks for info.

I see in chdk wiki about badpixel

http://chdk.wikia.com/wiki/Badpixel_removal

but the file to examine badpixel.bin can not download, do you know other place ?

I think now the badpixel script work ok in IX 1000, but the camera does never give same badpixel result for both shoots and so there is no badpixel file create with that lua code.

I find out, when i switch bad pixel removal in raw menu, from default(auto) to on, then the size of the bad_tmp file get lots smaller.

when its cold  (ccd 26) 33528 bytes. little hotter sensor show (ccd 35) 34556 bytes

now when dark frame removal is set to auto i try out when CCD temparatur show 42.I get a bad_tmp.bin file of size 486860 bytes with default RAW settings.

thats very large.

normaly for the long exposure time of badpixel script, dark frame subtraction in auto should work.Or i am wrong ?
maybe there is on IX 1000 Port miss the firmware value if dark frame subtraction should do or not in automatic ?

The IX 1000 seem have a lot bad pixel
and i think it never happen that there are 2 shoots with same badpixel on IX 1000.
so only bad_tmp file can use.

@asm1989

how big is your bapixel file ?


« Last Edit: 28 / December / 2010, 04:47:16 by Bernd R »
Ixus 1000 HS

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: IXUS 1000 HS Porting Thread
« Reply #216 on: 28 / December / 2010, 04:59:21 »
@bernrn: 24,5KB

And this is the right area to get a raw file without black areas at any side

Code: [Select]
   #define CAM_ACTIVE_AREA_X1 42
#define CAM_ACTIVE_AREA_Y1 24
#define CAM_ACTIVE_AREA_X2 3816-126
#define CAM_ACTIVE_AREA_Y2 2784-24

@realyp or any gurudev
I'm still working out why the green color channel is allways totaly black with the RGGB pattern
And I think this is the one since I find " ADR     R0, aObRG1G2BLdLdLdLd ; "\n  OB : (R, G1, G2, B) = (%ld, %ld, %ld"..."

I try calling  capt_seq_hook_raw_here from several places inside captseq and the result is the same.

And I think this is the correct pattern, I try to build new patterns in raw.c, and I get a green channel but the overal picture turns to blue or other color.

Do you have any clue about this?

« Last Edit: 28 / December / 2010, 05:12:50 by asm1989 »

*

Offline fe50

  • ******
  • 3147
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: IXUS 1000 HS Porting Thread
« Reply #217 on: 28 / December / 2010, 05:48:47 »
but the file to examine badpixel.bin can not download, do you know other place ?
The download links are updated now... most CHDK-related tools & apps can be found at http://www.box.net/chdk

Quote
I think now the badpixel script work ok in IX 1000, but the camera does never give same badpixel result for both shoots and so there is no badpixel file create with that lua code.
IMO it doesnt make any sense to do badpixel stuff before RAW saving is ok - you won't get suitable results from a broken RAW image ;)
Darkframe subtraction shouldn't change the amount of Canon-defined bad pixels (the ones for DNG creation, badpixel.bin).


Re: IXUS 1000 HS Porting Thread
« Reply #218 on: 28 / December / 2010, 07:56:30 »
I test what happen when change the buffer addr by add 1 and 2.but there come only more wrong images

@asm1989

here i have new kybd.c for platform dir.now the wheel work in correct direction.

http://www.zshare.net/download/84463583cf9dcf78/

I get the idea, when find in the firmware ROM the code that deactivate Firmware keys when USB is plug in, can help to get Keys on IX 1000 correct work, when add the keyboard check code in that place.

USB mask is correct and it use physw_status[2]

#define USB_MASK (0x80000)

Do you think this is possible ?

because when plug in USB cable in Camera, then firmware keys do not work, but chdk can read the keys and work ok.

so it work press key for alt mode, then plug in USB cable and Canon firmware do no key processing.

Later when you want switch to Canon Firmware mode, you can pres key for alt mode to switch it off.
now remove the USB cable and Canon Firmware keys work then ok too

@fe50
>The download links are updated now... most CHDK-related tools & apps can be found at >http://www.box.net/chdk

thanks for the link, i see this tool allow the load of RAW *cr2 files.so i change prefix to cr2 and switch of DNG, and the IX1000 create a cr2 file and i try to load that in windows badpixel pro.

http://www.box.net/chdk#chdk/1/55270403/580767258/1

but when start program it come a error

File not found:   E:\chdk\badpixel\readme.txt

this file is not in the archive.I find nothing in forum when i type in badpixel pro

It is still usable.but when i switch to supportet cameras, there is no camera show.the cameras.ini file i have in archive is default and contain lots of camera.But nothing is list.

And when i try to load the cr2 file of IX1000 come error bad file format unknown.file size (15.936.616) same as crw and smaller as dng size (15.974.016)

Does this work on other Camera ?
« Last Edit: 28 / December / 2010, 08:00:28 by Bernd R »
Ixus 1000 HS

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: IXUS 1000 HS Porting Thread
« Reply #219 on: 28 / December / 2010, 08:43:46 »
@Bernd R
keyb works better with new file, did you chech other new cams keyb, like sx30, s95, ixus130 and so on?

about the color you need to work with the file raw.c and  add a new code for this:

Code: [Select]
#if cam_CFAPattern==0x02010100    // Red  Green  Green  Blue
    r=gamma[get_raw_pixel((x/2)*2,(y/2)*2)>>(CAM_SENSOR_BITS_PER_PIXEL-8)]; // red pixel
    g=gamma[6*(get_raw_pixel((x/2)*2+1,(y/2)*2)>>(CAM_SENSOR_BITS_PER_PIXEL-8))/10]; // green pixel
    b=gamma[get_raw_pixel((x/2)*2+1,(y/2)*2+1)>>(CAM_SENSOR_BITS_PER_PIXEL-8)]; //blue pixel
#elif cam_CFAPattern==0x01000201 // Green  Blue  Red  Green
    r=gamma[get_raw_pixel((x/2)*2,(y/2)*2+1)>>(CAM_SENSOR_BITS_PER_PIXEL-8)]; // red pixel
    g=gamma[6*(get_raw_pixel((x/2)*2,(y/2)*2)>>(CAM_SENSOR_BITS_PER_PIXEL-8))/10]; // green pixel
    b=gamma[get_raw_pixel((x/2)*2+1,(y/2)*2)>>(CAM_SENSOR_BITS_PER_PIXEL-8)]; //blue pixel

and try changing some numbers for r, g an b, like this:

Code: [Select]
#elif cam_CFAPattern==0x02010001    // Red  Green  Blue Green  ?? Guessing maybe wrong
    r=gamma[get_raw_pixel((x/2)*2,(y/2)*2+1)>>(CAM_SENSOR_BITS_PER_PIXEL-8)]; // red pixel
    g=gamma[6*(get_raw_pixel((x/2)*2+1,(y/2)*2+1)>>(CAM_SENSOR_BITS_PER_PIXEL-8))/10]; // green pixel
    b=gamma[get_raw_pixel((x/2)*2+1,(y/2)*2+1)>>(CAM_SENSOR_BITS_PER_PIXEL-8)]; //blue pixel

and then change it at camera.h

#define cam_CFAPattern 0x02010001    // Red  Green  Blue Green  -> MY NEW ONE


or maybe what is wrong for this cam is the function: get_raw_pixel

Code: [Select]
unsigned char* addr=(unsigned char*)get_raw_image_addr()+y*RAW_ROWLEN+(x/4)*6;
 switch (x%4) {
  case 0: return ((unsigned short)(addr[1]) << 4) | (addr[0] >> 4);
  case 1: return ((unsigned short)(addr[0] & 0x0F) << 8) | (addr[3]);
  case 2: return ((unsigned short)(addr[2]) << 4) | (addr[5] >> 4);
  case 3: return ((unsigned short)(addr[5] & 0x0F) << 8) | (addr[4]);
 }

You have more info here:
http://chdk.setepontos.com/index.php?topic=4744.0
« Last Edit: 28 / December / 2010, 08:59:15 by asm1989 »

 

Related Topics