the sx20 porting thread - page 44 - General Discussion and Assistance - CHDK Forum supplierdeeply

the sx20 porting thread

  • 1286 Replies
Re: the sx20 porting thread
« Reply #430 on: 17 / April / 2010, 05:20:49 »

I only bought my SX20 because of CHDK. I still have an S3 which has enabled me to create some pretty cool shots. 120 minute exposure of the northern lights for example as well as catching water droplets explode.

Don't expect to make your living selling on stock photo sites, there are always pros with 10x more expensive cameras and bags of equipment - as well as a lifetime of experience. Even then they don't make much money or get everything accepted.

Have a look at the features of the histogram and zebra as well as HDR and see what you come out with then.

Re: the sx20 porting thread
« Reply #431 on: 17 / April / 2010, 19:56:03 »

Many thanks to everyone who has contributed to this thread so far, especially for the code. I suggest replacing the DISKBOOT.BIN file on a normal CHDK release (the one with lots of folders in the ZIP) for best effect.

RAW mode
exposure and aperture override
built against latest head revision 885

Display / refresh bug - sometimes the CHDK menu isn't redrawn correctly
High quality override movie mode only records for a few seconds
Built in debug mode so might be slower
RAW images do not have correct file created time
No Zebra

Remember the RAW files produced by CHDK must first be processed. Read the previous posts in this thread or the CHDK wiki on how to do this.

Re: the sx20 porting thread
« Reply #432 on: 17 / April / 2010, 20:51:42 »
Many many thanks, dear Acid and the other guys,
I'm going to test it and wish to have the final version  immediately :)

Re: the sx20 porting thread
« Reply #433 on: 17 / April / 2010, 21:19:17 »
Hello HCDK Group. I have FW 1.02C and would like the features provided with a Customer FW. I have been following along here and noticed that only 1 other person has the same firmware as I. I would like to dump my firmware but have no idea how to i read,4188.0.html but still cant seem to figure it out. Please let me know what i need to do or how i can contribute. Thank you.
Canon PowerShot SX20 IS ~FW-1.02C~

Re: the sx20 porting thread
« Reply #434 on: 18 / April / 2010, 01:23:16 »

YAY! Awesome.

Re: the sx20 porting thread
« Reply #435 on: 18 / April / 2010, 07:27:48 »
Who-hoo, been waiting a long time for this!  Thanks for the work, will try it.

Re: the sx20 porting thread
« Reply #436 on: 18 / April / 2010, 08:01:52 »
« Last Edit: 18 / April / 2010, 08:11:13 by hellgate »

Re: the sx20 porting thread
« Reply #437 on: 18 / April / 2010, 09:37:30 »
Read the wiki. Especially

The SX10 firmware package can be adapted by just changed the file I provided in the zip.

Re: the sx20 porting thread
« Reply #438 on: 18 / April / 2010, 11:03:19 »
Sorry its my fault i have a 1.02C ...  :-[ ::)

Re: the sx20 porting thread
« Reply #439 on: 18 / April / 2010, 13:56:15 »
OK I've been doing a bit more work diagnosing some GUI glitches. Luckily I am able to compare the CHDK I'm building it to a fully supported port.

Basically the values for screen res in lib.c are wrong. At least for the SX20 102b. It might be worth trying these on the 100f as well, i believe it will fix the current hack put in there to resize the screen.

I used the SX200 as reference as it has the same number of pixels and also requires scaling. Using all the magic numbers in the SX200 lib.c (ie vid_get_bitmap_screen_width etc) and the aspect correction found in camera.h I got the GUI resizing correctly without changing gui.c. AFAIK apart from some changes in the propset file merging with the latest trunk should be fairly easy now.

I've also found that the logo isn't displaying correctly. Should be white instead of grey. I've fixed this by changing the palette. Testers need to find places where the colours are defiantly wrong so I can fix it.  

I'm still having problems with screen refreshing and lua scripts output not being displayed.

Maintainers, a number of propset values need to be changed for the SX20. Do we need to create another propset file to be compatible with the trunk revision or can we #define?

For those that are interested here is the new camera.h

Code: [Select]
   #define CAM_PROPSET                 3
    #define CAM_DRYOS                   1
    #define CAM_DRYOS_2_3_R39           1

    #define CAM_RAW_ROWPIX              4080
    #define CAM_RAW_ROWS                3048
    #define CAM_SWIVEL_SCREEN           1
    #define CAM_HAS_VIDEO_BUTTON       1
    #define CAM_VIDEO_QUALITY_ONLY          1  
    #define CAM_BRACKETING              1
    #define CAM_MULTIPART               1
    #define CAM_HAS_JOGDIAL             1
    #undef  CAM_USE_ZOOM_FOR_MF
    #undef  CAM_UNCACHED_BIT  // shut up compiler
    #define CAM_UNCACHED_BIT    0x40000000

    #define DNG_SUPPORT                 1
    // pattern
    #define cam_CFAPattern 0x02010100 // Red  Green  Green  Blue
    // color

    #define CAM_COLORMATRIX1                               \
      827547, 1000000, -290458, 1000000, -126086, 1000000, \
     -12829,  1000000, 530507,  1000000, 50537,   1000000, \
      5181,   1000000, 48183,   1000000, 245014,  1000000

    #define cam_CalibrationIlluminant1 1 // Daylight
    // cropping
    #define CAM_JPEG_WIDTH  4000
    #define CAM_JPEG_HEIGHT 3000
    #define CAM_ACTIVE_AREA_X1 24
    #define CAM_ACTIVE_AREA_Y1 12
    #define CAM_ACTIVE_AREA_X2 4080-48
    #define CAM_ACTIVE_AREA_Y2 3048-24
    // camera name
    #define PARAM_CAMERA_NAME 4 // parameter number for GetParameterData
    #undef  CAM_WHITE_LEVEL
    #undef  CAM_BLACK_LEVEL
    #define CAM_SENSOR_BITS_PER_PIXEL   12
    #define CAM_WHITE_LEVEL             ((1<<CAM_SENSOR_BITS_PER_PIXEL)-1)
    #define CAM_BLACK_LEVEL             127

    #define CAM_EXT_TV_RANGE            1
    #define CAM_QUALITY_OVERRIDE        1

    // copied from the SX200
    #define CAM_USES_ASPECT_CORRECTION  1  //camera uses the modified graphics primitives to map screens an viewports to buffers more sized
    #define CAM_USES_ASPECT_YCORRECTION  0  //only uses mappings on x coordinate

    #define ASPECT_XCORRECTION(x)  ( ( ((x)<<3) + (x) )  >>2 )   //correction x*screen_buffer_width/screen_width = x*720/320 = x*9/4 = (x<<3 + x)>>2

    #define ASPECT_GRID_XCORRECTION(x)  ( ((x)<<3)/9  )  //grids are designed on a 360x240 basis and screen is 320x240, we need x*320/360=x*8/9
    #define ASPECT_GRID_YCORRECTION(y)  ( (y) )       //y correction for grids  made on a 360x240 As the buffer is 720x240 we have no correction here.
    #define ASPECT_VIEWPORT_XCORRECTION(x) ASPECT_GRID_XCORRECTION(x) //viewport is 360x240 and screen 320x240, we need x*320/360=x*8/9, equal than grids, used by edgeoverlay
    #define ASPECT_VIEWPORT_YCORRECTION(y) ( (y) )
    //games mappings
    #define GAMES_SCREEN_HEIGHT 240
    // 720/360=2 same aspect than grids and viewport but another approach: there is a lot of corrections to do in game's code, and we decide to paint directly on display buffer wirh another resolution
    // used by gui.c that configures the draw environment (trhough new draw_gui function) depending on gui_mode: we have then 360x240 for games (but deformed output:circles are not circles) and 320x240 for
    // other modes in perfect aspect ratio 4/3: slightly better visualization: file menus more readable, ...
    #define ASPECT_GAMES_XCORRECTION(x)   ( ((x)<<1) )  
    #define ASPECT_GAMES_YCORRECTION(y)   ( (y) )  //none

    #define CAM_BITMAP_PALETTE    3

« Last Edit: 18 / April / 2010, 17:54:11 by acid2000 »


Related Topics