GPL palette support
GoogleCodeExporter opened this issue · 9 comments
GoogleCodeExporter commented
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 commented
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 commented
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:
GoogleCodeExporter commented
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:
GoogleCodeExporter commented
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:
GoogleCodeExporter commented
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 commented
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 commented
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
GoogleCodeExporter commented
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 commented
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