CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: waterwingz on 30 / October / 2013, 23:19:42
-
From time to time while writing scripts, I've found myself wishing for a way to display text on the camera's LCD in a larger font. Something that can be read from several feet away ( at least ). It doesn't take a lot of imagination to find situations where this could be very useful.
I took a look at the underlying code for the Lua text display function draw_string() (http://chdk.wikia.com/wiki/Lua/Lua_Reference#Drawings) and quickly came to the conclusion that the code was not written with any thought to allowing the user to specify fonts or font sizes. Changing that looks like a really big job !
So I decide to write a Q&D (quick & dirty) routine to let you display text in various font sizes. I ended up with a C language patch file for the existing CHDK trunk and a Lua-only routine to do much the same thing. I'll admit right here that my code does not let you specify the font face and it does not do proportional spacing, kerning, decenders, font hinting, anti-aliasing, or anything else fancy. Its just a way to put up a BIG message on the screen for those situations where you really need a big message - ugly fonts or otherwise. The image below show the displayed text in various user specified font sizes and colors.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FnXDX0hx.png&hash=a0a57dfca934b9b65cd1b83a014fffb8)
The new function is called draw_big_chars( xpos, ypos , text_string , fg_color , bg_color , font_size ).
draw_big_chars( 45, 15,"SMALL",258,259, 1)
draw_big_chars( 25, 30,"MEDIUM",271,266, 6)
draw_big_chars( 35, 90,"BIG",270,262, 12)The attached zip file has a patch file to add code to Lua to make this a built-in function, a test script for that new function, and it also has a Lua only version of the function that will work with any current version of CHDK.
Can this be improved? Absolutely! But working code is 100x better than good intentions so I'll post it here for anyone to enjoy.
-
Here's a version that uses the built-in font data instead of adding another font.
This also has the advantage of supporting all the special and non-english characters already in the built-in font.
I've added an optional 7th parameter that allows the Y scale to be set separately, if not included it defaults to the 6th parameter.
The built in font is 8x16 so if you set the vertical scale to 1/2 the horizontal scale you get same size characters on screen as your original patch.
Or you can do funky stuff like tall skinny characters or short fat ones :)
Phil.
-
That's very good idea!
But wouldn't it be better just add such functions to drawings module, instead of pushing them to lua itself? Just a suggestion.
-
Very interesting idea. I also think, it's better to add this function to the draw functions modul.
There are also a few suggestions in the SDM source code: http://trac.assembla.com/chdkde/browser/branches/SDM/core/draw_palette.c#L411 (http://trac.assembla.com/chdkde/browser/branches/SDM/core/draw_palette.c#L411)
But working code is 100x better than good intentions so I'll post it here for anyone to enjoy.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.kolobok.us%2Fsmiles%2Ficq%2Fgood.gif&hash=530a008ac06900a03f182fbeb59072a3)
msl
-
I decide to write a Q&D (quick & dirty) routine to let you display text in various font sizes.
SDM 1.86 Beta does of course already fully support this.
There are also a few suggestions in the SDM source code: http://trac.assembla.com/chdkde/browser/branches/SDM/core/draw_palette.c#L411 (http://trac.assembla.com/chdkde/browser/branches/SDM/core/draw_palette.c#L411)
Although that function still exists it is now redundant.
As far as I am concerned, SDM 1.86 Beta testing is now completed.
I will next update the documentation, then clean-up the code and finally an official release.
These days, because of the extreme selfishness and laziness of testers, this will not be a top priority for me.
I have photography to do instead.
-
Another little Lua script to exercise philmoz's version :
--[[
@title Big Font
--]]
stretch = 4
for size= 1, 10 do
for count = 0, 10 do
draw_big_chars( 1, 20,"ABC",258,259, size , stretch)
sleep(100)
end
if ( size ==4 ) then stretch=3 end
end
Fonts look much nicer his way.
-
Here's a version that uses the built-in font data instead of adding another font.
As I said in my original post, mine was Q&D. This is much better.
But wouldn't it be better just add such functions to drawings module, instead of pushing them to lua itself?
I wrote it in C originally thinking of a patch to the svn. Then I realized I could code it in Lua and did so, wondering if there would be a noticeable speed difference. From what I could actually see, the Lua version worked just as well.
Putting it into the drawing module is probably the best way to avoid increasing the size of the installed CHDK image if the script doesn't need/use the function. However, I don't believe that would allow philmoz's trick of using the currently installed font - which has much more resolution than the font file I found online.
Update : maybe a good compromise is a small Lua function that just returns the address of the current font bitmap so that the rest of the code can be in the drawing module?
-
Putting it into the drawing module is probably the best way to avoid increasing the size of the installed CHDK image if the script doesn't need/use the function. However, I don't believe that would allow philmoz's trick of using the currently installed font - which has much more resolution than the font file I found online.
Update : maybe a good compromise is a small Lua function that just returns the address of the current font bitmap so that the rest of the code can be in the drawing module?
I think outslider and msl meant to put the function in gui_draw.c rather than luascript.c
By using the built-in font the function becomes quite small so it won't add much to the core CHDK size.
I'd suggest adding two new functions to gui_draw.c - 'draw_char_scaled' and 'draw_string_scaled' to be consistent with the current draw_char and draw_string functions.
Note: this will still only use the built-in font, it won't allow scaled rendering of the RBF fonts.
Phil.
-
I think outslider and msl meant to put the function in gui_draw.c rather than luascript.c
I'm not sure that you are correct (outslider wrote the drawings.lua module after all) but regardless, it could go into drawings.lua in the CHDK/LUALIB SD card folder. Having said that, my personal preference would be to build it in as you suggest.
By using the built-in font the function becomes quite small so it won't add much to the core CHDK size.
I'd suggest adding two new functions to gui_draw.c - 'draw_char_scaled' and 'draw_string_scaled' to be consistent with the current draw_char and draw_string functions.
I played with a uBASIC function to do this as well but quit when I got the Lua version working. Even though uBASIC string handling is pretty much limited to the print function, it could still be useful.
Note: this will still only use the built-in font, it won't allow scaled rendering of the RBF fonts.
I think we can live with that.
-
... msl meant to put the function in gui_draw.c rather than luascript.c
That is correct. So we can use this function for other GUI applications. People ask me very often whether it is possible to represent CHDK OSD text elements greater?
msl
-
... msl meant to put the function in gui_draw.c rather than luascript.c
That is correct. So we can use this function for other GUI applications. People ask me very often whether it is possible to represent CHDK OSD text elements greater?
Okay .. I'll hold out the hope that outslider meant the drawings.lua module. :-[
Meanwhile, if I follow where msl is going with this, would a single "OSD" font size setting be sufficient rather than seperate font sized per element ? One of the problems there will be the q&d nature of both our hacks - the current steps between font sizes are pretty big. But searching back through the forum, its been a common request for years now.
Also, I just rediscovered the Lua bit operations (http://chdk.wikia.com/wiki/Lua/Lua_Reference#bitwise_operations) - my Lua script from earlier can use some cleanup.
-
Okay .. I'll hold out the hope that outslider meant the drawings.lua module. :-[
Yes, I did, but conversation led all of you to different approaches which are better - usage of built-in fonts, which is impossible from current lua itself. So, in any case - there's a need to add new lua funcs.
-
Patch with core code in gui_draw.c
Renamed Lua function to 'draw_string_scaled' to be consistent with 'draw_string'; but open to suggestions on this.
Phil.
-
Hey, do we really need a new lua function draw_string_scaled?
Currently we have:
draw_string( x, y, t, clt, clb)
Can't we just change it into:
draw_string( x, y, t, clt, clb [, size])?
Default size would be like now, but user could change the last parameter to decrease/increase size.
-
Hey, do we really need a new lua function draw_string_scaled?
Currently we have:
draw_string( x, y, t, clt, clb)
Can't we just change it into:
draw_string( x, y, t, clt, clb [, size])?
Default size would be like now, but user could change the last parameter to decrease/increase size.
Good point :)
New patch with optional parameters in 'draw_string' for scaling:
draw_string( x, y, t, clt, clb [, xsize [, ysize]])
Also fixes off-by-one error in draw_char_scaled function which removes some flickering and improves performance.
Phil.
-
Patch 4 works fine for me. Thanks for that.
msl
-
Patch 4 works fine for me. Thanks for that.
Ditto.
I did have another thought. If the scale parameter is 0, then how about a 1/2 size font? Thinking ahead, there are times when that would be useful with console debugging (assuming we take the next step and start allowing OSD stuff to use variable sized fonts ...). Also, the screen gets pretty crowded when Misc Values and the State displays and Debug data display are all active. Yes - hard on old eyes but with "cheater" it makes debugging somewhat easier.
-
Patch 4 works fine for me. Thanks for that.
Ditto.
I did have another thought. If the scale parameter is 0, then how about a 1/2 size font? Thinking ahead, there are times when that would be useful with console debugging (assuming we take the next step and start allowing OSD stuff to use variable sized fonts ...). Also, the screen gets pretty crowded when Misc Values and the State displays and Debug data display are all active. Yes - hard on old eyes but with "cheater" it makes debugging somewhat easier.
On newer cameras the font is already scaled x2 horizontally because the actual physical bitmap is 720 pixels (on the really old cameras CHDK started on it was only 360).
So a half scale horizontally can be done (with a bit of work) without any loss of fidelity in the displayed characters.
Phil.
-
I've added this in revision 3200 (trunk).
I'll look at the half scaling separately.
Phil.
-
So we can use this function for other GUI applications. People ask me very often whether it is possible to represent CHDK OSD text elements greater?
I've added this in revision 3200 (trunk).
So I did a bit of crash coding today when I should have been doing other stuff. I made it possible to change the text size of the standard CHDK OSD icons.
I'm sure it can use improvement - even I can see a few weak points in the data organization But its pretty cool to be here :
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FJZn7mOB.png&hash=e2ada29a15094af6c549ecc2b30abca9)
OSD text size selectable on a per icon basis. You just use the existing OSD Layout Editor - in addition to the up,down,right,left icon position control, you do a half-press to change the text size. Currently lets you select four sizes before it rotates back to the default size. In the editor, non-text icons ignore the half-press as (currently) does the OSD stuff with lots of text - state display, misc values and debug. But the rest do! Saving to config files is included - backward compatible etc. (Hope I got that part right ..)
Edit : need to play with the colored icons .. seems like they could be scaled too! And if philmoz gets 1/2 size text working it will need a few mods - ones well worth doing!
-
Very nice initial work!
I have found that a scaled font 16x16 (native 8x16) has a very nice look (see the screenshot from my newest script work). The ratio for x:y could be 2:1 with a single scaling factor.
msl
-
I have found that a scaled font 16x16 (native 8x16) has a very nice look (see the screenshot from my newest script work). The ratio for x:y could be 2:1 with a single scaling factor.
Thanks - that gives me an idea. As I said in the initial post of this thread, when scaled this way, the fonts gets ugly as they get big. However, building on your suggestion, I can recode this to scale in 1/2 steps, giving more choices ( 1:1, 2:1 , 2:2 , 3:2, 3:3, 4:2, 4:4 ...)
Nice looking script by the way - I get the idea from your screenshot!
Edit : typo - I really need a better keyboard
-
Okay .. here's a patch file that takes the font size up in "half steps" and a screen shot of how some of the look.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FwG104gv.png&hash=61e7344198011a712df51c4e34f8426d)
I also reordered the way the OSD editor steps through the icons to group them more logically.
-
Looks great. This could be a good improvement for CHDK 1.3.
msl
-
Looks good.
I think it might be possible to simplify the code a bit by putting the xscale and yscale values directly into the OSD_pos structure (and modifying the load/save code accordingly).
Also using '0' as a special case for unused entries might conflict with the option to use 0 as 1/2 scale in the Lua script. Might be better to just set currently unused values to 1.
I'll take a closer look over the weekend.
Phil.
-
I think it might be possible to simplify the code a bit by putting the xscale and yscale values directly into the OSD_pos structure (and modifying the load/save code accordingly).
Yea - thought about that but decided to defer that decision so that my test versions could stay backwards compatible.
Also using '0' as a special case for unused entries might conflict with the option to use 0 as 1/2 scale in the Lua script. Might be better to just set currently unused values to 1.
I did think about smaller font scalings and once I found myself using a plural on the scaling word I realized we might be better with negative numbers rather than using zero. (Hope that makes sense...) The other reason I use a 0 is to prevent the editor from trying to scale icons/text that should not be scaled. Using a 1 tells the editor that the icon is scalable and is currently 1:1.
Update : scaling the colored icons is on my "todo" list ....
-
Some fixes to the previous patch from waterwingz:
- moved ConfInfo ID numbers for scale values to start at 280 instead of 302. These are local to the specific conf file, so don't need to start at the next highest number across all conf files.
- removed the 1.2 mapping entries for the new scale values (they don't exist in 1.2 so no need to try and map them from an old config file)
- reset Clock default position & osd_edit width to 5 characters (minimum width rather than maximum width), otherwise you can't position the clock at the right edge of the display in 'normal' mode (without seconds).
Phil.
Edit: Updated patch to fix some issues with positioning of some OSD items if scaled, and prevent clock from being scaled in 4wins games.
This is probably ready for commit to SVN.
-
We don't have a "Like" button on this forum, so I'll just say "Like"
-
Personal words are always better than an anonymous button. I also say "Like". :)
msl
-
(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRlhj5BHKu9Se32QdiodHww4SPo1-QibYiwMYYcFMFsbrr494AD3A)
-
I think there is a small problem with the big font patch.
Misc values & override state does not work, nothing is displayed.
msl
-
I think there is a small problem with the big font patch.
Misc values & override state does not work, nothing is displayed.
Confirmed. I reverted versions and it's in the menu changes rather than the big font changes. It was also in my patches prior to philmoz working on it.
And its really not obvious why - at least not yet.
Update : found the problem and posted a patch. The worst part is it was caused by something I discussed above (0=don't scale) but did not handle in the draw_osd_string() function properly.
-
I think there is a small problem with the big font patch.
Misc values & override state does not work, nothing is displayed.
Confirmed. I reverted versions and it's in the menu changes rather than the big font changes. It was also in my patches prior to philmoz working on it.
And its really not obvious why - at least not yet.
Update : found the problem and posted a patch. The worst part is it was caused by something I discussed above (0=don't scale) but did not handle in the draw_osd_string() function properly.
Fixed in revision 3209 - I modified the solution slightly to still use draw_string if both scale values are 1 (slightly faster).
Phil.
-
Fixed in revision 3209 - I modified the solution slightly to still use draw_string if both scale values are 1 (slightly faster).
Thanks. I guess it doesn't matter much but I purposefully let a scale value of 1 use draw_string_scaled() in case we ever use different fixed and scalable fonts.
-
Two more little upgrades :
- patch files to allow misc values and state values to be scaled. Probably only useful for the first two sizes but who am I to judge?
- patch file to use the zoom key to increase / decrease font sizes in the OSD editor. Seems more natural than using the "shoot-half" key and allow you to decrease size without having to wrap all the way around.
Patch files can be applied seperately or together and in either order.
Note : You will need to reset your OSD config to use the state/misc value change - if you've used the previous version they will be locked at a fixed size in OSD__4.CFG file.
-
Good idea.
One note: a410|a430|a450|a460|a470 have no zoom lever.
msl
-
Good idea.
One note: a410|a430|a450|a460|a470 have no zoom lever.
msl
Likewise the iZoom (SD30) and i7Zoom (SD40), they use the button pad ^ and v
-
One note: a410|a430|a450|a460|a470 have no zoom lever.
Likewise the iZoom (SD30) and i7Zoom (SD40), they use the button pad ^ and v
Thanks for that - I wondered about it a bit. Can't be much fun entering large override values on those cameras without the zoom lever to change between digit.
In any case, here's an updated patch that also allows the shutter button to increase the font size with a half-press, wrapping back around when the largest size is reach. So in this version you can use the zoom keys if you have them, and the shutter button if not (or you just like pressing your shutter button a lot).
-
Thanks.
Now it should be ready for the trunk.
msl
-
One note: a410|a430|a450|a460|a470 have no zoom lever.
Likewise the iZoom (SD30) and i7Zoom (SD40), they use the button pad ^ and v
Thanks for that - I wondered about it a bit. Can't be much fun entering large override values on those cameras without the zoom lever to change between digit.
In any case, here's an updated patch that also allows the shutter button to increase the font size with a half-press, wrapping back around when the largest size is reach. So in this version you can use the zoom keys if you have them, and the shutter button if not (or you just like pressing your shutter button a lot).
Added in revision 3220.
Phil.
-
Added in revision 3220.
Phil.
Thanks Phil. Can you also add the patch to allow state & misc values to scale. I thought it was going to be difficult with the multiple lines so left it out originally - turned out to be trivial.
-
Added in revision 3220.
Phil.
Thanks Phil. Can you also add the patch to allow state & misc values to scale. I thought it was going to be difficult with the multiple lines so left it out originally - turned out to be trivial.
Added in revision 3223.
Phil.