GPL palette support

[GoogleCodeExporter]

Because GPL (Gimp PaLette) format is used by many OSS graphics apps (GIMP, 
Inkscape, Scribus, GPick), it would speed up some processes to support it.

For example, GrafX2's palette editor is competent, but GPick is much better for 
the broader work of building palette ramps to start with, due to things like 
7-cell 'swatch' for side-to-side comparison of multiple colors, LAB 
gradienting, LAB/LCH based color selector, color contrast measurement tool, 
'layer mode' tool (ie. color A  OP  color B, with opacity O) which helps in 
getting colors for translucent surfaces, interactive gradient preview, and 
color scheme generation.

A few notes/ideas:

* The format of GPL is obvious from inspecting one with a text editor; I'll 
outline it here anyway (%s etc are scanf style representations of an editable 
value) :

** Line containing the exact string "GIMP Palette"
** Name: %s
** Columns: %d
** Line containing the exact string "#"
** Arbitrary number of lines '%3d %3d %3d\t%s'; each specifies an RGB color 
with a name. The name has no particular meaning.

* GPL supports an arbitrary number of colors. if more than 256 are contained in 
a file, inform the user that only the first 256 were loaded.

* GPL has a 'columns' setting for the palette. It should probably be used when 
possible, that would be a step closer to the idea of 'having a palette 
columns/rows setting included in the image data'

* Because GPL colors have names, it would be possible to include shade table 
info in GPL files as well.. see GPick's 'Autonumber' tool. Imagine each ramp in 
the shade table has a name 'foo', then you consider any string 
'[a-z_A-Z]+([0-9]+)' (eg. 'foo01', 'foo02') in the color name to indicate 
membership and position in the named ramp. The only caveat to this is that when 
loading, the order of ramps in the shadetable would be determined by the order 
of colors in the palette -- eg. if the first color's name is 'foo01 bar03' then 
'foo' would be the first ramp in the shadetable and 'bar' would be the second. 
Oh, and we couldn't accept more than 512 items after the necessary blanks are 
added, but practically speaking that's never going to occur anyway.

* When loading, whether shade table info is present could be autodetected 
(essentially, whether ( there are any ramps of length >1 AND the whole GPL 
isn't in one single ramp))

Just quickly writing this down, I expect to have time to implement it in a week 
or so.

Original issue reported on code.google.com by 00a...@gmail.com on 30 Nov 2012 at 11:29

[GoogleCodeExporter]

This was supported in earlier versions of GrafX2 (at least the most basic 
palette loading). It looks like it was broken when adding support for Paint 
Shop Pro palettes which are very similar but not identical.

The paint shop pro format is currently the default. Feel free to make GIMP 
format be the default one again, but make sure we can still load JASC format as 
well (they are the same besides the header, anyway).

Original comment by pulkoma...@gmail.com on 3 Dec 2012 at 6:01

[GoogleCodeExporter]

Actually, they're -not- the same besides the header. JASC colors are not named, 
nor are the component values padded (this means you can't use the same scanf 
format to read them.)

An early draft of a GPL support patch is attached.
It currently only has test and load support, at a basic level (nothing related 
to building a shade table yet). Additionally, some old GPL palettes do not load 
correctly -- I haven't had time to figure that out yet.

Original comment by 00a...@gmail.com on 12 Dec 2012 at 9:56

Attachments:

• gpl-v1.diff

[GoogleCodeExporter]

Bug fixed -- it occurred for any color whose name contained spaces.
updated patch attached.

Original comment by 00a...@gmail.com on 12 Dec 2012 at 10:30

Attachments:

• gpl-v2.diff

[GoogleCodeExporter]

Version with working save support is attached.

This now has the basic level of functionality (load and save colors, ignoring 
names).
Implementing shade table <-> name translation will take significantly more time.

Original comment by 00a...@gmail.com on 12 Dec 2012 at 11:03

Attachments:

• gpl-v3.diff

[GoogleCodeExporter]

I think we have to move the loading/saving of palettes into the palette screen. 
It requires a difficult reorganization of the screen, but it's clearer, allows 
saving all those different palette formats that we can load, and it frees up 
several "slots" in the format dropdown for images.

Original comment by yrizoud on 12 Dec 2012 at 1:45

[GoogleCodeExporter]

Until now we only had one 'PAL' format that would perform auto detection of 
JASC and PAL formats.
I added some Microsoft one recently, and now we have this one. So, maybe it 
makes sense to move this out of load/save. However, maybe we should put them in 
"palette settings" rather than the palette editor ? There's more space there.

Original comment by pulkoma...@gmail.com on 12 Dec 2012 at 6:07

• Added labels: OpSys-All

[GoogleCodeExporter]

Personally I certainly agree with putting them in palette settings rather than 
palette editor, unless we intend to support loading sub-palettes (select a 
range in palette editor, entries are loaded only into that range). It matches 
at least in frequency of use (rare).

However the palette editor screen is already due for a reworking, as Yrizoud 
points out. Some buttons (Gray, Neg) are rarely applied enough that they belong 
in a popup menu similar to 'Sort' rather than occupying screen space 
permanently, and it seems rather likely that the two [verb], X-[verb] pairs of 
functions can be merged into one button each. If you're thinking like that, 
then load and save could go in the same menu of rarely used functions as Gray 
and Neg, and would occupy no permanent screen space.

Original comment by 00a...@gmail.com on 12 Dec 2012 at 9:39

[GoogleCodeExporter]

The GrafX2 UI isn't much into menus. There's a good reason for that : using 
plain buttons allows you to see everything at once, and avoids us bug reports 
where users ask for a feature that is already available, but that they didn't 
find in the UI.
Same apply (even more) for buttons having a different action on right click. 
This is quite unusual and unexpected from users, so we try to avoid it, except 
on the main menu.

Another approach to free space would be to use icons in this window. I think we 
can get things like "spread", "swap", "neg", "sort" expressed with icons rather 
easily.This would reduce the buttons to a smaller size, allowing for a bit more 
space without going with nested menus.

Random unrelated idea: maybe we could have a special marker (top right corner 
folded or so) to indicate there's an extra function on right-click of a button.
Example in DOpus 4 from Amiga: http://aadb.amiga.me/data/DirOpus4.png
IIRC the extra function will show when right clicking the button, and execute 
when releasiung the mouse button unless the pointer moved elsewhere in between.

Original comment by pulkoma...@gmail.com on 15 Dec 2012 at 8:07

[GoogleCodeExporter]

Patch applied in r2112. I made space for load and save buttons in the palette 
screen.

Original comment by pulkoma...@gmail.com on 4 Mar 2015 at 1:46

• Changed state: Fixed