Can I convert a bmp from sd card to int[][] with color values?

Is there something like getpixelcolor()?

Any help would be greatly appreciated!

Thank you

Can I convert a bmp from sd card to int[][] with color values?

Yes, but it won't be a very big "int [][]".
Or did you want to generate the C source for the array declaration?

Thank you very much.
What do you mean, it won't be a very big int [][]?
I need to convert 290p x 440p 16bit images to int-arrays(one at once). I am using a Arduino due.
Can i just use the C commands?

Thank you.

What do you mean, it won't be a very big int [][]?

I mean, even on a Mega, you've only got 8k bytes of RAM.

Yes, it can be done.

Can it be done easily? probably not.

Problem 1: Memory.

The image is 290x440x16. That's 127600 x 16-bit, or 255200 bytes. Way too much even for a Due to handle. So you would have to work either streaming the data or in smaller chunks.

Problem 2: Image format

The bitmap image (I assume you mean a Windows BMP format?) isn't a straight raw pile of image data (it's a pile of raw something else, but that's just my opinion). It contains compressed data with chunks and headers and such, so you would need to first understand the format and how to read it. From that you could then write a program to extract some of the image data from the file and work on it.

I find it is far far better to pre-convert the images first (using my PC) into an uncompressed format that you can easily read and manipulate. You'll still have the problem of lack of memory to store it all, but if all you want to do is display it, then a raw uncompressed file could be read a pixel or so at a time and displayed directly - you don't need to remember all the pixels you've drawn.

When I need a raw file I tend to export the image as PNG, then write a small program using the GD library to extract the image data and write a file in the format I want.

It does not matter if the images are bmp or something else. I will gladly convert them on a pc. What would be the most suitable image-format? Png?
Or do you convert the pictures to the array on the pc and then import them as text-files?

thank you

If you're going to convert them on the PC, why not just plug the SD card into the PC?

That's what i meant. Import = drag and drop to the card.

Thank you very much

Eh??

You're asking on an Arduino forum how to drag and drop a file on Windows?

Regardless, as has been pointed out the resultant array will be much too large for an Arduino's limited RAM.


Rob

This image conversion control may help you. It supports more than thirty image and document formats, including PDF, TIFF, GIF, BMP, JPEG and so on. And image conversion is often finished at high speed without quality loss.

First off -- what are you trying to do? (What's the project goal?) The approach you take might be different whether you're creating a digital picture frame or a GUI for a touch interface, for instance.

Many LCD screens have libraries that already have image readers. So, in those cases, you'll be best off using the image format(s) supported by the existing library. If you're rolling your own lib for some reason, you might want to find (or write) a PC program to decode some common image format (e.g., BMP) and write a raw file. There is no absolute raw format -- it's raw data, and so can be represented in any number of ways. Typically, whatever's most convenient for the intended application. (Like it would be in your case.)

I usually just use a flat array, both as a file format and as a memory layout, thus memcpy() is all you need to read/write between the two. The image starts (x=0, y=0) at the top-left pixel and goes left-to-right (x) for each line (y). The number of bits per pixel obviously depends on color depth, but given a 24-bit image (R,G,B at 8-bits per channel), it would look like this:

pixel 0,0 red, green, blue  // First pixel at top left
pixel 1,0 red, green, blue  // One pixel to the right
....
pixel (<width - 1>, 0) red, green, blue  // Last pixel of first line
pixel (0, 1) red, green, blue  // First pixel of second line
....
pixel (<width - 1>, <height - 1>) red, green, blue  // Last pixel of last line

So the code to access any given pixel is:

byte  data[w * h * 3];  // For those allergic to malloc()  ;-)
byte  red   = data[(x + (w * y)) * 3];
byte  green = data[((x + (w * y)) * 3) + 1];
byte  blue  = data[((x + (w * y)) * 3) + 2];

Of course, you could just allocate your memory as a three-dimensional array and let C handle the offset calculations:

byte  data[w][h][3];  // 24-bit color
byte red   = data[x][y][0];
byte green = data[x][y][1];
byte blue  = data[x][y][2];

I use the first method mostly because I'm used to thinking of it as a blob. When you start getting into other color depths that don't align as neatly, the array index method falls apart and you're back to using offsets again. May as well get used to it.

If I am embedding the image into the code I often use a simple RLE compression algorithm to save space in flash. I also like to use a basic palette system, especially for things like icons that rarely want more than a few colours. Sticking to 8-bit images, which gives you 256 colours, which can be selected from a palette of 65536 colours, gives small files with plenty of depth.

The simplest way of doing RLE compression is the "double byte" method - two adjacent bytes the same indicates the start of a run, and the next byte indicates the number of the same bytes.

So the colour sequence, for example:
"0 0 0 0 0 0 1 1 1 1 2 1 1 3 2 3 9 8 3 1 1 1 1 9 9 9 9 9 9 9 3 3 1 2 2 2 2"
could compress to:
"0 0 6 1 1 4 2 1 1 2 3 2 3 9 8 3 1 1 4 9 9 7 3 3 2 1 2 2 4"
Or, to delimit the runs:
"[0 0 6] [1 1 4] [2] [1 1 2] [3] [2] [3] [9] [8] [3] [1 1 4] [9 9 7] [3 3 2] [1] [2 2 4]"

It works best, as you would imagine, with images with large blocks of the same colour.