Re: [Gimp-developer] assets in the high bith depth age
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 -- On 9 February 2014 18:45, Ofnuts ofn...@laposte.net 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 ___ 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
[Gimp-developer] Feature Request(if wrong way to ask, sorry)
I use Gimp for awhile and I simply love it. But I came to idea to repattern something on a picture (change pattern of walls and floor) but as I found out I would need to create pattern as one huge image with right sizes and then use built-in perspective tool to adjust it. Could you please think about adding something like Perspective pattern tool? You would just select area with right perspective and then select fill this area with... . As I said, if this is wrong way to do feature request or it's already doable I want to apologize myself. I was googling as I could but haven't come to any solution. -- Marek Lukáš ___ 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
[Gimp-developer] Feature Request(if wrong way to ask, sorry)
I use Gimp for awhile and I simply love it. But I came to idea to repattern something on a picture (change pattern of walls and floor) but as I found out I would need to create pattern as one huge image with right sizes and then use built-in perspective tool to adjust it. Could you please think about adding something like Perspective pattern tool? You would just select area with right perspective and then select fill this area with... . As I said, if this is wrong way to do feature request or it's already doable I want to apologize myself. I was googling as I could but haven't come to any solution. -- Marek Lukáš -- Marek Lukáš ___ 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
Re: [Gimp-developer] Gimp on Steam
Personally I'd use the Steam version of Gimp if it were available. Sure, the on-the-fly updates are no problem for a Linux edition of Steam. But on Mac and Windows there's no such auto-updating functionality (due to the drawbacks of the OS) and GIMP rightly does not try to fill that gap. In addition to the auto-updates on Windows, a neat statistic would be how much time I spend in the program. They track other usage statistics but to me that would be the most interesting. Also, Steam allows DRM free packages (i.e. you install via steam but you can take the software out of steam and run it without steam even if steam is not installed or running). So I think no modification would be required from a developers perspective. It would just require the headache of a packager. I'm not sure the Gimp userbase as it stands would much benefit (unless they play PC games and use Steam) but on an average daily basis there's more than 5 million users logged into Steam using the distribution platform. The largest of it's kind. I think it would bring steam to a wider audience with little to no effort in the long run just by simply existing on Steam. I think a good approach might be to wait and see with what Krita does and ask Krita members for feedback on their experience with Steam. If it's positive I see no reason not to do it. ___ 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
Re: [Gimp-developer] Gimp on Steam
On Mon, Feb 10, 2014 at 1:57 PM, Sam Gleske sam.mxra...@gmail.com wrote: Sure, the on-the-fly updates are no problem for a Linux edition of Steam. I meant to say Linux edition of GIMP. ___ 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
Re: [Gimp-developer] Gimp on Steam
On Mon, Feb 10, 2014 at 1:57 PM, Sam Gleske sam.mxra...@gmail.com wrote: ...but on an average daily basis there's more than 5 million users logged into Steam using the distribution platform. The largest of it's kind. I should probably back up with a source for statistics. Luckily, Valve provides Steam stats. http://store.steampowered.com/stats/ ___ 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
Re: [Gimp-developer] Gimp on Steam
El lun, 10-02-2014 a las 13:57 -0500, Sam Gleske escribió: Also, Steam allows DRM free packages (i.e. you install via steam but you can take the software out of steam and run it without steam even if steam is not installed or running). So I think no modification would be required from a developers perspective. It would just require the headache of a packager. Ok, let's see if I can redeem myself after the pointless noise I generated yesterday with a decent question :-) What about the source code? Does the Steam platform provide a way to distribute the sources of GIMP? Does a link to the sources in the description (pointing to gimp.org downloads section) suffice to comply the GPL requirements? Gez. ___ 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
Re: [Gimp-developer] assets in the high bith depth age
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. ___ 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
Re: [Gimp-developer] Feature Request(if wrong way to ask, sorry)
On 02/10/2014 05:01 PM, Marek Lukáš wrote: I use Gimp for awhile and I simply love it. But I came to idea to repattern something on a picture (change pattern of walls and floor) but as I found out I would need to create pattern as one huge image with right sizes and then use built-in perspective tool to adjust it. Could you please think about adding something like Perspective pattern tool? You would just select area with right perspective and then select fill this area with... . As I said, if this is wrong way to do feature request or it's already doable I want to apologize myself. I was googling as I could but haven't come to any solution. Did you try the perspective clone tool in pattern mode? ___ 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
Re: [Gimp-developer] assets in the high bith depth age
On Tue, Feb 11, 2014 at 1:25 AM, Ofnuts wrote: 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. I'm afraid we are arguing over technicalities :) Since swatches and gradients are both handled by a single file format in SwatchBooker, you could just have po-assets/LANG.po that would get the contents of .sbz files, and then another script would write the updated data back into the .sbz files. Or you could carry around .mo files in binary builds. My point is that right now this is not essential. We lived without i18n, and it's something we could decide later. There are ways to deal with this without even breaking the file format. But we cannot exactly live with 8bit raw RGB data in GEGL-based GIMP, and 2.10 is the milestone when this really ought to be solved. So what I'm saying is whether we have a general agreement that a) things have to change; b) SwatchBooker's file format is the way to go. If there's an agreement on a) and b), then it's simply a TODO material: http://wiki.gimp.org/index.php/Hacking:TODO. Which means we would be officially looking for contributors to work on that. Let's make the next step :) Alexandre ___ 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
