Re: [Gimp-developer] Option to save images without embedded ICC profile
Hi, On Wed, 2010-03-03 at 16:33 -0600, Jason Simanek wrote: I understand that color management is complicated and probably not worth completely implementing until Gimp fully employs GEGL, but I think changing the menu so that File Image Mode Assign Color Profile sRGB ACTUALLY applies the selected sRGB color profile to the image and something like File Image Mode Remove Color Profile would discard any color profile associated with the image would be a simple change that would be a huge improvement to Gimp's user interface. It's not that simple though. The assumption that no profile means sRGB is made in many more places. The Image Properties dialog for example will show you sRGB built-in for an image that has no profile attached. The current behavior was proposed and accepted on this mailing-list before color management was added to GIMP. Of course it can be changed now, but such a change needs a complete proposal then that covers all places that are affected by it. The point of the current behavior is that you need to make an assumption if no profile is attached to an image. Otherwise you could not even display this image. Without a color profile or an assumption about the meaning of the RGB values it's just numbers. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
On 03/04/2010 02:14 AM, Sven Neumann wrote: The point of the current behavior is that you need to make an assumption if no profile is attached to an image. Otherwise you could not even display this image. Without a color profile or an assumption about the meaning of the RGB values it's just numbers. It's really unfortunate that the one color space that Gimp actually uses is sRGB, which has a fairly limited gamut (as I understand it). Of course, since it's the default color space of computer displays, sRGB makes perfect historical sense. But if it were instead something like Adobe RGB, Gimp would probably be pretty respectable as long as it color managed the transition from whatever original color space an image was in to the native wide-gamut RGB. And the export would work the same. In that situation the wide-gamut RGB would most likely be able to preserve all/most existing color variations in any image. Sven, thanks for explaining the reality of color management in Gimp. Is somebody on the team already working on this or in this direction? Is there anything a non-programmer can do to contribute to this color management problem? Or is it just a matter of waiting for the developers to move all of Gimp over to GEGL's way of doing things? -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] About the XCF format
So, I was thinking about an interesting matter: why the image viewer softwares doesn´t have support to XCF? Some linux file managers, like Thunar, have the thumbnails support. So what if I want to develop, or help developing, an image viewer, can I implement the XCF format? And if yes, where may I find more info about the format? Is it all in the gimp sources? Or, better, is XCF a gimp format or was it borrowed from some other place? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] About the XCF format
On Thu, Mar 4, 2010 at 6:34 PM, Eduardo Barijan wrote: So, I was thinking about an interesting matter: why the image viewer softwares doesn´t have support to XCF? Some linux file managers, like Thunar, have the thumbnails support. So what if I want to develop, or help developing, an image viewer, can I implement the XCF format? In that very case you will reinvent the wheel :) http://blog.reblochon.org/2009/03/gift-to-competition.html Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
On 03/04/2010 02:13 PM, Jason Simanek wrote: On 03/04/2010 02:14 AM, Sven Neumann wrote: The point of the current behavior is that you need to make an assumption if no profile is attached to an image. Otherwise you could not even display this image. Without a color profile or an assumption about the meaning of the RGB values it's just numbers. It's really unfortunate that the one color space that Gimp actually uses is sRGB, which has a fairly limited gamut (as I understand it). Of course, since it's the default color space of computer displays, sRGB makes perfect historical sense. But if it were instead something like Adobe RGB, Gimp would probably be pretty respectable as long as it color managed the transition from whatever original color space an image was in to the native wide-gamut RGB. And the export would work the same. In that situation the wide-gamut RGB would most likely be able to preserve all/most existing color variations in any image. Sven, thanks for explaining the reality of color management in Gimp. Is somebody on the team already working on this or in this direction? Is there anything a non-programmer can do to contribute to this color management problem? Or is it just a matter of waiting for the developers to move all of Gimp over to GEGL's way of doing things? I am currently working on improving color management in GIMP. If you would like to follow along, CC yourself on https://bugzilla.gnome.org/show_bug.cgi?id=608961 . I need to rev the spec, as I'm working off off a version of it that's a product of what I started with as well as discussions that happened after I originally wrote it. As mentioned, I also discussed the spec here on the mailing list; see the thread GIMP color-management spec and further discussion which I started on 7 Feb 2010. I'm surprised that nobody referred to that spec or that prior discussion before now. Finally, yahvuu created a nice spec for color management UI/UX. IMO, it's too ambitious for the first implementation, and I'd like to get something in that's basic but fully-functional, and covers usecases we don't support right now. So I will be implementing my spec, and once that basic functionality is in place, I'll look more closely at his spec. Among the changes that I plan to make, which are pertinent to what's been discussed so far: - The implicit assumption that untagged images use sRGB will be made explicit Planned changes that aren't part of the spec: - I hope to make more (if not all) of the small previews color-managed - With any luck, I will get the sRGB profiles (2x3kB) included as part of the GIMP distribution, which will allow us to change how options are named — the user will trivially be able to embed an actual sRGB profile in addition to whatever they can do now. If you have questions, let me know --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP distributing sRGB profiles: license issues?
Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles
to the GIMP distribution. They're 3kB each, so size shouldn't be an
issue. The main question is one of licensing. I believe the license
allows us to distribute the profiles, but IANAL.
I'd appreciate if someone who either is a lawyer, or acts in that
capacity for GIMP, could comment. If you have other issues with the
patch, feel free to voice those as well.
The patch is attached, and also lives in bugzilla at:
https://bugzilla.gnome.org/show_bug.cgi?id=608961#c2
--xsdg
From 3c76fe59f903206fed2322371359fe700614663b Mon Sep 17 00:00:00 2001
From: Omari Stephens x...@xsdg.org
Date: Wed, 3 Mar 2010 21:12:40 +
Subject: [PATCH] Add sRGBv2 profiles to the GIMP distribution
Downloaded from http://www.color.org/srgbprofiles.xalter
---
configure.ac |1 +
data/Makefile.am |1 +
data/icc-profiles/COPYING |6 ++
data/icc-profiles/Makefile.am | 10 ++
.../sRGB_IEC61966-2-1_black_scaled.icc | Bin 0 - 3048 bytes
.../sRGB_IEC61966-2-1_no_black_scaling.icc | Bin 0 - 3052 bytes
6 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 data/icc-profiles/COPYING
create mode 100644 data/icc-profiles/Makefile.am
create mode 100644 data/icc-profiles/sRGB_IEC61966-2-1_black_scaled.icc
create mode 100644 data/icc-profiles/sRGB_IEC61966-2-1_no_black_scaling.icc
diff --git a/configure.ac b/configure.ac
index 215b87a..1a78c7c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2079,6 +2079,7 @@ data/brushes/Makefile
data/dynamics/Makefile
data/environ/Makefile
data/gradients/Makefile
+data/icc-profiles/Makefile
data/images/Makefile
data/interpreters/Makefile
data/palettes/Makefile
diff --git a/data/Makefile.am b/data/Makefile.am
index 93b4717..3cbfb39 100644
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -5,6 +5,7 @@ SUBDIRS = \
dynamics \
environ \
gradients \
+ icc-profiles \
images \
interpreters \
palettes \
diff --git a/data/icc-profiles/COPYING b/data/icc-profiles/COPYING
new file mode 100644
index 000..7112a58
--- /dev/null
+++ b/data/icc-profiles/COPYING
@@ -0,0 +1,6 @@
+Source: http://www.color.org/srgbprofiles.xalter
+Date: 3 March 2010
+
+Terms of use
+
+To anyone who acknowledges that the files sRGB_IEC61966-2-1_no_black_scaling.icc and sRGB_IEC61966-2-1_black scaled.icc are provided AS IS WITH NO EXPRESS OR IMPLIED WARRANTY, permission to use, copy and distribute these file for any purpose is hereby granted without fee, provided that the files are not changed including the ICC copyright notice tag, and that the name of ICC shall not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. ICC makes no representations about the suitability of this software for any purpose.
diff --git a/data/icc-profiles/Makefile.am b/data/icc-profiles/Makefile.am
new file mode 100644
index 000..0f716b2
--- /dev/null
+++ b/data/icc-profiles/Makefile.am
@@ -0,0 +1,10 @@
+## Makefile.am for gimp/data/icc-profiles
+
+icc_profilesdatadir = $(gimpdatadir)/icc-profiles
+
+icc_profilesdata_DATA = \
+ COPYING \
+ sRGB_IEC61966-2-1_black_scaled.icc \
+ sRGB_IEC61966-2-1_no_black_scaling.icc
+
+EXTRA_DIST = $(icc_profilesdata_DATA)
diff --git a/data/icc-profiles/sRGB_IEC61966-2-1_black_scaled.icc b/data/icc-profiles/sRGB_IEC61966-2-1_black_scaled.icc
new file mode 100644
index ..71e33830223c4c05c61002462e13df02bb30ae02
GIT binary patch
literal 3048
zcmb_eXIK+i8@)4=UT6uuggYn0*Ley5hDbgd{*H0Ro|k4G|SwQADIEf~*R-;Hnf^
z3nGezMM1Hm8)Q*X*TsSjm7VAh-0%5*?tPw_Irq%_-uK-1{s...@+3e9j6nycoi_rh
z2O}~nnt{Iu5TFhefj-dYa5K`RG555`T4us;M?pbQ_7iqaCy}BI;=IvI|s4H#t)0
zNhy_MA`N06o-`rTVIEs5vOpgr@k...@000Ob3XcZQG)VYG;m_5~MNlKg1-9
zqv...@}+zvpob;oha6iO-jo|@kuE!`ks6F8~!0Tlg~xhBaNawB}dlYmuaV*^-?p
z%_u3...@qiq__~p4%`f|8bdyfV)O6%Q3QZ?hO~ifZ%=zGM|*pwHPea_o6O-RF*3NE
zWa+B^^^l`_ciqo03eHM$uJpi?Y6R80iNKNI(|Qfhy1fdcYVkfi-XdcF?LgT){a
zgn}rr3UEOJNC6^{4f4T8Py|ZAPOt}5gF4U%nm{W!4m!bUa2{L*T4-h0v-Sfm;leg
zGXMQAqc`lREP$tLfVi4WCmG7ENBtr4K0B}peQH?iid=d7|MqK_yTbR1MWbP0+8
zDd;?O1sa0xL1WMq^cwmEBQOP~!w)myz~mw...@`3a^cy;dD3;E`)c$m2d-m6z+h}
z!`I*uSOPzXXAppp5hX+iVInNV6A473kvK$ztV4c3zwy...@rgR6PULYSaI1CNL
zz%Vh+7(yxhhkotztix=_ray`{ixu~ho0u`oh0croiq*ihvv$ss...@wn~g2pr$vcd
z+p!n1BiIS-I~)$Dgfqf9;QVk=xJ29+;-ePTpO+jH-sCEWBPRlFJA1s{m#;4|?
z_$vHS{5kwEeggl2KqhDttO-7ZXo8SXKT)z6V4Kb2~PLL^+}X(TNyHPmd;rNl;J
zH}N`gf;dZ(CmE4kNTH-e(neAxsg-n*G)j6yCX;o^j^tpnfV_cRNj^rtOdcbDq$p5K
zDV~%S6ftE7uIj(a*y(cN~Ic7-Kf#jOzIA56ZHc15%q%%O~yioEyIpFHAaAu}xV
zQkE!dAnPuN;XfnLiU90b=enkL^(q_PdSdI=LFTQ*w9YX5?w|R`P-JDe~Lpo8_;_
zPb%OQ3CZ;cnXCI2Nftjmeub...@+req`$(k{{_=s3Co...@qm(YKq57MU6%=h1
z!xeKBYZT8YN|Xklnxfsvqnwiai!zzpoii~-ie*u+mu_chn3%}sh...@kuuc+ehkv
zKB+QPy;YM`cd2%K2*b~nW_b=WvlI1yQua;ov!YzQi~KdydX1J*Fr2+%haZqDG
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
Omari Stephens wrote: Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles to the GIMP distribution. They're 3kB each, so size shouldn't be an issue. The main question is one of licensing. I believe the license allows us to distribute the profiles, but IANAL. As I mentioned before, the sRGB profile provided in Argyll is public domain. Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On Thu, 2010-03-04 at 19:49 +, Omari Stephens wrote: Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles to the GIMP distribution. They're 3kB each, so size shouldn't be an issue. The main question is one of licensing. I believe the license allows us to distribute the profiles, but IANAL. I'd appreciate if someone who either is a lawyer, or acts in that capacity for GIMP, could comment. If you have other issues with the patch, feel free to voice those as well. I appreciate your work on this, but I am afraid that the license is compatible with the GPL. Aside from that I wonder why GIMP should ship with color profiles at all. There is the icc-profiles package that seems to be available in most Linx distributions nowadays. We should rather continue to depend on that package and make sure that it is included with the Windows installer than installing our own duplicates. The folks from the OpenICC initiative [1] are trying hard to push shared color profiles and color management work-flows. We should really try to cooperate instead of building our own little world. Sven [1] http://lists.freedesktop.org/mailman/listinfo/openicc ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp shouldn´t save if no chang es were made( trivial idea )
Hi, I was advised to post these kind of ideas to developer mailing lists, so here I am. The link to the original post in bugzilla is below: https://bugzilla.gnome.org/show_bug.cgi?id=611765 What do you think of this? Also sorry again Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] remove layer should not force you to last selected layer
Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758 I was advised to present this idea here, what do you think? Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
Once I was used to the behaviour I found it quite useful. If I need to delete a number of consecutive layers, I select the top or bottom one then use the down or up arrow to walk through the layers I want deleted then click the delete button repeatedly. However, even knowing it and leveraging it, I still get caught when I move from one layer to another far away in the stack to delete then find the active layer is way back in the stack. Regarding the comments in the bug report, I can think of at least one time deleting a layer currently leaves no layer selected...when there is only one layer. Not near my machine to check what happens if you select a channel as a drawable then select a layer and delete it. Does it set the channel active? -Rob A On 3/4/10, Luiz Felipe Moraes Pereira felipemorae...@gmail.com wrote: Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758 I was advised to present this idea here, what do you think? Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp shouldn´t save if no chang es were made( trivial idea )
On Thu, 2010-03-04 at 23:14 -0300, Luiz Felipe Moraes Pereira wrote: Hi, I was advised to post these kind of ideas to developer mailing lists, so here I am. The link to the original post in bugzilla is below: https://bugzilla.gnome.org/show_bug.cgi?id=611765 What do you think of this? What if you save to a USB thumb drive, remove the thumb drive, then insert another one? Or what if you accidentally remove the file in the file manager after saving? Several other programs I use have this feature, but I think it's a mistake. You can tell from the * in the title bar whether the image is dirty or not. Liam -- 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 www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp shouldn´t save if no chang es were made( trivial idea )
I see your point...haven´t thought of it, thanks buddy. Now if someone cames with the same idea I can answer accordingly Em Qui, 2010-03-04 às 21:50 -0500, Liam R E Quin escreveu: On Thu, 2010-03-04 at 23:14 -0300, Luiz Felipe Moraes Pereira wrote: Hi, I was advised to post these kind of ideas to developer mailing lists, so here I am. The link to the original post in bugzilla is below: https://bugzilla.gnome.org/show_bug.cgi?id=611765 What do you think of this? What if you save to a USB thumb drive, remove the thumb drive, then insert another one? Or what if you accidentally remove the file in the file manager after saving? Several other programs I use have this feature, but I think it's a mistake. You can tell from the * in the title bar whether the image is dirty or not. Liam ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
On 03/04/2010 05:58 PM, Patrick Horgan wrote: On 03/03/10 11:19, Jason Simanek wrote: That's not true in my experience. Yes, sRGB should be as good as NOT having a profile since sRGB is the ASSUMED color space on most computersy. But Gimp still adds a color profile to the image: an sRGB color profile. This still causes all of the color mismatch problems on websites thoroughly described on the gballard.net site mentioned above. Now I'm confused I thought gballard said the opposite. Here's how it works: 1 Web Browsers That Don't Support Color Management With these browsers images that do or don't include color profiles is irrelevant because they can't do anything with them anyway. The colors are just displayed as whatever RGB color space is available, most likely some form of unmanaged sRGB. 2 Safari (Browsers that ONLY color manage images with color profiles, not colors defined in HTML or CSS) If a color profile is included with an image Safari uses color management to adjust the colors to the computer's display color space. If a color profile is not included it acts like #1. Also, as far as colors defined in HTML and CSS, it acts like #1. 3 Firefox 3.2+/3.5+ by default (Browsers that color manage images with color profiles. Images without color profiles are also managed assuming the sRGB color profile. PLUS: Colors defined in HTML and CSS are managed with assuming the sRGB color profile. What this means for web designers/developers: A #1 isn't a problem unless you want color managed photos that look beautiful on your website. Otherwise, #1 is the way web browsers have generally worked until recently. B #2 is the wrong way to do color management on the web. It's a nice effort and photos certainly look beautiful, but this approach causes big problems for web designers that want to use images for page elements that are intended to exactly match and blend with colors on the web page that are defined in HTML or CSS. This approach forces web developers to NEVER include color profiles on images that are part of a website's design, otherwise the page elements won't match the colors defined in HTML/CSS. At least not in Safari. It'll look perfect everywhere else. C #3 is the right way to do color management. It makes color profiled photographs look as close to the creator's intentions as possible on any computer system that is color managed. But it also allows web designers to use color management to make their page element images look as good as intended while still matching the HTML/CSS colors that are also part of the web page. Thanks to browser type #2 I can only use color profiles on images that are not intended to be a part of the web site's design. If I do include color profiles on those images, every time I bring up the site in Safari it will look like my page elements don't match the flat colors defined in my site's HTML/CSS. So the color mismatch I'm concerned about really only happens in Safari, but mismatches like that are not acceptable. Did that resolve your confusion? Or just add to it? -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On 03/04/2010 09:01 PM, Sven Neumann wrote: On Thu, 2010-03-04 at 19:49 +, Omari Stephens wrote: Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles to the GIMP distribution. They're 3kB each, so size shouldn't be an issue. The main question is one of licensing. I believe the license allows us to distribute the profiles, but IANAL. I'd appreciate if someone who either is a lawyer, or acts in that capacity for GIMP, could comment. If you have other issues with the patch, feel free to voice those as well. I appreciate your work on this, but I am afraid that the license is compatible with the GPL. I presume you meant isn't compatible. Obviously, IANAL but from re-reading the GPL, I believe the case of including a color profile (any color profile) falls under its discussion of aggregates: A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. Aside from that I wonder why GIMP should ship with color profiles at all. There is the icc-profiles package that seems to be available in most Linx distributions nowadays. We should rather continue to depend on that package and make sure that it is included with the Windows installer than installing our own duplicates. My goal in this is only to make sure than an sRGB profile is guaranteed to be available. Depending on the icc-profiles package or any other option (such as using Graeme's profiles) would be perfectly fine, as long as I could assume that an sRGB profile is available (and there is some way to get its pathname). The folks from the OpenICC initiative [1] are trying hard to push shared color profiles and color management work-flows. We should really try to cooperate instead of building our own little world. [1] http://lists.freedesktop.org/mailman/listinfo/openicc I was unaware of this. Again, the goal is to be able to assume that an sRGB profile is available, regardless of how that guarantee is carried out. Finally, to respond to your question on the bug, we need some way to embed an actual sRGB profile into an image. Simply leaving an image untagged or adding some sort of sRGB tick-mark isn't sufficient — there are formats where the color-profile is all you have (TIFF and PDF come to mind), and where it _isn't_ appropriate to assume that every untagged image is sRGB. As one very specific example, I have a print shop (bayphoto.com) whose printers' native color space is AdobeRGB. If you send them an untagged sRGB image, it'll likely end up wrong. And even beyond that, there's the question of whether an sRGB image is sRGBv2 or v4 — the spec openly acknowledges that the two will behave differently in many circumstances. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
