Gpick generates gpl files with out of bounds colour-ranges for Krita and Gimp.

[GoogleCodeExporter]

I initially thought this was solely a Krita bug, so I first reported it to the 
Krita bugtracker:
https://bugs.kde.org/show_bug.cgi?id=318345

Basically, Krita and Gimp register rgb to go from 0 to 255, while Gpick and 
Mypaint go from 1 to 256, resulting in swatches with any of the colours at 256 
to throw errors in Krita and Gimp.

Original issue reported on code.google.com by griffinv...@gmail.com on 17 Apr 2013 at 2:04

[GoogleCodeExporter]

It's extremely likely you are simply using an out of date version of GPick. 
GPick 0.2.5 includes a fix for this issue. (note that in a slight oversight, 
the About dialog for 0.2.5 still reports "0.2.4", so you'll need to look at 
your package manager to be sure. Or just check whether 'Group and Sort' is 
shown in the palette's rightclick menu.

Original comment by fintic...@gmail.com on 22 Apr 2013 at 12:48

[GoogleCodeExporter]

(this is my old login. Comment #1 was also by me.)

Please confirm whether updating to 0.2.5 fixes the problem for you. 

If not, please give specific step-by-step examples of creating colors that 
export wrongly.

I have not, for example, been able to produce this bug by saving or exporting a 
palette containing  black, white, and full intensity red, green, blue, cyan, 
yellow, and magenta (ie. #f00, #0f0, #00f, #0ff, #ff0, #f0f), created using the 
RGB sliders. All values reported as 0 by GPick are also 0 in the GPL, and all 
values reported as 255 by GPick are also 255 in the GPL. 

Sample GPick 0.2.5 output attached.

Original comment by 00a...@gmail.com on 23 Apr 2013 at 7:11

• Changed state: WaitingConfirmation

Attachments:

• burntcolors.gpl

[GoogleCodeExporter]

Note that the claim made in comment #1 is incorrect -- GPick 0.2.5 does in fact 
report the correct version number, and it was my build which was out of date.

Original comment by fintic...@gmail.com on 3 May 2013 at 3:42