IXUS 155 Port - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: [1] 2   Go Down

IXUS 155 Port

  • 15 Replies
  • 7278 Views
*

Offline brooss

  • *
  • 6
IXUS 155 Port
« on: 01 / June / 2021, 12:12:09 »
Advertisements
I've recently acquired an IXUS 155 which I see didn't have a port.

I have no experience with CHDK, but working mostly from the IXUS 145 port and following the Adding_support_for_a_new_camera guide I've been able to complete a working port.

So, what are the next steps to get my port included in svn trunk?
Logged
*

Offline reyalp

  • ******
  • 14119
Re: IXUS 155 Port
« Reply #1 on: 01 / June / 2021, 12:34:23 »
Hello and welcome :)

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.

Please include a notes.txt describing, what's been verified working and any port specific peculiarities or outstanding issues.

In case you haven't already found it https://chdk.fandom.com/wiki/Testing has some recommendations for testing.
Logged
Don't forget what the H stands for.
*

Offline brooss

  • *
  • 6
Re: IXUS 155 Port
« Reply #2 on: 01 / June / 2021, 12:53:39 »
Quote
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.
Ok, patch attached.

Quote
In case you haven't already found it https://chdk.fandom.com/wiki/Testing has some recommendations for testing.
Excellent, I had not seen that. I'll try working my way through it.
Logged
*

Offline reyalp

  • ******
  • 14119
Re: IXUS 155 Port
« Reply #3 on: 01 / June / 2021, 19:46:34 »
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 capt_seq_hdr.c
Code: [Select]
static long *nrflag = (long*)(0xa0e0)
is the same as the address in ixus145. Based on the addresses of other variables, this is quite unlikely to be correct (variables like zoom_busy at 0x6... moved, so a variable at 0xa... is unlikely to be the same between the two cams), which would result in corrupting memory if someone used this feature. So unless you've verified that dark frame override works, I suggest looking for an equivalent variable, or guessing an offset from the ixus145 and testing, but beware ixus145 could be wrong too.

Makefile has TODO comments on movie_rec.c, but still includes it in the source/object list. Since the hook isn't implemented (commented in boot.c), it shouldn't be linked.
Based on the camera generation, I would expect it to need different, more complicated quality override code (like ixus150) for video overrides to work, so I'd leave it out for now.

If video quality isn't implemented/working, the related define in platform_camera.h
Code: [Select]
#define CAM_VIDEO_QUALITY_ONLY              1
should be changed to
Code: [Select]
#undef  CAM_VIDEO_CONTROL

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. (see https://chdk.setepontos.com/index.php?topic=14022.msg143092#msg143092)

Additionally, the use of mode_get() should be switched to use camera_info.* like ixus140_elph130

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)

For the stuff above, you can submit a new patch based on the trunk, or I could provide diffs or builds to test.

In platform_camera.h:
TODO on CAM_CIRCLE_OF_CONFUSION. 5 matches the result from http://www.dofmaster.com/digital_coc.html

TODO on active area. You can determine the active area using the procedure on https://app.assembla.com/spaces/chdkptp/wiki/DNG_Processing

TODO 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.

I undef'd CAM_USE_ZOOM_FOR_MF. That feature is only intended for cams with native MF, and is broken on all non-ancient cams. This is the only non-comment / whitespace change I made.

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.

If you want to post a dump from your actual ixus155, it would nice to have just in case there turns out to be some significant difference down the road.

Logged
Don't forget what the H stands for.
*

Offline Caefix

  • *****
  • 947
  • Sorry, busy deleting test shots...
Re: IXUS 155 Port
« Reply #4 on: 02 / June / 2021, 11:15:38 »
Default Script changed from German to Dutch  :blink:
Code: [Select]
exec require'camtests'.runbatch{bench=true,filexfer=true,shoot=true,xfersizebugs=true} returns 26/0  :D

 ;) ... The lens is same as Ix255, so for main.c:
Code: [Select]
#define NUM_FL      101 // 101 zoom steps
#define NUM_DATA    2   // 2 words each entry, FL in MM*1000, 100
extern 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

mftest passed all, ndtest too: avg calc ND value=274 fw=276
Edit: Tiny Spacebar issue, same as Ix190 (minimal flicker on cam):
« Last Edit: 02 / June / 2021, 14:50:11 by Caefix »
Logged
All lifetime is a loan from eternity.
*

Offline brooss

  • *
  • 6
Re: IXUS 155 Port
« Reply #5 on: 02 / June / 2021, 23:28:48 »
Quote
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:
Great, thanks.
Quote
The patch was missing the loader directory. It's pretty much all boilerplate at this point, so I just copied the ixus145 files
Yes, sorry. Like you say, I just copied the ixus145 loader so that's fine.
Code: [Select]
static long *nrflag = (long*)(0xa0e0)Fixed this, and tested to be working now.
Quote
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.
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.
Quote
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)
Ok, updated from elph130.
Quote
In platform_camera.h:
TODO on CAM_CIRCLE_OF_CONFUSION. 5 matches the result from http://www.dofmaster.com/digital_coc.html

TODO on active area. You can determine the active area using the procedure on https://app.assembla.com/spaces/chdkptp/wiki/DNG_Processing

TODO on jpeg size: It matches the Canon specs, should be fine.
Updated/checked and TODOs removed.
Quote
All the CAM_SD_OVER* are 1. Are these verified? If not, you can check using mftest as described on the testing page.
Running mftest as described in the testing page says everything passes, but I'm not totally sure what everything means here.
Quote
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.
Note added.
Quote
The lens is same as Ix255
Thanks, updated.

Recommendations from the testing page now all look to be passing.

Framerate I'm getting in chdkptp-gui live view is quite poor, I'm not sure if that's typical or not though.

Patch attached.
Logged
*

Offline reyalp

  • ******
  • 14119
Re: IXUS 155 Port
« Reply #6 on: 03 / June / 2021, 02:06:09 »
Thanks for the patch. Checked in and enabled in autobuild in r5942, with a couple minor adjustments.

Quote from: brooss on 02 / June / 2021, 23:28:48
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.
Thanks for noting that. I'll try to find an ixus145 owner to confirm.

Quote
Ok, updated from elph130.
Not sure if it was intentional, but the patch included vid_get_viewport_height from elph130. The _GetVideoOutType() and vid_get_viewport_yscale() stuff probably doesn't make sense without the rest of that code, and only if the two cameras viewport characteristics are actually equivalent. The _GetVideoOutType() stuff is only relevant when using an analog TV out adapter.

There are two common variations in cameras of that era: Either the viewport is mostly 720x480 in rec mode, or it's mostly 720x240 (much of the CHDK code treats the width as 360). Your port appears to be set up for always being 240 as vid_get_viewport_yscale is not implemented, and will default to 1.

Having this wrong will affect things like histogram, zebra and motion detection in addition to live view, so it's good to make sure it's right in the common modes.

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.

Most ports don't handle all the more obscure permutations, and we only fix them if someone complains. ixus140 is an example of the 480 height variant that should handle pretty much everything, including TV out. ixus175_elph180 is an example of the 240 variant, but it's significantly newer and may vary in other ways.

Quote
Running mftest as described in the testing page says everything passes, but I'm not totally sure what everything means here.
Since you have chdkptp working, you can check mf and aflock there. In the console, use
Code: [Select]
=set_mf(1)
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.

Quote
Framerate I'm getting in chdkptp-gui live view is quite poor, I'm not sure if that's typical or not though.
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.
Logged
Don't forget what the H stands for.
*

Offline brooss

  • *
  • 6
Re: IXUS 155 Port
« Reply #7 on: 04 / June / 2021, 16:05:42 »
Quote
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.
Live view isn't cut off in any of the shooting modes now, so i think what's in trunk is right.

Quote
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.
Both do work, but calling set_mf(0) after adjusting focus seems to cause a crash (after about 10 seconds).
Any ideas?

Quote
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.
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.

Small patched attached to fix a palette issue in menus.
Logged
*

Offline reyalp

  • ******
  • 14119
Re: IXUS 155 Port
« Reply #8 on: 04 / June / 2021, 16:21:26 »
Quote from: brooss on 04 / June / 2021, 16:05:42
Both do work, but calling set_mf(0) after adjusting focus seems to cause a crash (after about 10 seconds).
Any ideas?
You can check the ROMLOG https://chdk.fandom.com/wiki/Debugging#Camera_crash_logs_.28romlog.29

It's also worth checking if shooting crashes after using focusing with set_mf or set_aflock.

Quote
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.
Agreed, it's very unlikely to be port specific. Performance on linux seems to vary widely for reasons that I don't understand.

edit:
Patch added in trunk 5944
« Last Edit: 04 / June / 2021, 19:13:18 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline brooss

  • *
  • 6
Re: IXUS 155 Port
« Reply #9 on: 06 / June / 2021, 18:24:42 »
Quote
You can check the ROMLOG https://chdk.fandom.com/wiki/Debugging#Camera_crash_logs_.28romlog.29

It's also worth checking if shooting crashes after using focusing with set_mf or set_aflock.

Shooting seems to work fine after setting focus with either method. Shooting with a SD override set through menus seems to work correctly too.
There doesn't seem to be any other issue with focus, just calling set_mf(0) causing a crash.

The log shows a call to SS:_MFOff happening on the camera after I call set_mf(0) in chdkptp, which seems to suggest the address mappings are correct. The camera then crashes some seconds later (seems to vary).

Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal