You can post your source here, either as a patch, or just the loader and platform directories if you didn't need to change anything outside that.
In case you haven't already found it https://chdk.fandom.com/wiki/Testing has some recommendations for testing.
static long *nrflag = (long*)(0xa0e0)
#define CAM_VIDEO_QUALITY_ONLY 1
#define NUM_FL 101 // 101 zoom steps#define NUM_DATA 2 // 2 words each entry, FL in MM*1000, 100extern int focus_len_table[NUM_FL*NUM_DATA];// Conversion factor lens FL --> 35mm equiv// lens 35mm CF// ---- ---- --// 4.3 24 (24/4.3) * 43 = 240 (min FL)// 43 240 (240/43) * 43 = 240 (max FL)#define CF_EFL 240#define CF_EFL_DIV 43
Thanks. Added in trunk r5937 with minor cosmetic changes. Autobuild disabled for the moment, but I think it can be turned on once you verify the trunk source works on your cam and the nrflag issue is addressed.Overall, this looks very good for a first port. Please don't take the long post that follows as a flame, I'm just trying to flag potential issues while there's someone with camera to address them:
The patch was missing the loader directory. It's pretty much all boilerplate at this point, so I just copied the ixus145 files
In platform lib.c, vid_get_viewport_live_fb has a TODO on it, and based on other cams, the video case is probably incorrect. I'd suggest using a build with OPT_VIEWPORT_DEBUG=1 and turning on display misc values to determine the number of buffers used, both when recording video and not.
vid_get_bitmap_active_palette should check for null in the fallback case too (like the current elph130 code), and load_chdk_palette should not modify the palette on null. (These are wrong in the ixus145 port too)
In platform_camera.h:TODO on CAM_CIRCLE_OF_CONFUSION. 5 matches the result from http://www.dofmaster.com/digital_coc.htmlTODO on active area. You can determine the active area using the procedure on https://app.assembla.com/spaces/chdkptp/wiki/DNG_ProcessingTODO on jpeg size: It matches the Canon specs, should be fine.
All the CAM_SD_OVER* are 1. Are these verified? If not, you can check using mftest as described on the testing page.
Finally, I used the ixus 157 dump from our archive https://drive.google.com/drive/u/0/folders/0B08pqRtyrObjTy11Y003Sk1lYTQ (ixus157 dump + discussion https://chdk.setepontos.com/index.php?topic=12543.msg124442#msg124442) to build, because the 155 one we have is incomplete. This is verified compatible based on stubs and firmware CRC values, and can be mentioned in the notes + wiki page.
The lens is same as Ix255
Checked and fixed this. Interestingly I had to fix the active_viewport_buffer address to get the debug info working first and I think the reference I used (ixus145) also has a wrong address for it.
Ok, updated from elph130.
Running mftest as described in the testing page says everything passes, but I'm not totally sure what everything means here.
Framerate I'm getting in chdkptp-gui live view is quite poor, I'm not sure if that's typical or not though.
Since you have chdkptp live view running, you can easily check whether this is correct by comparing the live view to the camera screen. If it's cut off, it's wrong. The height can also vary when video is recording, and in some special modes like fisheye effect.
Then, if you use set_focus with different values, like =set_focus(100) and =set_focus(10000), you should see the focus change immediately in the live view. Same for set_aflock. Be sure to set_mf(0) before using set_aflock(1).You can also use shoot with various -sd values and check the difference.
What kind of frame rate, and what platform are your running on? I wouldn't generally expect more than 10-15, but some systems seem especially slow.Also, are you going by how chdkptp's reported framerate, or how it looks? Bugs in vid_get_viewport_live_fb can cause you to see old frames, even if the chdkptp frame rate is OK.If the chkdptp reported frame rate is low, the the frame last ms and xfer last ms stats may hint where the bottleneck is.
Both do work, but calling set_mf(0) after adjusting focus seems to cause a crash (after about 10 seconds). Any ideas?
I tried on Windows and I get a nice smooth 20+FPS instead of horribly inconsistent framerate I get on Ubuntu. Not sure what's causing it, but I don't think it's an issue with the port.
You can check the ROMLOG https://chdk.fandom.com/wiki/Debugging#Camera_crash_logs_.28romlog.29It's also worth checking if shooting crashes after using focusing with set_mf or set_aflock.
Started by X4IUAV
Started by a.pro
General Help and Assistance on using CHDK stable releases
Started by francky1606
Started by 551suxi
Started by kvelarun