Hello,

I tried posting this question without success. I have reformatted the question in clearer terms. I hope someone can help with some insight ... here it goes:

I have a question about resizing graphics loaded from an external flash memory while in runtime. Here's the issue.

I have my own graphics library which is able to retrieve text, icons or pictures from an 8MEG flash and display them on either a 1.5 " or 2.0" color LCD. Here's the thing though, when I am using the 1.5" LCD and I display an icon it has to be a certain size. However if I display that same icon on the 2.0" LCD, it has to be slightly bigger. The reason why I need both sizes at any given time is because my project requires that I allow the user to disconnect the 1.5" LCD and reconnect the 2.0" (or vice versa) while the MCU is running. My question is, for us embedded guys that are using PICS with limited memory what are our options to resize graphics only using an MCU and on the fly.

Right now I am stuck in storing that same text, icons and pictures in two different sizes in flash actually wasting flash memory.

The option I am looking for would be to store the text, icons or pictures in flash once as the biggest size only. Then when I want to display a text, icon or picture I would load it into the MCU and according to the size that I require I would reduce it (Palletize and resize) in respect to the current LCD I am hooked up to and then display it. Here's the catch though... I need to do this all in run time.

So, what I am asking is, is there code done in C that I can include in my C project source files which would have the capability to paletize and resize graphics in the MCU at runtime. I know there are utilities out there that can resize fonts and pictures... but I need a piece of code that does this rather than a PC utility app.

All feedback is very appreciated.
Rob

 

If you use a PIC system they actually have a graphics GUI creator where you can make backgrounds, menus, buttons, logo's, etc.. Then it outputs it into a format to be loaded onto the pic.

 

Resizing is a processor intensive undertaking.

Windows 3.11 through later versions of windows had different sized icons for different screen resolutions due to this simple fact.

For code to port to try it out, look at the source for resize at www.imagemagick.org That is an awesome graphics package, essentially a "Command Line Photoshop'.

I'd strongly suggest resizing for both anticipated screens and saving both on the SD card/flash and loading the appropriate one at runtime. Graphics manipulation takes a good deal of RAM to carry out.

 

thatoneguy,

"Windows 3.11 through later versions of windows had different sized icons for different screen resolutions due to this simple fact."

wow! I didn't know that.

"I'd strongly suggest resizing for both anticipated screens and saving both on the SD card/flash and loading the appropriate one at runtime. Graphics manipulation takes a good deal of RAM to carry out. "

Okay. Or I would just have to do my own palletizing and resizing code myself. Huummm. If I dive into this, I will definitely need more speed than 80 MHZ from my PIC32.

I was wondering, would you know of a forum specialized in bitmap manipulation techniques where I can discuss on how I would plan to do this.

Anyhow, thanks for your input!
Rob

 

maxpower097,

So If I need 10 different sizes of a list box with special patterns, I would have to keep all this in my PIC... or even better yet if I need 100 icons in 10 different sizes, I would have to load all 1000 icons in my PIC...... so how much memory in my PIC will this take up???

Also if I need a control with special functionality that does not exist in GUI creator? I still would have to do what I am doing now. I am back to square one!

I have breifly looked at GUI creator a couple of months ago and was not very impressed.

 

If you google "resizing algorithms" you will find a ton of methods, some with source code, most are variants for better quality, but I think staying with the basic resizing methods, such as nearest neighbor, would be best.

 

Hi thatoneguy,

Well from what I have been reading, nearest neignbour is not the most precice method... I think bilinear or bicubic are better methods.

But isn't an off the shelf C code module that does all this available somewhere?

Something like what this guy is doing but off the shelf and done in C so we can include the code in an embedded application:

http://www.codeguru.com/forum/showthread.php?t=360214

Regards
Rob

 

I would imagine you could scale icons with software and a pic. But yes. The way it works on a PIC is it loads all the graphics in memory and links it all. It has a wizard to make it easy, so there may be a more complex way to do it and actually render jpg's, etc.. But for speed and ease MC has a graphics wizard for MCU's with LCD's. Haven't played around too much with it but it looks pretty easy to make anything you could want. You could also store graphics on memory chips, sd cards, internal epprom, etc..

 

Hi thatoneguy,

Well from what I have been reading, nearest neignbour is not the most precice method... I think bilinear or bicubic are better methods.

But isn't an off the shelf C code module that does all this available somewhere?

Something like what this guy is doing but off the shelf and done in C so we can include the code in an embedded application:

http://www.codeguru.com/forum/showthread.php?t=360214

Regards
Rob

That code would require a bit over 2k of RAM (assuming 128x90 x2), enough for both images to fully be in RAM at the same time. If you have the memory, this isn't an issue, but it usually is with microcontrollers.

The second issue is that he stated it required 4 seconds to resize an image that was resized "instantly" in a different program on the same hardware. From the article date, I'd guess the CPU speed was at least 1Ghz, even if you count 50% of that for the OS, 500Mhz taking 4 seconds is a massive number of CPU cycles. What he posted was in C could be ported to most any C compiler with some work though.

If you do have the RAM and want to do a proof of concept, I'd suggest trying it and posting the results here, I'm very interested in how it turns out, I may be entirely wrong with my guesses and the power of the PIC32 series.

At the same time, storage has gotten down to the cost where it is cheaper to simply store two copies if there are only 2 choices for output. One could have the resizing code on the PIC, and only run it once after the screen size is determined, storing the results, I suppose.

 

maxpower097

>I would imagine you could scale icons with software and a pic. But yes. The way it >works on a PIC is it loads all the graphics in memory and links it all.

So your saying the pic would load the 100 icons in 10 different sizes of the same icon?
So I would have 1000 icons in my PIC???

get back?

 

<That code would require a bit over 2k of RAM (assuming 128x90 x2), enough for both images to fully be in RAM at the same time. If you have the memory, this isn't an issue, but it usually is with microcontrollers.>

uummm .... my lcd is a 16 bit per pixel color depth at 176 x 220 res. so a full pic would require appr. 77K. So for an icon of 128x90 pixels would require approx 23Kx 2 !!!!
Not very doable with PIC32!

<The second issue is that he stated it required 4 seconds to resize an image that was resized "instantly" in a different program on the same hardware. From the article date, I'd guess the CPU speed was at least 1Ghz, even if you count 50% of that for the OS, 500Mhz taking 4 seconds is a massive number of CPU cycles. What he posted was in C could be ported to most any C compiler with some work though.>

1- I don't like the part "with some work though"
2- The PIC 32 MCU I am using is 80MHZ internal clock and could go a little faster with optimizations turned on.... but a far cry of 500MHZ!!!

>If you do have the RAM and want to do a proof of concept, I'd suggest trying it and >posting the results here, I'm very interested in how it turns out, I may be entirely >wrong with my guesses and the power of the PIC32 series.

hum! But I need more speed if I Iam to go through all of this.

regards

 

It really doesn't make too much sense to do.

If you have a device with a built-in display..i.e. Embedded, there is no reason to have to resize images or store separate icon sizes.

The memory card that holds the images should be different with the 1.5 or the 2" display.

If this was a cellphone, why would you need this option? The screen is not going to change.

However, it is possible to "zoom" into your images when you have taken a picture on your cell.

So, maybe looking into zooming images on the device, you will essentially find your answer.

I have only played with the touchscreen on the EasyPIC6, and have used the available libs.

If you look into image editing, and particularly a zoom and crop, the info you want should be around.

It does seem awful processor intensive.

If you had a multicore uC, you could assign the resize to a core, or have a seperate graphics uC. The DSP PICs.

You could ask it to retrieve the image file, resize, and make a pin high when the task is complete.

This way, you need not affect your primary processor while the image resize is processing.

Another thing is, this could be done at boot-up.

Once the file is resized and saved, it need not be done again, until the display is changed.

This leads back to my original thought. Do the conversions on a PC and swap the flash memory with the display.

I suppose half the fun is seeing if you can do it.

 

I suppose half the fun is seeing if you can do it.

Yeah, I'll admit to being interested in this, it would be pretty cool!

 

Yeah, I'll admit to being interested in this, it would be pretty cool!

Well thats good to read. More gets done when more are interested.

I was thinking that it may be worthwile to look into animation techniques on these displays also.

Instead of drawing 50 of the same image of different size, there is probably a zoom technique.

There are alot of Arduino sheilds with displays, and as I said the EasyPIC6 has a qvga display, so there has to be libs for these things abound.

 

>The memory card that holds the images should be different with the 1.5 or the 2" >display.

>If this was a cellphone, why would you need this option? The screen is not going to >change.

cause its not a cellphone! See my innitial post where I said:

The reason why I need both sizes at any given time is because my project requires that I allow the user to disconnect the 1.5" LCD and reconnect the 2.0" (or vice versa) while the MCU is running.

I need to be able to swap LCDs to different sizes on the fly. Having a different flash for every LCD, means I would have to sell the LCD with the flash..... its just not feasable there are too many lines between the flash and the MCU... I think something like 22 address lines and 8 data lines + control lines.... that would be one hell of a connector.

>However, it is possible to "zoom" into your images when you have taken a picture on >your cell.

>So, maybe looking into zooming images on the device, you will essentially find your >answer.

The device is my own hardware... I am on my own here... there is no established platform or kit I am working with!


>I have only played with the touchscreen on the EasyPIC6, and have used the available >libs.

>If you had a multicore uC, you could assign the resize to a core, or have a seperate >graphics uC. The DSP PICs.

>You could ask it to retrieve the image file, resize, and make a pin high when the task >is complete.

>This way, you need not affect your primary processor while the image resize is >processing.

An extra processing part will increase costs... I unfortunately can't do that!

>I suppose half the fun is seeing if you can do it.
Nope. I will do what's most efficient. I will store the icon once and retreive it and resample it to the desired size and then display it. It doesn't seem that hard to resample a graphic icon or image. The issue is after I do all of this resampling how slow will the PIC32 go? That's why I am posting questions on resizing and resampling..... because I am not convinced that the MCU can do the job in lightning speeds.

Thanks for your help!
Rob

 

Ok, slow down. I read your inital post and I understand it is not a cellphone.

By device I mean the PIC. Not your creation.

Look for people that have done these types of thing with the same PIC family.

Does that straighten things out?

How your system determine the difference between displays?

Will it auto sense which display is plugged in?

What color depth are you using for these bitmaps?

 

maxpower097

>I would imagine you could scale icons with software and a pic. But yes. The way it >works on a PIC is it loads all the graphics in memory and links it all.

So your saying the pic would load the 100 icons in 10 different sizes of the same icon?
So I would have 1000 icons in my PIC???

get back?

Traditionally without any additional code yes. But you could probably write some code to take 1 icon and scale it down 9 times. So then you would only need to store one image.

 

Exactly maxpower097 !

ANd that's the goal of this thread to see if there is any off the shelf code I could use to take 1 icon and scale it down 9 times and all done *in* the MCU at runtime.

R

 

Exactly maxpower097 !

ANd that's the goal of this thread to see if there is any off the shelf code I could use to take 1 icon and scale it down 9 times and all done *in* the MCU at runtime.

R

Give it a shot. I looked over the code again, and it would appear you only need to change a few things that will pop up at compile time depending on the compiler. It is ANSI C without any external libs used, and no reserved keywords that I saw, so give it a shot and let us know!

If you are dealing with a 30x30 icon, that will be fast, but as image sizes increase, time goes up by the square.

 

>Look for people that have done these types of thing with the same PIC family.
I am pretty new to this resampling stuff so its a little difficult for me to be clear with my questions....

I am trying to find people that have used an off the shelf code module to dowsample or up sample an image *in* the MCU. I think though for down sampling its easy to do myself as shown in this link:

http://www.giassa.net/?page_id=174

But upsampling, I would have to use nearest neighbor, which would be a rough result. Or I can use nearest neighbor interpolation... but have never done this with RBG... or I can try to use bilinear/cubic interpolation techniques... However, I am have trouble finding clear samples to use these techniques in reference to pixels and RGB. So thats why I am looking around to see if there exists some pre-made code.

Tell me something, in __principle __ if I have 2 pixels one next to each other and say the 1st one has an RGB value of [255, 0, 0] (which is RED) and the second one has a value of [0, 255, 0] (which is GREEN) and I want to insert a pixel between the two. Shouldn't the new pixel be the average of the two.. something like this:

1st - [255, 0, 0]
2nd - [128, 128,0] <<< new one!
3rd - [0, 255, 0]

>How your system determine the difference between displays?
>Will it auto sense which display is plugged in?
Yes!

>What color depth are you using for these bitmaps?
16bpp

Thanks for your reply...
Rob