The SX1 IS Porting Thread

[pev69]

Okay, here's the zebra modification for trunk 744. Unzip under the trunk744 dir and let it replace the files.
The changes in code are in core\gui_osd.c in functions gui_osd_zebra_init and gui_osd_draw_zebra. Plus definitions added for CAM_HAS_VARIABLE_ASPECT (include\camera.h) and PROPCASE_ASPECT_RATIO (include\propset2.h).

EDIT: There is a slight esthetic dismissal in the current logic when in 4:3 mode: canon's own OSD elements are not drawn on the black bars when zebra is visible; this is particularly noticable if you comment out the line
#define ZEBRA_CANONOSD_BORDER_RESTORE   1
near the beginning of the file core\gui_osd.c (this should cause all of canon's own elements to show with zebra, not just borders as the define does). It is due to the fact that I added a condition that nothing is drawn on the black bars when any zebra is drawn . Will correct it later.

EDIT: It is now part of the official trunk, since #752. Still haven't gotten myself to fix the canon OSD thing, sorry.

[fboesch]

PEV69! EXCELLENT!!! Clean and structured coding! and most important: WORKING! :-D

(i even saw in gui_osd.c, that my thoughts/suggestion of when and how to "calculate" the correction factor has been used and is working!) :-D

I'm extremely happy, that you are such a Crack! As said: I'm not a developer, but working as "translator" between Business & IT... I can read & understand many languages and code, but due to lack of practice/knowledge of syntax, it takes me too long to implement it. ...But it definately seems to workout great between us two! Thank you so much!

As said: I'm not a higher-programming-language crack, but I do love Assembler (since PocketPC's in the '80)! So I myself am just "learning" the ARM Assembler language for now (Syntax, commands), because I do want to find the PS.FI2 and Cont-AF issue...but due to the learning-curve (and because of our "normal" daily jobs), It may take another 2-3 weeks until the next major break-through.

Till later

F.

BTW: Regarding the EdgeOverlay....the fix for our SX1 is also within the EdgeOverlay Code....is it of use, if I'm tracking down the issue there and describe (in my simplified language) of what I think needs to be done?

[fboesch]

EDIT: There is a slight esthetic dismissal in the current logic when in 4:3 mode: canon's own OSD elements are not drawn on the black bars when zebra is visible; this is particularly noticable if you comment out the line
#define ZEBRA_CANONOSD_BORDER_RESTORE   1
near the beginning of the file core\gui_osd.c (this should cause all of canon's own elements to show with zebra, not just borders as the define does). It is due to the fact that I added a condition that nothing is drawn on the black bars when any zebra is drawn . Will correct it later.

Are you sure, that it is really a true issue? Because don't forget: there are "two" Custom-Display Modes on the Canon itself.

Yes: on the "first" one the Canon OSD will disappear after first "Zebra-Blink"....BUT if I push the "DISP" Button once (--> and use the 2nd Custom-Display Profile, including display of Detail-Informations) The OSD will work as expected...

Cheers

[pev69]

PEV69! EXCELLENT!!! Clean and structured coding! and most important: WORKING! :-D
...
BTW: Regarding the EdgeOverlay....the fix for our SX1 is also within the EdgeOverlay Code....is it of use, if I'm tracking down the issue there and describe (in my simplified language) of what I think needs to be done?

Thanks! I'll propably look into the edge thing next at some point. You may look at it if you wish , and I'm sure it is of use. But if you don't, no worries, I'm sure I'll find it on my own too .

BTW, as I already hinted in the zebra mod post, depending on your tastes you might want to comment out the
#define ZEBRA_CANONOSD_BORDER_RESTORE   1
near the beginning of the core\gui_osd.c. This causes all of canon's own OSD to be nicely visible during zebra drawing (but not currently on the black bars in 4:3 as I said). This WILL take about 85 kB more RAM during zebra, but as the SX1 has more than 1 MB free, should not cause much trouble.

EDIT: Oh, you replied while I was typing this. Well, it is not much of an issue, but still to my tastes a bit nicer

EDIT2: Oh, I don't know if we are talking about the same thing now, but if you are in 4:3 and have zebra on, when you press half-shoot, e.g. the camera's own ISO display on the right black bar disappears whenever there is any zebra stripes drawn on screen.

[fboesch]

EDIT2: Oh, I don't know if we are talking about the same thing now, but if you are in 4:3 and have zebra on, when you press half-shoot, e.g. the camera's own ISO display on the right black bar disappears whenever there is any zebra stripes drawn on screen.

Ah! I see! the "blinking" ISOxxx value....well....i compiled an "old" Trunk 730 & 744 (mod) for my S2 IS to check if this was then already the case.

In both versions (730 as well 744 including your "mods") the values (Shutterspeed/Aperture) are staying fine on the display (while blinking Zebra) on the S2 IS.

In both versions (730 as well 744 including your "mods) the values (ISO, Shutterspeed, etc) are blinking on the display (while blinking Zebra) on the SX1

So fixing the "blink" is already an additional fix for the SX1 :-)


EDIT: This was my "Post No. 100" :-D

[pev69]

Hmm, I guess there should be an option in the menus whether you want the canon OSD elements visible either:
1) never when zebra enabled
2) only during the "non-blink" phase of blinking zebra
3) always

In general about the OSD (both canon and CHDK) I was thinking that the user should be able to determine the order in which the different overlay elements (canon, zebra, edge, grid, CHDK osd, CHDK histogram...) are drawn.

Also I am planning to change the GUI-drawing system, because at the moment it is a bit mixed up, and also things like the zebra are unnecessarily consuming more RAM (albeit sometimes only temporarily, but this can still lead to RAM fragmentation, which is not good and can potentially lead to trouble in the firmware) particularly if trying to "restore" the original OSD. My new system would draw all elements in the same frame-buffer, and when combined with the user-defined drawing order, should be consistent, more user- and firmware-friendly, and potentially faster and more efficient.

I know, this all sounds so pompous, but I'll see what I can do

[reyalp]

Also I am planning to change the GUI-drawing system, because at the moment it is a bit mixed up, and also things like the zebra are unnecessarily consuming more RAM (albeit sometimes only temporarily, but this can still lead to RAM fragmentation, which is not good and can potentially lead to trouble in the firmware) particularly if trying to "restore" the original OSD. My new system would draw all elements in the same frame-buffer, and when combined with the user-defined drawing order, should be consistent, more user- and firmware-friendly, and potentially faster and more efficient.

I know, this all sounds so pompous, but I'll see what I can do

Pompous or not, if you can do it, that would be GREAT. The gui system is a mess. FWIW, I found the variable that stores the current canon bitmap buffer for the SD990. This is listed in lib.c along with hints to finding it.

I'll try to look at the zebra stuff as soon as I can if none of the other devs get to it, but I'm going to be quite busy for the next few days

[pev69]

Also I am planning to change the GUI-drawing system, because at the moment it is a bit mixed up ...
I know, this all sounds so pompous, but I'll see what I can do

Pompous or not, if you can do it, that would be GREAT. The gui system is a mess. FWIW, I found the variable that stores the current canon bitmap buffer for the SD990. This is listed in lib.c along with hints to finding it.

Hey, good, and thanks. I'm further encouraged now

I'll try to look at the zebra stuff as soon as I can if none of the other devs get to it, but I'm going to be quite busy for the next few days

Great. Although it is a really small change, and does not change anything for other cameras (for which the CAM_HAS_VARIABLE_ASPECT is not defined), so you could just replace the files in the trunk right away .

EDIT: Well, the only significant change for other cameras is that the buffer is cleared once it has been succesfully malloc'ed.

[elorup]

Thanks to all cracks starting that port! Great work and fascinating to follow the conversations. Keep on please.

I've played around with it a bit and also tried to get the Motion Detection scripts running (several ones from the CHDK site). Without any success. My SX1 IS always fired within some intervall even without any motion to detect.

Also changed the several parameter settings, but without getting the desired behaviour.

Has anyone of you had success with that already?

e.g.
http://chdk.wikia.com/wiki/UBASIC/Scripts:Lightning_script_--_Fudgey
http://chdk.wikia.com/wiki/UBASIC/Scripts:_Multipurpose_Motion_Detection
http://chdk.wikia.com/wiki/UBASIC/Scripts:_Lightning_Photography

Regards from Zurich
Eric

[alexpreyer]

I'm not sure if this thread is the right place to diskuss this, but here are my experiences.
Ich tried this one:

http://chdk.setepontos.com/index.php/topic,471.msg17797.html#msg17797

And it worked for me. Tested not much, but the motion dectection worked.
You have to be careful, because most of the motion detect scripts are for digic II/III and not testet for the digicIV which the SX1 is having.

[elorup]

Hi alexpreyer,

thanks alot for your fast reply. Sounds very promising  will move to a more appropriate place (http://chdk.setepontos.com/index.php/topic,471.135.html) for further discussion on motion detection issues.

Regards,
Eric

[pev69]

It is still possible, that if the motion detection has problems in SX1, it is a porting issue, and therefore should be discussed here, at least if those of you who test it find no help in other MD threads in the forum. The variable aspect ratio may very well cause trouble there as well, and the viewport parameters may still be wrong. I have not tested these issues myself, but I will try to look into the MD code as well when I can. I have been rather busy with other things lately (last couple of days), so I have not been able to do much anything for CHDK.

[fboesch]

hi all!  I was very quiet the last few days, due to private technical issues...the last three days I was forced to finally "Migrate", "Clean", "Consolidate", "Update", etc, etc my private Client-Server environment @home, and so my virtual "Dev" Environment was offline.

I'm still here and still working (if times allows me) on the "PS.FI2" (1st Prio) ....and after that other issues (Continous AF notworking - 2nd Prio)....

@elorup:  As you may have read: the Shooting in Series with Autofocus "ON" will not work. Cam will crash. May be this is also the reason why your Motion Scripts do not work...? --> try to set the Cam in "AF only on first pic" Shooting and try the scripts again. Would be interesting to hear if this works out (for now)

[reyalp]

Okay, here's the zebra modification for trunk 744. Unzip under the trunk744 dir and let it replace the files.
The changes in code are in core\gui_osd.c in functions gui_osd_zebra_init and gui_osd_draw_zebra. Plus definitions added for CAM_HAS_VARIABLE_ASPECT (include\camera.h) and PROPCASE_ASPECT_RATIO (include\propset2.h).

EDIT: There is a slight esthetic dismissal in the current logic when in 4:3 mode: canon's own OSD elements are not drawn on the black bars when zebra is visible; this is particularly noticable if you comment out the line
#define ZEBRA_CANONOSD_BORDER_RESTORE   1
near the beginning of the file core\gui_osd.c (this should cause all of canon's own elements to show with zebra, not just borders as the define does). It is due to the fact that I added a condition that nothing is drawn on the black bars when any zebra is drawn . Will correct it later.

I've added this, with some minor changes. SVN #752

In the future, please post a patch rather than a zip of modified files. It makes it much easier to apply if there are changes between when you submit your change and when I commit it.

[Sei]

Motion detection with fudgey's script works on SX1 (version 080914 for cameras with video button from this thread). Although to run it correctly I had to mask right and bottom cells. Cells from those areas actuate shots without reason. I think intervalometer is in some part "guilty" of this. During tests I have manage to obtain 80-100ms of minimum delay.