Parsing pixels

July 9, 2019 2:41 AM

I want to produce simple planting plans in Artrage 4.5.9. Each planting type will be a separate layer in Artrage. I then want to parse the resulting colour layers to get the area (or percentage) of pixels in each layer and use the data to generate lists of plants.

Currently I draw colour-classed polygons in CAD (vectorworks) and then query the polygons and do some calcs to get my plant list and develop any other metrics I require. I normally have from one to say ten species per polygon and usually keep the number of plant types to ten or less. But the CAD is a pita and I could do much more and speed things up a lot if I could just draw my polygons as digital paintings and query the data more directly.

This is a very basic Artrage watercolour planting plan/ also showing layers palette. Each colour is a separate layer in the program which is the easiest way to produce updateable plans. This way I avoid having to discriminate different colours.

Artrage will save a photoshop\.psd file and export bmp jpef png gif or tif. It may (via a script) be able to export a separate image file for each layer (altho' I'm still reading on that) which may simplify parsing as I could just treat each file as a binary image but is there a faster way?

Artrage's native file - ptg is a monster and evening this simple graphix is 48Mb. psd files are likewise huge.

I'm willing to use R, imagemagick or other things (not that I'm too familair with those but I think that's where the answers lie) but do not know where to start for the best outcome

* I find handwork is understood better by some of my clients (than hard-edged polygons), I also have a visceral dislike of photoreal which also tends to produce unwieldy files.

I've just found a psd reader plugin for Paint.NET / but that's probably too indirect a route.

my system is Win10 64, I don't have photoshop.

posted by unearthed to Computers & Internet (5 answers total)

This is hard to do because of the variation in the colors in the image from Artrage. With some blurring and color reduction in ImageMagick you can generate an image with a limited color palette:

convert input.jpg -blur 0x5 -modulate 100,300 -blur 10x10 +dither -colors 9 output.jpg

With a simplified image we can count the colors using ImageMagick:

convert input.jpg -blur 0x5 -modulate 100,300 -blur 10x10 +dither -colors 9 -depth 4 -format %c histogram:info:-

That command run on your image will return something like this:

27567: (102,170,238) #66AAEE srgb(102,170,238)
31836: (102,255, 85) #66FF55 srgb(102,255,85)
8706: (187,238,102) #BBEE66 srgb(187,238,102)
34701: (204,102,204) #CC66CC srgb(204,102,204)
9376: (204,204,187) #CCCCBB srgb(204,204,187)
18788: (238,238,221) #EEEEDD srgb(238,238,221)
16947: (255, 85, 85) #FF5555 srgb(255,85,85)
30912: (255,255, 34) #FFFF22 srgb(255,255,34)
406077: (255,255,238) #FFFFEE srgb(255,255,238)

The first number is the count of the pixels of a color; to the right is the color. You can punch in the hex code colors (#66AAEE) on one of the online color pickers to figure out what color is what.

If Artrage exports a PSD with layers this whole process might be a lot easier. Maybe you could post the same Artrage image as a PSD somewhere?
posted by gregr at 7:54 AM on July 9, 2019

ImageJ, which lists area measurement and macros as features, might work. Or if you can't find a solution for your Artrage files, you could look into using Gimp (raster drawing) or Inkscape (vector drawing), both of which have pixel count/area measurement tools that I believe are also accessible through their scripting languages. (Sorry I don't have any specifics on how to actually do this, though for Gimp you could count non-white pixels using the approach described here.)
posted by trig at 1:45 PM on July 9, 2019

Response by poster: Thanks gregr, dropbox link for 3Mb .psd file. this was cropped in Gimp but I have no way of verifying whether it is compliant enough to be an acceptable Photoshop compliant .psd file for use by e.g. perl\pthon\imagemagick. The original Artrage .psd file is 48Mb but I guess (hope!) most of that is Artrage-specific data not needed in .psd

I barely know what I'm reading but I found this; PSD.js from reading a a page from perlmonks where I also found pixel counting on a fouling panel which looks like a less complex case than mine.

I should say I'm not capable of writing scripts; I understand my own problem and can understand just enough of other solutions to get the gist of a solution here and there.

zengargoyle and flabdablet have gottten me interested in cmdline solutions in especially perl and python and have both really shown me the value of non-gui solutions, especially returning text data I can further process and use.

Quick note on my process - Paint by layers - this way I can envision parsing can treat all transparent pixels as no data, and only count colour pixels as data. I accept there may be small areas of no-data withing colour blocks but this is fine as those no-data\white pixels will only represent maybe .01% of the surrounding color\data pixels.
posted by unearthed at 5:46 PM on July 9, 2019

Best answer: That PSD works perfectly-- with ImageMagick you can take the PSD and convert it into separate images :

convert input.psd output%02d.jpg
The "%02d" part makes each of the layers from the PSD numbered with two numbers, ie 00, 01, 02...

With the file you posted this generates 7 files. One seems to be blank the other 6 are the colored areas. You could then run this on each of your images:

convert output01.jpg -threshold 1% -format %c histogram:info:-

That will generate a count of pixels like this:

2478373: ( 0, 0, 0) #000000 black
90907: (255,255,255) #FFFFFF white

Then some math gives the percentage of each color--

(White/(Black+White))*100 = Percentage

(90907/(2478373+90907))*100 = 3.5382%

posted by gregr at 1:15 PM on July 10, 2019

Response by poster: Thanks heaps gregr! that looks very promising, makes me think this is all very possible. I'll go and have a play with what you've put up and see what I can do.
posted by unearthed at 1:20 AM on July 11, 2019 [1 favorite]