On 6/27/07, Roberto Uhlig wrote:

Hello,
has/knows anyone a script/plugin (an idea) to go color by color through an indexed color-palette and doing an action for each color? I d like to create from a picture with an optimized color-palette with ca. 5-10 (may be 1-256) colors new layers or new pictures for each color in palette. Layer(s) or pictures must have the same extensions like the original picture. The new picture must be a black and white (1-bit) palette binary tiff for using in geo information systems as visible and invisible.

I do have an idea:

1. set the image's colormap to a grayscale gradient, where the intensity matches the index (eg. at index 0, #000000, at index 9, #090909..)
2. copy that

for each indice in the palette: 3. paste it as a new greyscale image 4. use the threshold function with (indice, indice) as it's range parameters 5. indexize to monochrome
6. save that image
7. delete the image from memory.
loop...

That can be completely automated by scripting

Quoting Roberto Uhlig :

Hello,
has/knows anyone a script/plugin (an idea) to go color by color through an indexed color-palette and doing an action for each color? I'd like to create from a picture with an optimized color-palette with ca. 5-10 (may be 1-256) colors new layers or new pictures for each color in palette.
Layer(s) or pictures must have the same extensions like the original picture. The new picture must be a black and white (1-bit) palette binary tiff for using in geo information systems as visible and invisible.

I have written a script
(http://flashingtwelve.brickfilms.com/GIMP/Scripts/Temp/save-as-map-masks.scm) which attempts to address your problem. I do not know how to save 1-bit TIFFs and so my script saves the files as RGB-mode black-and-white PNGs (I know Indexed would be smaller, but I was lazy).

From the comments in the script:

;; Saves a PNG file for each color of an Indexed image where that ;; color is replaced by white and the rest of the image is black. ;; The PNG's filename is derived from the name of the bottom ;; layer of the original Indexed image. The RGB colors are ;; appended to this name, separated by hyphens. ;; An example of an output filename would be ;; "Background-10-242-79.png".
;;
;; The files (one for each indexed color) are saved in the same directory as ;; the original image (or to the GIMP invocation directory if a ;; new image).

I have updated the script
(http://flashingtwelve.brickfilms.com/GIMP/Scripts/Temp/save-as-tiff-masks.scm). It now saves as a LZW-compressed TIFF.

;; Saves a 1-bpp TIFF file for each color of an Indexed image where that ;; color is replaced by white and the rest of the image is black. ;; The TIFF's filename is derived from the name of the bottom ;; layer of the original Indexed image. The RGB color values are ;; appended to this name, separated by hyphens. ;; An example of an output filename would be ;; "Background-10-242-79.tif".
;;
;; The files (one for each color) are saved in same directory as ;; the original image (or to the GIMP invocation directory if a ;; new image.

On 7/5/07, Roberto Uhlig wrote:

Hello and best thanks first,
but it doesn't work correct on my xp-pc with gimp GIMP 2.3.10. After private consultation with saul some testing and some changes for windows (backslash \) now it works fine. Essential change is, that saul's
;; (set! blue (fmod (aref color-map (+ 2 index)) 256)) doesn't work.
aref brings sometimes negative eg. -51 values. In that case you have to ad 256 to become the realy color-value for blue. So I implementet
(set! blue (aref color-map (+ 2 index))) (if (< blue 0) (set! blue (+ blue 256))) and it does his job.
I've tested it only under WINXP with Gimp 2.3.10 and also with 2.2.11.

Because of a bug in save-tiff-plugin in gimp 2.3.x (I din't know which was the fix) it isn't possible to save black-white (1bit) indexed with older gimp's. In my 2.3.10 it works fine.

Where can I find Informations about internals of the color-map int8array data storage, because I found that negative integer values?

I don't know where you can find that info; but I know myself -- Each image's colormap is made up of sets of 3 bytes (R,G,B); these values are unsigned. Since you have found you had to add 256 to the values in that case, it seems to me that script-fu must be wrongly treating the colormap values as signed values, and this is a bug.

Roberto Uhlig wrote:

but it doesn't work correct on my xp-pc with gimp GIMP 2.3.10.

[snip]

aref brings sometimes negative eg. -51 values. In that case you have to ad 256 to become the realy color-value for blue. So I implementet (set! blue (aref color-map (+ 2 index))) (if (< blue 0) (set! blue (+ blue 256))) and it does his job. I've tested it only under WINXP with Gimp 2.3.10 and also with 2.2.11.

INT8 and INT8ARRAY used to be signed values but these types were changed to unsigned a few versions back in the development version of GIMP. They are still signed entities in the 2.2 series of GIMP so storing values > 127 will read back as negatives.

Aref doesn't return negative values in the current development version of GIMP (built from SVN).