Re: [Gimp-developer] assets in the high bith depth age

[Ofnuts <ofnuts laposte net>]

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...).