OSDev.org

I'm working on developing a graphical bootloader, and the first core component will be rendering the background layer. I want to support a single PNG with the same aspect ratio as the display being scaled up or down accordingly in size. I've been working on some of my own code to do this, but I've found it to be unusably slow (and it's only halfway done!). I've been trying to integrate GOP's `blt` function as well as an open source PNG decoder bzt sent me. What's the best way to handle image resizing? Is there any library I could integrate for other image manipulation functions (such as Gaussian blur)?

amyipdev wrote:I've been working on some of my own code to do this, but I've found it to be unusably slow (and it's only halfway done!).

Is it any faster outside UEFI? (Image processing is entirely self-contained, so you should have no trouble gluing your code to libpng or something to benchmark it.)

amyipdev wrote:What's the best way to handle image resizing?

Find an existing library that handles the type of interpolation you want to use.

amyipdev wrote:Is there any library I could integrate for other image manipulation functions (such as Gaussian blur)?

Sure. What language and license are you looking for?

(couldn't quote since sending from mobile)

I'll try outside UEFI later but I don't see any potential performance improvement (aside from being able to use >SSE2).

I've seen some libraries that could help but many seem far too large and complex to integrate for a bootloader (ImageMagick comes to mind).

As for the rest, C as the language, and GPL2 would be preferred but I cab work with Unilicense and MIT (certain BSD ones also work, I'll double check if something good is in BSD). If it's just for image resizing that's fine, I found an efficient Gaussian algorithm that I can reimplements myself.

amyipdev wrote:I've seen some libraries that could help but many seem far too large and complex to integrate for a bootloader (ImageMagick comes to mind).

If the license is permissive enough, you can copy the code without using the entire library.

amyipdev wrote:As for the rest, C as the language, and GPL2 would be preferred but I cab work with Unilicense and MIT (certain BSD ones also work, I'll double check if something good is in BSD).

How about stb_image_resize.h?

Octocontrabass wrote:

amyipdev wrote:I've seen some libraries that could help but many seem far too large and complex to integrate for a bootloader (ImageMagick comes to mind).

If the license is permissive enough, you can copy the code without using the entire library.

That's probably ideal. Often I just submodule in libraries, with exceptions (I needed to patch tomlc99, for example, as it's dependent on a C standard library implementation, so I couldn't submodule it in).

Octocontrabass wrote:

amyipdev wrote:As for the rest, C as the language, and GPL2 would be preferred but I cab work with Unilicense and MIT (certain BSD ones also work, I'll double check if something good is in BSD).

How about stb_image_resize.h?

Looks great, thanks!

@Octocontrabass

Is STB going to work within UEFI? I'm using POSIX-UEFI and I see that it seems to require stdlib (stdio can be declared out).

amyipdev wrote:Is STB going to work within UEFI?

As long as you provide all of the functions it depends on, yes.

amyipdev wrote:I'm using POSIX-UEFI

POSIX-UEFI is a cool project, but I'm not sure I trust the code quality. Instead of fixing the issue that causes this warning to appear, bzt disabled the warning. Same for these warnings.

amyipdev wrote:and I see that it seems to require stdlib

It only uses malloc() and free(). You can define STBIR_MALLOC and STBIR_FREE to make it use something else, like AllocatePool/FreePool.

Alright, thanks for the clarification. I definitely don't trust the code quality of POSIX-UEFI either - heck it didn't even cast right for printf integers, cutting off everything at 32 bits - but it works and I honestly don't mind it.

malloc and free are the only stdlib functions used throughout the entire STB? Alright then, POSIX-UEFI already has malloc and free so I should be all good to go. Thanks!

Every time I look at the code in POSIX-UEFI I find bugs. For example it loads your kernel at some fixed memory address without first allocating that memory or making sure it is free. It's fine if you are just toying around and don't want to learn how to use UEFI... But if you want your code to be reliable in any ways, I would move away from it.

For malloc/free, you can use dlmalloc. It is not hard to implement a mmap() function that uses UEFI to allocate chunks of memory and that's all that is required to use dlmalloc within an UEFI application.

For printf(), there are many options. Here is one: https://github.com/mpaland/printf. You simply need to write a small function that outputs a character to the UEFI console.

For memcpy/strcpy/etc: if you find writing these yourself to be challenging in any way, then I would argue that it will be good practice for you to do it. Otherwise it takes 15 minutes to write them all.