Programmatic access to image attributes

[Chuft-Captain]

Hi,

Does anyone know if any of the common tools such as The GIMP are able to decode/extract the coordinate and color attributes of an image (either greyscale, RGB, or CMYK) into say a CSV file.

I could then access the values programmatically in a spreadsheet. ie. I could make programming decisions based on the color value of a given pixel coordinate.

To take a very simple example, let's say I had a 16 pixel image which looked like this:

eg.jpg

...if the format of the output CSV file is: X,Y,R,G,B, then I might expect to get a file containing something like:

Code: Select all

0,0,0,0,0
0,1,64,64,64
0,2,128,128,128
0,3,192,192,192
1,0,255,255,255
1,1,0,0,0
1,2,64,64,64
1,3,128,128,128
2,0,192,192,192
2,1,255,255,255
2,2,0,0,0
2,3,64,64,64
3,0,128,128,128
3,1,192,192,192
3,2,255,255,255
3,3,0,0,0


Cheers
CC

[Spaceman Spiff]

Try saving with the PNM format in GIMP. It handles 8 bit RGB colours. This image (N.B., enlarged 16 times here!):

test.png

comes out looking like this:

Code: Select all

P3
# CREATOR: GIMP PNM Filter Version 1.1
4 4
255
0
0
0
255
255
255
...
255
255
255
0
0
255


... after I delete the middle 12 triplets to, er, save forum space. In any case, I find after re-editing all the values onto one row like so:

Code: Select all

P3
# CREATOR: GIMP PNM Filter Version 1.1
4 4
255
0 0 0 255 255 255 128 128 128 255 0 255 128 128 128 255 0 0 0 255 255 255 255 255 255 255 255 255 255 0 0 255 0 128 128 128 255 255 255 128 128 128 255 255 255 0 0 255


.. GIMP happily reads it back in OK.

You'll have to compute the pixel co-ordinates, but the X Y values ("4 4") tell you what you are dealing with. I've no idea what the following "255" means but I guess it's harmless to leave it alone.

Spiff.

[Chuft-Captain]

Thanks Spiff,

I'll have a look at that.
Incidentally, I discovered that the GIMP also exports "C" code .h and .c files complete with accessor functions... If I had a C compiler on my system, that would be the way to go!

For my needs your PNM method will probably do the job, just not quite as easily.

Cheers
CC

[jogad]

Hello,

As I have no idea of what you want to do, I am not sure to actually help.
Just to see, I wrote a little utility. It builds a csv file as you specified if your first post from a 24 bpp BMP file. (No gray scale).
Maybe useful? I join it to this post.
CSV files are really huge. Not sure that it is efficient.

[t00fri]

Thanks Spiff,

I'll have a look at that.
Incidentally, I discovered that the GIMP also exports "C" code .h and .c files complete with accessor functions... If I had a C compiler on my system, that would be the way to go!

For my needs your PNM method will probably do the job, just not quite as easily.

Cheers
CC

CC,

let me add that many image formats are organized very similarly. What differs are the image headers and often there is compression and the possibility for an alpha channel. PNG format is a close relative to PNM, except that PNG supports e.g. also alpha and various degrees of compression. PNG also exists entirely uncompressed like PNM format.

As an illustration of how versatile my F-TexTools are , you can use my tool 'png2bin' to just print out from a PNG texture the sequence of pixels you are interested in. That's what bin format is all about

> png2bin < test.png > test.bin

Then, in test.bin, you have all the pixels you want, except they are in hex format (00..FF). That is trivial to account for. Right?

Moreover, in these image files, one works in the "image frame" rather than the "XY frame".
For each texture line the 1 byte pixel values are listed successively for all columns of that line and then the next line follows etc. Moreover you have to run through the various color values, like so e.g. in line 1

RGBRGBRGBRGBRGB.......RGB
each of R,G,B is a number between 0 and 255 or in hex 00 and FF.
If you have an alpha channel as well then the only change would be
RGBARGBARGBA....RGBA

hence alpha is treated as a 4th color.

The transformation to XY coordinates is again a very elementary (linear) relation...
[2 equations, 2 unknowns ]

Fridger

[Chuft-Captain]

As I have no idea of what you want to do, I am not sure to actually help.
Just to see, I wrote a little utility. It builds a csv file as you specified if your first post from a 24 bpp BMP file. (No gray scale).
Maybe useful? I join it to this post.
CSV files are really huge. Not sure that it is efficient.

Thanks Jogad,
That's exactly what I was going to write (once I got a compiler sorted).
Did you make use of the "C" image dump (save as .c) in GIMP?
eg.

Code: Select all

/* GIMP RGBA C-Source image dump (eg2.c) */

static const struct {
  guint      width;
  guint      height;
  guint      bytes_per_pixel; /* 3:RGB, 4:RGBA */
  guint8     pixel_data[4 * 4 * 4 + 1];
} gimp_image = {
  4, 4, 4,
  "\4\4\4\377???\377\204\204\204\377\277\277\277\377\375\375\375\377\0\0\0\0"
  "===\377\207\207\207\377\302\302\302\377\374\374\374\377\0\0\0\0EEE\377||"
  "|\377\312\312\312\377\377\377\377\377\0\0\0\0",
};



Your utility is fast, it's just the further processing of the .csv file which I'm doing following that, which is currently very inefficient (as you predicted).

To give a bit of background idea of what I'm doing...

This is the Shackleton Base addon I'm working on at the South Pole of the moon:

city00.jpg

It's 25 km in diameter, and what I'd like to do is to have a 3D city inside the dome.

Now, given the size of this settlement, it's impractical and inflexible IMO to model the large number of buildings required by hand, so I've been experimenting with generating the city procedurally based on imagery.

By combining a chosen land texture for the settlement, with another image chosen to represent the layout of the buildings, we end up with something like this for example:

map01.jpg

By using your utility (or Fridgers) to dump the pixel values, and then further processing the output, we end up with an addon complete with 3D city, as shown in the following image (only the top half of the city has been done so far with about 13,500 buildings).
(From this distance you can't see individual buildings, but their locations are marked in blue):

city01.jpg

Notice the similarity in the layout of the actual buildings in the addon to the image map I used as a source.

CC

[Chuft-Captain]

let me add that many image formats are organized very similarly....

...Then, in test.bin, you have all the pixels you want, except they are in hex format (00..FF). That is trivial to account for. Right?

This is also a possibility, however I'm using Notepad+ to eyeball the files, and as far as I can tell, there's no HEX format in Notepad+.
I would like to be able to eyeball the contents of the bin-file in HEX or OCTAL rather than ASCII.

CC

[jogad]

Hello CC

Did you make use of the "C" image dump (save as .c) in GIMP?

No sorry. I don't use the Gimps. And I don't understand C programming.
I used the graphic routine of Delphi to process the bmp format as you can see if you take a look at the bmpToText.pas witch is the source file.

Thank you for trying to explain what you are doing.
I don't understand every thing but seem to be a great project.

When you have a compiler it will be very easy to process directly your images without need of intermediate cvs files.
But if it is easier for you and if you don't want bother with original graphic file formats, Friger's tool lead to more compact files that can be processed by program more easily than csv files.