Hi @yugandhar,
Thank you for waiting.
With this script you can use to customize the text according to your preferences. You can adjust the following:
Kindly share the settings you’ve applied in your script and also the glyph folder that you have generated. I’ll get the header file for you first.
Script
generate_glyph_pngs.zip (1.1 KB)
Example of glyphs folder
glyphs.zip (36.5 KB)
Thank you
Hi @Pammy ,
In python script you shared, I can see font size(20) and glyph width(32), height(64). I think font size will be applied to draw the text which generates glyph image of specified width and height. Now what will be the font size I need to use in Ameba OSD API? is it 20(real font size applied) or 32(glyph width)? Please clear this confusion.
Edit: I attached the generated glyphs with different sizes. Please provide font header files for all szies I attached. We need to validate all font sizes.
Thanks,
Yugandhar
glyphs_roboto.zip (260.4 KB)
Hi @yugandhar,
FONT_SIZE = 20 is only used by Pillow to draw the character into the glyph image (32x64). It is recommended to use a glyph image size of 32×64 or larger. OSD pipeline is designed at 32×64 glyphs. The size of the text in the glyph image can be adjusted by FONT_SIZE.
Currently, the OSD text size is set to 28 (width) × 56 (height) slightly smaller than the glyph image size. I have tried example_isp_osd(0, 0, 32, 64); for the test .h file.
I’ve generated a sample header file for testing. You can try it out while I prepare other font sizes for further testing.
This is my updated PNG generation script, along with the settings I used for the test header file.
generate_glyph_pngs.zip (1.2 KB)
custom_font_argb4444_new.zip (35.5 KB)
Can I confirm your settings as follows,
Fonts: Roboto
Character Required - 0123456789`~!@#$%^&*()-=_+,./;‘’\<>?:”{}|abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
Color: draw.text((x, y), ch, font=font, fill=(255, 0, 0, 255))
Requirements: You need multiple font sizes for validation
Hi @Pammy ,
I forgot to attach python script which has all required characters. Please use attached script file. The character set you mentioned has different characters for single quote and double quotes, I think those are not ASCII. Please check in attached python script for character set.
Are you using the glyphs I shared or you are generating again?
I am not convinced with font size in OSD API. I have a requirement to calculate the text width and adjust the (x,y) for proper alignment of OSD on screen. If the font data is generated from glyphs with 32x64, what are the osd_char_w and osd_char_h values in below struct which won’t use scaling.
axOSDDateInfo[ix].font.osd_char_w = 32;
axOSDDateInfo[ix].font.osd_char_h = 64;
I am asking font data for different sizes to avoid scaling in OSD module. The scaling may generate wrong alpha values for glyphs with curves.
generate_glyph_pngs_roboto.zip (1.1 KB)
Hi @yugandhar,
The header file I provided earlier is a test file from my generation; however, it uses the same fonts as yours, Roboto Regular. Currently, I’m in the process of getting the header files based on the images you provided.
To clear some doubts, and also verified with the team internally.
osd_char_w and osd_char_h can be configured as needed and represent the target (scaled) output size displayed on the video overlay.
The current OSD pipeline always performs a resize operation during OSD initialization, even when the source glyph size and the target size (osd_char_w, osd_char_h) are identical (e.g., 32×64 → 32×64). As a result, minor processing effects may still occur.
These values are passed into rts_osd_init(), where scaling is handled internally via rts_set_char_size(). This function takes the original font data from the header and rescales it to the specified dimensions (osd_char_w, osd_char_h).
To minimize quality loss (e.g., blurriness during scaling), it is recommended to use higher-resolution glyph images in the header, especially when scaling up is required.
While we are checking internally with the development team on the feasibility of a no-scaling solution, may I check if it would be possible for you to proceed with the current implementation in the meantime?
Do let us know if you have any enquires.
Thank you.
Hi @Pammy ,
Please provide the font data header file with the glyph images of highest resolution shared by me. If scaling effect applied in OSD module even though same font size used, there is no use of evaluating different font sizes.
Is there any plan to release the ARGB font generation tool to public? It is better if so, otherwise if I need to add any extra character, again I need to request and wait for some time.
Thanks,
Yugandhar
Hi @yugandhar,
I may need your help to provide the characters “MmW@” with X_OFFSET of -2, -4, -6, as I’m currently observing some clipping from the images.
Alternatively, you may also share the 32×64 font rendering settings you used, so I can fine-tune the characters on my side.
Please feel free to correct the configuration below if anything is not accurate:
Roboto.zip (7.6 MB)
Is this the font you are using?
GLYPH_W = 32
GLYPH_H = 64
CHARS = "MWm@"
FONT_PATH = "Roboto/Roboto/static/Roboto-Regular.ttf"
OUTPUT_DIR = Path("glyphs")
FONT_SIZE = 32
PAD_X = 6
PAD_TOP = 12
PAD_BOTTOM = 10
X_OFFSET = -2
We do not have an official tool to generate ARGB4444 header files. However, I can share tools I’ve created to help preview characters for clipping issues and generate the header file after testing and finalizing.
Thank you.
Hi @Pammy ,
I used same settings to generate glyphs. I just checked the glyphs I shared with 32x64 resolution and no clipping available in the png images, How the OSD module can clip them? And also, I can see characters like g, p, q, y, etc. are not positioned properly.
Hi @yugandhar,
The clipping happens after the PNGs are converted into the ARGB4444 font table and rendered by the OSD module.
Therefore, some fine tuning is needed during the PNG-to-ARGB4444 conversion process, especially for glyph alignment and positioning, which is done in the script that I have written.
osd_char_w , osd_char_h that i have tested are,
Kindly try the attached header file, which was tuned based on the image you provided. Do let me know if there’s any issue.
custom_font_argb4444.zip (27.5 KB)
The OSD module scales and renders the characters according to osd_char_w and osd_char_h . If the scaling, character spacing, or display area is not suitable, some characters may still appear clipped, so further fine-tuning may be needed.
You may let me know if you have any osd_char_w , osd_char_h in mind that you want to try so i can tune for you beforehand.
Thank you.
Hi @Pammy ,
When I try to use the custom font provided, I am getting below stack overflow errors continuously and program stopped working. I increased from 10KB to 30KB, still same issue. How to calculate the stack size of rts_osd_task? The font data is around 380KB, Is OSD task copies any amount of it to stack?
Task name : OSD, TCB : 70cfc640
PSP 70fc3fd0 PSPLIM 70fa64c0
MSP 20003fb0 MSPLIM 20003000
I verified the custom font data which is around 135KB provided in OSD example with 10KB stack size and it is working without any stack overflow errors, but I am seeing errors like font of char 00000073 not exist. This error is common if the characters are not found in font data. But, the major issue with OSD lib is all OSDs are displayed with same color by omitting missed characters, even though I used different colors. When I used my old 1bit font data with all characters, all OSDs displayed with correct colors. It looks like a bug in OSD module, can you provide a fix for this also.
Thanks,
Yugandhar