On Sun, 9 Feb 2014, Alexandre Prokoudine wrote:

Hi,

I'm curious if we have a plan for assets in v2.10 and onwards now that 16/32 bit is possible. Color palettes and gradients are still based on raw 8bit RGB values, and pattern files are 8bit as well.

Jumping in sideways... I'm getting interested in this as well. The current resource file definitions, which we (that is Krita) mostly use, we just choose to make sure we were compatible with gimp, and they are a bit limited.

FilmGIMP/Cinepaint "fixed" that in the past by converting everything to 16bit integer (afaik, integer), but I'm not sure if that's such a good idea.

I'm sure it isn't :-) There's the same limitations, except for that one tiny difference.

Some things to consider, in no particular order:

- IMO, ideally, stock color palettes should be using a linear device-independent color space (some sort of LCh?); - it should be possible to use palettes that rely on arbitrary color models (RGB, LAB) to make paint vendors happy; - we still need to solve the i18n issue that was raised recently (non-translatable palettes/colors/etc. names).

Three times yes.

In my opinion, a sensible way to approach that would be using an already available, but somewhat forgotten file format devised by Olivier Berten during his work on SwatchBooker:

http://selapa.net/swatchbooker/

To reiterate my earlier email to create@, the benefits of this file format are:

- simple combination of XML + ZIP - (nearly) any color model + optional mapping to an embedded ICC profile - flat colors and gradients supported - spot colors supported
- i18n-ized names of all metadata fields and color names

There is no other file format that would provide the same set of features for us, free or non-free:

http://www.selapa.net/swatches/colors/fileformats.php

So the questions are:

- Is changing the assets file format something we need to do for 2.10 (or maybe at all)?
- Is the SwatchBooker's file format right for us? - do we actually have resources to make the switch?

I cannpt answer for GIMP, obviously, but for me, one of the reasons I didn't put time into a switch is that I didn't think any other relevant (that is, free) app would follow suit. Resources for Krita are stretched as well, and one of the big issues is creating software that can create resources in the new format, but I really would like to leave the twentieth century and get current...

Boud

(Who needs to find a way to work on Krita's gradient editor anyway.)

On 02/09/2014 07:55 PM, Alexandre Prokoudine wrote:

Hi,

I'm curious if we have a plan for assets in v2.10 and onwards now that 16/32 bit is possible. Color palettes and gradients are still based on raw 8bit RGB values, and pattern files are 8bit as well.

FilmGIMP/Cinepaint "fixed" that in the past by converting everything to 16bit integer (afaik, integer), but I'm not sure if that's such a good idea.

Some things to consider, in no particular order:

- IMO, ideally, stock color palettes should be using a linear device-independent color space (some sort of LCh?); - it should be possible to use palettes that rely on arbitrary color models (RGB, LAB) to make paint vendors happy; - we still need to solve the i18n issue that was raised recently (non-translatable palettes/colors/etc. names).

In my opinion, a sensible way to approach that would be using an already available, but somewhat forgotten file format devised by Olivier Berten during his work on SwatchBooker:

http://selapa.net/swatchbooker/

To reiterate my earlier email to create@, the benefits of this file format are:

- simple combination of XML + ZIP - (nearly) any color model + optional mapping to an embedded ICC profile - flat colors and gradients supported - spot colors supported
- i18n-ized names of all metadata fields and color names

There is no other file format that would provide the same set of features for us, free or non-free:

http://www.selapa.net/swatches/colors/fileformats.php

So the questions are:

- Is changing the assets file format something we need to do for 2.10 (or maybe at all)?
- Is the SwatchBooker's file format right for us? - do we actually have resources to make the switch?

Opinions?

Yes, that seems necessary.

But I don't like much how i18n is handled in the SwatchBooker format. I don't think the file should contain the names in multiple languages. Most resources distributed outside of Gimp (DeviantArt, etc...) are by isolated authors, and I would not expect their resources to be tagged in more than two or three languages (English plus their native languages). I18N support is done by users, and that would mean making a local version of the file to display the file in the user's language. I would think a single name in the file, remapped using a locale-dependent translation file (one in /usr/share on in the user's profile) would let users rename resources more efficiently. This method could also be used to display localized names for other resources (brushes, patterns...).

I agree with the file-format,
ad I don't think keeping the i18n's in file is a bad thing to do.

The idea of having a file as a "pill" containing all the translations, and such seens much
more tasty than having to distribute separated i18n resources when I publish, say, a color palette on my blog.

Distributors of third party files are welcome to accept downstream contributions to the assets
they create, or license their works in a way to allow for the creation of new versions,
containing more languages.

However, one option does not exclude the other - the use of the localization could be made in a way
to use either built-in translations for colors/metadata or look for them in an external location
if the former way defaults. (then one could have the best of both Worlds)

js -> wrote:

On 02/09/2014 07:55 PM, Alexandre Prokoudine wrote:

Hi,

I'm curious if we have a plan for assets in v2.10 and onwards now that 16/32 bit is possible. Color palettes and gradients are still based on raw 8bit RGB values, and pattern files are 8bit as well.

FilmGIMP/Cinepaint "fixed" that in the past by converting everything to 16bit integer (afaik, integer), but I'm not sure if that's such a good idea.

Some things to consider, in no particular order:

- IMO, ideally, stock color palettes should be using a linear device-independent color space (some sort of LCh?); - it should be possible to use palettes that rely on arbitrary color models (RGB, LAB) to make paint vendors happy; - we still need to solve the i18n issue that was raised recently (non-translatable palettes/colors/etc. names).

In my opinion, a sensible way to approach that would be using an already available, but somewhat forgotten file format devised by Olivier Berten during his work on SwatchBooker:

http://selapa.net/swatchbooker/

To reiterate my earlier email to create@, the benefits of this file format are:

- simple combination of XML + ZIP - (nearly) any color model + optional mapping to an embedded ICC profile - flat colors and gradients supported - spot colors supported
- i18n-ized names of all metadata fields and color names

There is no other file format that would provide the same set of features for us, free or non-free:

http://www.selapa.net/swatches/colors/fileformats.php

So the questions are:

- Is changing the assets file format something we need to do for 2.10 (or maybe at all)?
- Is the SwatchBooker's file format right for us? - do we actually have resources to make the switch?

Opinions?

Yes, that seems necessary.

But I don't like much how i18n is handled in the SwatchBooker format. I don't think the file should contain the names in multiple languages. Most resources distributed outside of Gimp (DeviantArt, etc...) are by isolated authors, and I would not expect their resources to be tagged in more than two or three languages (English plus their native languages). I18N support is done by users, and that would mean making a local version of the file to display the file in the user's language. I would think a single name in the file, remapped using a locale-dependent translation file (one in /usr/share on in the user's profile) would let users rename resources more efficiently. This method could also be used to display localized names for other resources (brushes, patterns...).

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

On 02/10/2014 03:01 PM, Joao S. O. Bueno wrote:

I agree with the file-format,
ad I don't think keeping the i18n's in file is a bad thing to do.

The idea of having a file as a "pill" containing all the translations, and such seens much
more tasty than having to distribute separated i18n resources when I publish, say, a color palette on my blog.

I doubt that you'll ever have all the translations. Do you speak chinese, basque, irish? In my view, the "external" I18N is easier to handle for the standard resources (resources are not modified by translations...) and allows roll-your-own I18N when the author doesn't speak your language.

Distributors of third party files are welcome to accept downstream contributions to the assets
they create, or license their works in a way to allow for the creation of new versions,
containing more languages.

And this quickly becomes a maintenance nightmare :)

However, one option does not exclude the other - the use of the localization could be made in a way
to use either built-in translations for colors/metadata or look for them in an external location
if the former way defaults. (then one could have the best of both Worlds)

Amen to that.

Bringing this topic back, since I think it matters - and more people could be dealing with this than striclty fidling at the core;

On 9 February 2014 16:55, Alexandre Prokoudine wrote:

Hi,

I'm curious if we have a plan for assets in v2.10 and onwards now that 16/32 bit is possible. Color palettes and gradients are still based on raw 8bit RGB values, and pattern files are 8bit as well.

FilmGIMP/Cinepaint "fixed" that in the past by converting everything to 16bit integer (afaik, integer), but I'm not sure if that's such a good idea.

Some things to consider, in no particular order:

- IMO, ideally, stock color palettes should be using a linear device-independent color space (some sort of LCh?); - it should be possible to use palettes that rely on arbitrary color models (RGB, LAB) to make paint vendors happy; - we still need to solve the i18n issue that was raised recently (non-translatable palettes/colors/etc. names).

In my opinion, a sensible way to approach that would be using an already available, but somewhat forgotten file format devised by Olivier Berten during his work on SwatchBooker:

http://selapa.net/swatchbooker/

To reiterate my earlier email to create@, the benefits of this file format are:

- simple combination of XML + ZIP - (nearly) any color model + optional mapping to an embedded ICC profile - flat colors and gradients supported - spot colors supported
- i18n-ized names of all metadata fields and color names

There is no other file format that would provide the same set of features for us, free or non-free:

http://www.selapa.net/swatches/colors/fileformats.php

So the questions are:

- Is changing the assets file format something we need to do for 2.10 (or maybe at all)?
- Is the SwatchBooker's file format right for us? - do we actually have resources to make the switch?

Opinions?

we could start talking more about evolving the format.

I pǘe been talking with some heavy users (for professional use, even) - and one thing they miss is more consistency on asst handling (you can rename a palette or a gradient inline in the gradient list dialog, but not a pattern or a brush, for example).

Alexandre
_______________________________________________

On 20.05.2014 15:59, Joao S. O. Bueno wrote:

I pǘe been talking with some heavy users (for professional use, even) - and one thing they miss is more consistency on asst handling (you can rename a palette or a gradient inline in the gradient list dialog, but not a pattern or a brush, for example).

We got an old bug report about that: https://bugzilla.gnome.org/show_bug.cgi?id=343090

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

On Tue, 2014-05-20 at 10:59 -0300, Joao S. O. Bueno wrote: [...]

I pǘe been talking with some heavy users (for professional use, even) - and one thing they miss is more consistency on asst handling (you can rename a palette or a gradient inline in the gradient list dialog, but not a pattern or a brush, for example).

Yes. I'd love to see "project files" or "project folders" that could contain per-project preferences and resources (brushes, gradients, fonts, images, default export and open folder)...

and the ability to work with multiple active projects!

but that's wanting to dance before we have feet.

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml