Re: [Gimp-developer] GIMP developer meeting
This is happening now in #gimp-development --xsdg Sven Neumann s...@gimp.org escribió: On Mon, 2011-02-28 at 19:38 +0200, Alexia Death wrote: On Mon, Feb 28, 2011 at 7:23 PM, Kevin Cozens ke...@ve3syb.ca wrote: LightningIsMyName wrote: said on IRC that she can't point a domain at that adress so we really should get wiki.gimp.org running or pay for some web server with the GIMP funds. We can discuss this more at todays meeting. I would like to know what the problem is with having wiki.gimp.org. GIMP has its own website so adding a wiki to it should be no problem. Is it a lack of diskspace, lack of someone to set it up, or lack of someone who keep an eye on the wiki and maintain it? Wiki needs an admin that cares, a database and php installed on the server. AFAIK there is no gimp host that meets all those requirements, specially the admin part. Well, the machine that hosts www.gimp.org meets all those requirements. It has database and PHP installed and if anyone volunteers to become the admin that cares, it's no problem to add accounts on the machine. I wouldn't put in the same machine as any part of the main gimp site. Any dynamic site is vulnerable to exploits and hacks. Compromising such a trivial side thing like the wiki should in no way threaten the operation of any of the main sites and integrity of a heavily used and trusted host like gimp.org that could be used to spread malware far and wide. Well, that's a point. But I guess that one could run such a server in a chroot environment or even a virtual host. Sven_ 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
[Gimp-developer] test email; ignore
Making sure that this address works before I send a long email; sorry for the noise --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [PATCH] gimpcairo-utils.h missing parens around some macro arguments
The subject and patch are pretty self-explanatory. Ran into this while
trying to do pointer arithmetic with these macros.
--xsdg
From 0ba4f676e3de80233b7ab184b11e527b61ab6158 Mon Sep 17 00:00:00 2001
From: Omari Stephens x...@xsdg.org
Date: Mon, 24 Jan 2011 18:49:08 +
Subject: [PATCH] Add missing parens around macro arguments
---
libgimpwidgets/gimpcairo-utils.h | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libgimpwidgets/gimpcairo-utils.h b/libgimpwidgets/gimpcairo-utils.h
index 6d614a0..b538c2d 100644
--- a/libgimpwidgets/gimpcairo-utils.h
+++ b/libgimpwidgets/gimpcairo-utils.h
@@ -105,10 +105,10 @@ cairo_surface_t * gimp_cairo_surface_create_from_pixbuf (GdkPixbuf *pixbuf);
const guint tr = (a) * (r) + 0x80; \
const guint tg = (a) * (g) + 0x80; \
const guint tb = (a) * (b) + 0x80; \
-d[0] = (((tb) 8) + (tb)) 8; \
-d[1] = (((tg) 8) + (tg)) 8; \
-d[2] = (((tr) 8) + (tr)) 8; \
-d[3] = (a);\
+(d)[0] = (((tb) 8) + (tb)) 8;\
+(d)[1] = (((tg) 8) + (tg)) 8;\
+(d)[2] = (((tr) 8) + (tr)) 8;\
+(d)[3] = (a); \
} G_STMT_END
#else
#define GIMP_CAIRO_ARGB32_SET_PIXEL(d, r, g, b, a) \
@@ -116,10 +116,10 @@ cairo_surface_t * gimp_cairo_surface_create_from_pixbuf (GdkPixbuf *pixbuf);
const guint tr = (a) * (r) + 0x80; \
const guint tg = (a) * (g) + 0x80; \
const guint tb = (a) * (b) + 0x80; \
-d[0] = (a);\
-d[1] = (((tr) 8) + (tr)) 8; \
-d[2] = (((tg) 8) + (tg)) 8; \
-d[3] = (((tb) 8) + (tb)) 8; \
+(d)[0] = (a); \
+(d)[1] = (((tr) 8) + (tr)) 8;\
+(d)[2] = (((tg) 8) + (tg)) 8;\
+(d)[3] = (((tb) 8) + (tb)) 8;\
} G_STMT_END
#endif
@@ -138,10 +138,10 @@ cairo_surface_t * gimp_cairo_surface_create_from_pixbuf (GdkPixbuf *pixbuf);
#if G_BYTE_ORDER == G_LITTLE_ENDIAN
#define GIMP_CAIRO_ARGB32_GET_PIXEL(s, r, g, b, a) \
G_STMT_START { \
-const guint tb = s[0]; \
-const guint tg = s[1]; \
-const guint tr = s[2]; \
-const guint ta = s[3]; \
+const guint tb = (s)[0]; \
+const guint tg = (s)[1]; \
+const guint tr = (s)[2]; \
+const guint ta = (s)[3]; \
(r) = (tr 8) / (ta + 1);\
(g) = (tg 8) / (ta + 1);\
(b) = (tb 8) / (ta + 1);\
@@ -150,10 +150,10 @@ cairo_surface_t * gimp_cairo_surface_create_from_pixbuf (GdkPixbuf *pixbuf);
#else
#define GIMP_CAIRO_ARGB32_GET_PIXEL(s, r, g, b, a) \
G_STMT_START { \
-const guint ta = s[0]; \
-const guint tr = s[1]; \
-const guint tg = s[2]; \
-const guint tb = s[3]; \
+const guint ta = (s)[0]; \
+const guint tr = (s)[1]; \
+const guint tg = (s)[2]; \
+const guint tb = (s)[3]; \
(r) = (tr 8) / (ta + 1);\
(g) = (tg 8) / (ta + 1);\
(b) = (tb 8) / (ta + 1);\
--
1.7.2.3
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Unsharp Mask and Sharpening
On 12/08/2010 10:35 PM, Jan Smith wrote: Hi, What are the best GIMP tools for sharpening? For sharpening _what_? The steps you would take when sharpening a photo for the web are different than what you'd do when sharpening a photo for print. And there are all sorts of artistic reasons to use various classes of sharpen that aren't related to the physical phenomena which cause a loss of sharpness in photographs shot through lenses. Much like the real world (sharpening a knife or a tool), sharpening isn't some magical term. It's a bunch of techniques, and which you use depends on your input and desired output. You generally wouldn't sharpen a kitchen knife with a file, but you would sharpen a drill bit with one. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] who is interesting in writing java api to gimp
On 05/09/2010 01:02 AM, Hades wrote: Is there anyone who likes writing an java api to gimp?so the J2EE can use the GIMP JAVA API perform graphic I can pretty much tell you now that this isn't going to happen. Googling for java graphics manipulation provides some leads that you might try following instead. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
On 04/21/2010 11:58 AM, Oliver Bandel wrote: Zitat von Tor Lillqvistt...@iki.fi: The test if( template ) makes only sense, if you can be sure that uninitialzed values will definitelky be NULL. You must have missed the g_return_val_if_fail (! template || GIMP_IS_CONTEXT (template), NULL) . It checks if template is NULL or a pointer to a valid GimpContext. If template is some random non-NULL value, the test will fail and a warning message will be printed. Such warning messages indicate a programmer error and should be dealt with during development. [...] Nice to know, but I was talking on things like the *context in that funcion. Even only temporarily valies, if set to a certain value, like 0 or NULL, will help in finding problems. The mentioned function just was an example. Uninitialzed values I see nearly everywhere in the code. Dereferencing NULL is easy to find, because it crashes early. Hi, Oliver Have you programmed with glib before? A lot of defensive programming techniques differ between straight C and C-with-glib. For instance, the guards at the top are common, and (I imagine) gimp_context_copy_properties has similar guards. As such, it's the job of the called function, not the caller, to check if a pointer they want to dereference is NULL. This has the advantage that you don't check a pointer for NULL 10 times across 10 different function calls when you only use it once, all the way at the bottom. Of course, if you actually dereference a value (like the template pointer in the snippet you posted), you should test it before you dereference it. In short, you might want to see what sort of defensive techniques are customary or appropriate for a given context before concluding that we're programming blind. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [PATCH] fix build when objdir and source dir are different
Attached. Seems pretty straightforward.
--xsdg
From 75abc6e31331137c643d09ac4db7b508a4406327 Mon Sep 17 00:00:00 2001
From: Omari Stephens x...@xsdg.org
Date: Thu, 15 Apr 2010 06:56:23 +
Subject: [PATCH] Fix build in case where objdir and srcdir differ
The build currently doesn't work when the build dir is distinct from
the source dir. This small change fixes that and the build completes
successfully.
Example case where this is true:
$ cd gimpsrc/
$ mkdir builddir
$ cd builddir/
$ ../autogen.sh
$ make
In this case, the (cd) on line 168 of the Makefile will do:
cd ../../../plug-ins/pygimp/
At which point calling ${PYGTK_CODEGEN} will fail because of the
argument:
--register ../../../plug-ins/pygimp/gimpcolor-types.def
Because we already cd into that directory, we can get rid of the
extra path specification and we're golden.
---
plug-ins/pygimp/Makefile.am |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/plug-ins/pygimp/Makefile.am b/plug-ins/pygimp/Makefile.am
index 59194bc..f6625e6 100644
--- a/plug-ins/pygimp/Makefile.am
+++ b/plug-ins/pygimp/Makefile.am
@@ -170,8 +170,8 @@ CLEANFILES = gimpui.c gimpthumb.c
--override $*.override \
--register $(PYGTK_DEFSDIR)/gdk-types.defs \
--register $(PYGTK_DEFSDIR)/gtk-types.defs \
- --register $(srcdir)/gimpcolor-types.defs \
- --register $(srcdir)/gimpenums-types.defs \
+ --register ./gimpcolor-types.defs \
+ --register ./gimpenums-types.defs \
--prefix $* $*.defs) gen-$*.c \
cp gen-$*.c $*.c \
rm -f gen-$*.c
--
1.7.0.4
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Why doesn't --enable-debug turn off optimization?
It seems like running configure with --enable-debug should also disable optimization; otherwise you end up with a bunch of magically inlined or optimized-out function calls, optimized-out variables, and confusing execution order. Thoughts? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] incomprehensible behavior with the git version
Try running ldd `which gimp-2.7` on both machines. I would imagine there's a dependency issue. Specifically, I'd wonder about your versions of X11 and GTK --xsdg On 03/31/2010 07:10 AM, Olivier wrote: The problem I encounter is not with the git version, but with my use of it. Explanations: I have two computers, one at work and one at home. Same version of Debian testing (Squeeze), same version of GIMP compiled from git the same day. No problem with the computer at home. On the computer at work, I have at least two very specific problems: Ctrl+mouse scrolling does not zoom at all, and with the Text tool, the temporary control window in the image does not work: if I click on some control, it is as if I would like to write text elsewhere in the window. The scrolling-zooming problem does not occur with GIMP 2.6, it is specific to the git version. I tried re-installing completely Debian testing on the computer at work, with no result. Today I imagined another test: I created another account on the same computer, and checked the two problems above. Both have disappeared. Thus the problem is somewhere in my personal configuration, but where should I search? Do the two problems suggest some idea to anybody? -- Olivier Lecarme ___ 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] wiki down...
On 03/22/2010 12:44 PM, peter sikking wrote: ehm guys, gui.gimp.org is down, or rather, serving up perfectly empty pages. It's an experiment in minimalism. How does the blank page make you _feel_? --xsdg ___ 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/13/2010 02:41 PM, yahvuu wrote: Graeme Gill wrote: The bottom line is that it depends on your purpose. If you have a particular reason to specify device dependent colors, then you deliberately don't want to tag the file with a profile. This case worries me a bit. Hope you can enlighten me what the best practices are. In a way, it is paradoxical that the files which, among all files, depend the most on color profiles, are the files which do not get profiles embedded. If such device dependent files end up anywhere but in the printer spooler's temporary directory, i see that as an invitation for trouble. Great fun for the collegue who gets assigned to print those ten images i tailored for three different printers -- and now i have to leave in a hurry... On the other hand, it seems ridiculously wasteful to embed a printer's profile into a file which gets send to that very printer anyway. Referencing an URL seems a good solution here. This probably also holds true for the case, where images get optimized for a photo finisher who provides regularily updated profiles of his minilab. But how to avoid the overhead when such files are to be archieved? After all, URLs tend to throw 404s after a while. Just rely on the compression feature of the backup software? I think the answer is easy: provide a way to strip the color profile. If a person is specifically targeting a situation where a color profile is a bad thing, they strip it, et voila. Otherwise, everything has a color profile, unless it lacked one when it was imported. And seriously, 3kB for a profile is peanuts for most images. If you know you are trying to squeeze the size of your images, you get rid of the color profile. Otherwise, the image is probably going to end up north of 50 or 100kB anyway, at which point again, 3kB is peanuts. Let's not overthink this. This isn't to say that a web export functionality wouldn't be useful. Just that thinking about in the context of this discussion will probably turn into wasted cycles. --xsdg ___ 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
z...@6x;(^oT1vr6-V_j
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
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
On 02/28/2010 02:43 PM, lloyd konneker wrote:
::snip? SNIP!::
Here is proposed addition for plug-ins/gimpmodule.c in pygimp_main()
that I have lightly tested. Note it raises a warning (Python prints
warning on stderr once, on the second call), not an exception. Note it
compiles with a C90 warning about mixing declarations and code.
Just move the variable declaration to the top of the function. We
should strive to make the codebase compile with as few meaningful
warnings as possible.
Also, is that proper code style?
--xsdg
if (query == Py_None) {
PyErr_SetString(pygimp_error, a query procedure must be
provided);
return NULL;
}
/* lkk 2010 begin enhancement*/
static int was_called_previously = 0;
if (was_called_previously) {
PyErr_WarnEx(PyExc_RuntimeWarning, main() should only be called
once, 1);
Py_INCREF(Py_None);
return Py_None;
}
else {
/* OK to set this here since following code either succeeds in
initializing plugin, or fails hard. */
was_called_previously = 1;
}
/* lkk 2010 end enhancement*/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 04:55 PM, yahvuu wrote: Hi, here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png I believe number 1 is incorrect: All images in GIMP will have a color profile. This will either be the implicit sRGB profile, or some explicit profile. Similarly, in the case where the monitor has no explicit display profile, we send it RGB on the assumption that it mostly conforms to sRGB. More specifically, that means that everywhere we display an image will be color-managed, even if that image isn't explicitly tagged with a profile. Color-related tools (the color picker comes to mind) should always function relative to the color profile of the image, be it explicit or implicit. This may spell some interesting changes for Curves and Levels down the line; I'm not sure. For 2, an image that, when imported, does not have any explicit color profile information will be exported without saving any explicit color profile information (unless an explicit color profile was added). I also do not understand why 2a and 2b are separated. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 05:36 PM, Martin Nordholts wrote: On 02/12/2010 06:27 PM, Omari Stephens wrote: On 02/12/2010 04:55 PM, yahvuu wrote: Hi, here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png I believe number 1 is incorrect: All images in GIMP will have a color profile. People will want to create unmanaged images without a color profile for use on the web for example, so we need to handle images with no color profile attached. I think introducing the conepts of implicit profiles adds unnecessary complexity. If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a display profile and opens an image-without-profile, what do we display? We can't apply the display profile unless the image has some source color profile to link to the transform. Hence, we assume sRGB to enable this and other situations to behave as correctly as possible. The sRGB assumption is one what we already make, this change will simply make that assumption a bit more explicit. In doing so, it allows us to stop special-casing for cases where the image may not have a color profile. We gain uniformity of display logic and a decrease in code complexity by being able to assume the presence of a color profile as an invariant. And the code itself is trivial: just add a give_me_color_profile function which returns icc-profile contents if present, or the sRGB profile otherwise. (with a more-reasonable name, of course). --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 10:12 PM, Christopher Curtis wrote: On Fri, Feb 12, 2010 at 11:55 AM, yahvuuyah...@gmail.com wrote: here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does monitor profile take this into account? I think my question is: Is X handling the colorspace or are profiles being applied on individual pixel regions? Is this even supported or is there something else I'm not understanding at a very basic level? This is an uncommon usecase that would require too much effort to support properly for the small amount of benefit. X11 has an atom which stores one ICC display profile per screen. We would have to change the display transform depending on which screen each pixel shows up on. This would also mean that we'd have to deal with the case where an image tile is split across two screens. Again, this would be a lot of code (and, thus, the potential for a lot of bugs). It would be infrequently used (and so the bugs would tend to not be found as quickly). And it would likely slow down our common code paths for little benefit. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
I had composed a response, and then shortly before sending, WIFI on my laptop conked out. I think yahvuu covered most of what I was going to say, though. I'll send it anyway when I pull the laptop out again. --xsdg On 02/10/2010 07:09 PM, yahvuu wrote: Martin Nordholts wrote: On 02/07/2010 04:55 AM, Omari Stephens wrote: 1) When an image is opened with no associated color profile, we assume that it is encoded in sRGB space. I don't think we should assume that, do you have an example use case where that is a good idea? I think the best guess is sRGB, assuming a file that was produced by a legacy device. Which were (back then) to be viewed on monitors with a profile similar to sRGB. Another source for images of these kind are web developers who want to achieve consistent colors cross a web page -- the rationale beeing: if the browser has no color profile information, the colors may be wrong, but at least consistent. Among garden-variety photo labs, it's pretty much standard to discard any color profile information and just assume sRGB. I think we should rather assume the image is in the working space color space. The user's choice of a working space does not reveal any information about an unknown image. I don't think the chosen working space should be used as input for import heuristics. My thinking is that it is the same working space color profile that is used for the GIMP color picker and also for images without a color profile attached. So when you pick RGB 128,128,128 in the GIMP color picker and open an image with no color profile, RGB 128, 128, 128 in the image will be displayed the same as RGB 128,128,128 in the GIMP color picker. OK, the color picker's colors must match, of course. Probably that means that the color picker can't show any numbers as long it's not yet clear which color space it will be assigned to. Or, perhaps better: the color picker gets disabled when no image is open. But the same problem still occurs when switching between images with different working color spaces. The very same color may have different RGB values in different color spaces. Assuming a calibrated monitor, the color picker displays absolute colors, so i think the RGB values should change, not the colors. regards, yahvuu ___ 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 color-management spec and further discussion
NOTE: if someone wants to think about the UI/UX involved in the color
management spec, I would really appreciate it. Right now, I have no
time for thinking outside the box — it's all I can do to find 30 minutes
here and there to do some GIMP hacking as it is. So if you don't want
to see more options at the bottom of the Color Management
configuration pane, your help would be appreciated.
(more comments inline)
On 02/07/2010 12:36 PM, yahvuu wrote:
Hi all,
Omari Stephens wrote:
Hi, all
I wrote up a quick spec for how GIMP should deal with color profiles
associated with files and images. The spec is attached, and is also
attached to bug 608961. If you have any general thoughts/comments, I
would love to hear them, but please note the scope of the document.
Please don't forget to incorporate EXIF data into the show:
https://bugzilla.gnome.org/show_bug.cgi?id=492048
For quite some time, users will have to deal with incompatible and
especially simply incomplete implementations of color management.
Possibly that pain [1] can be eased if users are supported to specify
workarounds, like: 'camera xy' + 'filename starts with _' = AdobeRGB.
Sort of heuristic device drivers.
I specifically chose to ignore that problem for now, as I think it's
more difficult to deal with than the generic has embedded ICC profile
or not? problem. I should probably have mentioned that in the spec
(what is out of the scope of this spec or somesuch).
For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
This means that even if we know it _should_ be AdobeRGB, the user will
need to take some action either to make that profile available or to tag
it manually.
Secondly, we currently use libexif for parsing EXIF in JPEG. We need to
switch to exiv2, but since the latter is C++, we'll need a C/C++
compatibility layer as well. A further problem is that we don't
currently support EXIF in PNG, which we should (and would be able to
with exiv2).
In short, I would consider make EXIF work right a mostly-orthogonal
problem to make color management work right. They're both important,
but the color management problem is the one that I'm focusing on right now.
PS: I think the scope of your questions is actually more of UX. As you said,
the pure technical solution is to popup when inference fails.
True. Unfortunately, guiguru doesn't seem to have been around in any
real capacity of late, so I think I'm going to have to start off by
adding functionality in ways that work but are non-ideal, and then we
can refine it later on.
[1] an example of how it took 5 days to track down the
import problems for some Pentax cameras:
https://lists.xcf.berkeley.edu/lists/gimp-user/2010-January/016415.html
Hmm. matching the filename against /_...[0-9]{4}\.jpg/i is one
potential heuristic to suggest (this image should be AdobeRGB), but I'm
not sure it would be worth the effort — if someone has a bunch of
untagged (as opposed to EXIF-tagged) AdobeRGB images, then they've got a
problem in their workflow.
--xsdg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
On 02/08/2010 01:39 AM, Graeme Gill wrote: Omari Stephens wrote: Obviously, options for both of these things are prompt the user. It seems like there should be better alternatives, but I'm not sure what they might be. guiguru? others? You're better having a set of defaults that the user can configure, so they aren't constantly hassled by prompts. The configuration can have options such as prompt me for certain combinations. Yes. By prompt the user I meant something similar to the current behavior when an image is tagged with a color profile other than the working space profile; the options are: 1) Do nothing 2) Convert to working space profile 3) Prompt the user I was hoping someone would come up with a better convention, but since that doesn't seem to be happening, I will rev the spec and mention this UX paradigm explicitly, with the hope that it will be improved upon in a later revision. Author: Omari Stephensx...@xsdg.org Version: 1 Date:3 February 2010 1) When an image is opened with no associated color profile, we assume that it is encoded in sRGB space. c) Convert the image from the implicit profile to some explicit profile (AdobeRGB, ProPhotoRGB, sRGB, etc.) Not a good idea. There are losses in every color conversion. Ideally you want to keep an image in its original format, unless the user explicitly decides to convert to another colorspace. Input is not the place to do this. So the application (GIMP) should have a transformation step available to: 1) Convert from one colorspace to another. If an image has no tag, then both profiles would need to be specified. 2) Assign a profile to the image. This would set or override a tag. One idea to consider is the possibility of a weak color tag. This is for a image that is to be considered un-tagged, but has a profile to specify the source colorspace for the purposes of display, and conversion. Your weak color tag is exactly what I meant by an implicit sRGB profile. My judgment was that it wouldn't be useful to have a weak tag that wasn't sRGB — anything else should be explicit and embedded. There should be a color tag status somewhere for an image. Because the only implicit color tag is sRGB, the absence of an icc-profile parasite (or an empty one) can be considered equivalent to the implicit sRGB tag. 4) When an image with an explicit profile is exported a) It will be tagged with that profile in whatever way is appropriate for the file format. b) If this is an sRGB PNG, we need to decide between an sRGB chunk and sRGB profile. See later discussion. c) If the file format has no way to embed color profile information, (FIXME!) For c), have the option to covert to a particular colorspace (ie. sRGB). Cool. Any thoughts from other people? d) Have an option to write the file without an embedded profile. This is an important option in regard to dealing with other applications, for instance sending calibration or profiling files to a particular device. I was thinking a tiny bit about this, but hadn't come up with anything conclusive. I'll probably implement something trivial where you can select a menu item to dump the icc-profile. 5) When an image with an implicit profile is exported a) The image is saved with no color profile information. For PNG, this means no sRGB chunk and also no iCCP chunk. You could really have the same options as 4, although you might default them differently. Hmm; good point. Will think about that. There are many possible ways of dealing with this issue. The important things as I see them are 1) Allow defaulting to logical and useful workflows 2) Allow flexibility to accommodate particular needs. Yup. Thanks for thinking about this. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP color-management spec and further discussion
Hi, all I wrote up a quick spec for how GIMP should deal with color profiles associated with files and images. The spec is attached, and is also attached to bug 608961. If you have any general thoughts/comments, I would love to hear them, but please note the scope of the document. My main questions so far: 1) What should we do when exporting to formats that don't support color profile tagging? One option is obviously to convert to sRGB. Are there people who are familiar with formats like this? What is the standard thing to do? What do people usually use these formats for? 2) What should we do when an opened image contains an invalid profile? Obviously, options for both of these things are prompt the user. It seems like there should be better alternatives, but I'm not sure what they might be. guiguru? others? --xsdg [1] https://bugzilla.gnome.org/show_bug.cgi?id=608961 Author: Omari Stephens x...@xsdg.org Version: 1 Date:3 February 2010 This spec is intended to define GIMP's color profile management behavior as pertains to the opening and exporting of image files. How this is achieved or implemented, and especially the UI and UX considerations involved, is not currently in the scope of this spec. Further discussion will happen on the mailing list: gimp-developer@lists.xcf.berkeley.edu 1) When an image is opened with no associated color profile, we assume that it is encoded in sRGB space. In practice, I'll say that it has an implicit sRGB profile. The user will have the following options: a) Assert (aka apply) some explicit color profile b) Leave the image without an explicit color profile c) Convert the image from the implicit profile to some explicit profile (AdobeRGB, ProPhotoRGB, sRGB, etc.) 2) When an image is opened _with_ an associated color profile, the user will have the following options: a) Leave the image with the explicit color profile b) Convert the image to some other explicit profile 3) When a PNG is opened that is tagged with the sRGB chunk a) This is as-yet undecided. See the later discussion about sRGB chunk vs. sRGB profile. 4) When an image with an explicit profile is exported a) It will be tagged with that profile in whatever way is appropriate for the file format. b) If this is an sRGB PNG, we need to decide between an sRGB chunk and sRGB profile. See later discussion. c) If the file format has no way to embed color profile information, (FIXME!) 5) When an image with an implicit profile is exported a) The image is saved with no color profile information. For PNG, this means no sRGB chunk and also no iCCP chunk. PNG: sRGB chunk vs. sRGB profile In theory, an untagged PNG and a PNG with the sRGB chunk should be treated identically. In practice, and particularly among web browsers, this is not the case. See [1]. Given this context, we face the question of what to do when we have the choice to use either an sRGB chunk or an sRGB profile in the iCCP chunk. In theory, these two choices should have the same outcome. However, it is not clear whether theory matches reality in this case either; I have very little data to judge either way. [1] Making the Color Spaces Match section of http://hsivonen.iki.fi/png-gamma/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image dimension(s) instead of pixel dimensions (Image Properties)
On 02/04/2010 02:42 PM, Cristian Secară wrote: In the dialog windows that opens on Image - Image Properties the first item is Pixel dimensions:. In my opinion this is incorrect (it sounds like it were about the dimensions of a physical pixel). I think it should be Image dimensions, or Image size, or something like that. I think that Pixel dimensions is fine as it is. It is compact, and it is very clear in the context in which it appears, that is, followed by (yyy) x (zzz) pixels. I don't think anybody familiar with image editing in any sense will think that it's referring to the shape of a single pixel. Any options that don't mention Pixel in the name will likely leave someone wondering how they can see other kinds of sizes there. Dimension in pixels is nice, but is longer with little real benefit. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Minimal color management strategy for GIMP 2.8
On 01/24/2010 07:26 AM, Omari Stephens wrote: On 01/23/2010 08:04 AM, Martin Nordholts wrote: Hi Right now we don't have a clearly defined color management strategy for GIMP. I would like us to settle a minimal color management strategy for GIMP so that we can fix some inconsistencies in our color management, in particular for PNG [1], for 2.8. In short the problem with PNG is that the current code always writes an sRGB chunk to a PNG file if no color profile is attached to the image and no gamma is specified. I suggest that we formally settle with this minimal color management strategy: An image either has or has not a color profile attached. A color profile is attached as a GimpParasite named icc-profile. For images that have a color profile attached, this color profile is used when displaying the image and is embedded when the image is saved or exported. For images that does not have a color profile attached, the global color profile defined under Color Management in Preferences is used to display the image, but no profile is embedded into saved or exported files. So, does the above sound like a sound foundation for color management in GIMP? I don't expect us to have time to apply this strategy consistently all over GIMP for 2.8 but at least we have settled on something that we can put in devel-docs and continue to build on later, and it allows us to fix the PNG problem for 2.8. Sounds eminently reasonable; I had run into this issue also. FWIW, http://hsivonen.iki.fi/png-gamma/ seems like a pretty good article on this topic; curious folks should give it a read. It also suggests that the current GIMP behavior is Bad. I had naively signed up for the work on color management job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o) It was actually trivial to find. Right now, I'm just considering the consequences before I nuke that 4 lines of code. I had also been taking a peek at [2] and [3], which also seem to fall under the umbrella of this desired behavior. Finally, [4] is something that bites me a lot, but needs some UI/UX work. guiguru? These will probably be more than 4 lines of code ;o) [2] https://bugzilla.gnome.org/show_bug.cgi?id=556608 Monitor color profile is not applied to filter preview [3] https://bugzilla.gnome.org/show_bug.cgi?id=478528 Layer previews are not color managed [4] https://bugzilla.gnome.org/show_bug.cgi?id=320447 fast switching between 'color managed display' and 'softproof' --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Minimal color management strategy for GIMP 2.8
On 01/24/2010 08:31 AM, Martin Nordholts wrote: Omari Stephens wrote: I had naively signed up for the work on color management job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o) It was actually trivial to find. Right now, I'm just considering the consequences before I nuke that 4 lines of code. You are talking about http://git.gnome.org/browse/gimp/tree/plug-ins/common/file-png.c#n1456 right? Nuking those four lines is not enough, a way to embedd an sRGB profile must also be added. Unfortunately, assagning an sRGB profile to an image in current GIMP does not stick since sRGB is the default color space. We need to change this. Changing this is likely to cause problems in other parts of the color managed code which needs to be taken care of. Any licensing folks about? Debian's icc-profiles package ships an sRGB profile that has license [1]. The ICC itself also provides sRGB v2 and v4 ICC profiles for use with licenses [2] and [3], respectively. Can we ship one of these with GIMP? At the very least, the PNG spec calls for IEC 61966-2-1, which is one of the sRGB v2 profiles, though both the BPC-enabled and BPC-disabled versions seem to count as 61966-2-1. Also, from a practical standpoint, are there important situations where someone would want to tag a PNG as sRGB, but where simply applying the actual sRGB color profile wouldn't be a reasonable substitute to the sRGB PNG chunk? The PNG standard has this to say (from http://www.w3.org/TR/PNG/#11sRGB ): It is recommended that a PNG encoder that writes the sRGB chunk also write a gAMA chunk (and optionally a cHRM chunk) for compatibility with decoders that do not use the sRGB chunk. Only the following values shall be used. […] When the sRGB chunk is present, it is recommended that decoders that recognize it and are capable of colour management [ICC] ignore the gAMA and cHRM chunks and use the sRGB chunk instead. Decoders that recognize the sRGB chunk but are not capable of colour management [ICC] are recommended to ignore the gAMA and cHRM chunks, and use the values given above as if they had appeared in gAMA and cHRM chunks. It is recommended that the sRGB and iCCP chunks do not both appear in a PNG datastream. Here are the licenses: [1] HP sRGB license, from Debian's icc-profiles package: sRGB Profile Licensing Agreement: To anyone who acknowledges that the file sRGB Color Space Profile.icm is provided AS IS WITH NO EXPRESS OR IMPLIED WARRANTY: permission to use, copy and distribute this file for any purpose is hereby granted without fee, provided that the file is not changed including the HP copyright notice tag, and that the name of Hewlett-Packard Company not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Hewlett-Packard Company makes no representations about the suitability of this software for any purpose. [2] ICC sRGBv2 license, from http://www.color.org/srgbprofiles.xalter 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. [3] ICC sRGBv4 license, from http://www.color.org/srgbprofiles.xalter To anyone who acknowledges that the file sRGB_v4_ICC_preference.icc is provided AS IS WITH NO EXPRESS OR IMPLIED WARRANTY, permission to use, copy and distribute this file for any purpose is hereby granted without fee, provided that the file is 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. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Minimal color management strategy for GIMP 2.8
On 01/24/2010 09:03 AM, Omari Stephens wrote: On 01/24/2010 08:31 AM, Martin Nordholts wrote: Omari Stephens wrote: I had naively signed up for the work on color management job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o) It was actually trivial to find. Right now, I'm just considering the consequences before I nuke that 4 lines of code. You are talking about http://git.gnome.org/browse/gimp/tree/plug-ins/common/file-png.c#n1456 right? Nuking those four lines is not enough, a way to embedd an sRGB profile must also be added. Unfortunately, assagning an sRGB profile to an image in current GIMP does not stick since sRGB is the default color space. We need to change this. Changing this is likely to cause problems in other parts of the color managed code which needs to be taken care of. Any licensing folks about? Debian's icc-profiles package ships an sRGB profile that has license [1]. The ICC itself also provides sRGB v2 and v4 ICC profiles for use with licenses [2] and [3], respectively. Can we ship one of these with GIMP? At the very least, the PNG spec calls for IEC 61966-2-1, which is one of the sRGB v2 profiles, though both the BPC-enabled and BPC-disabled versions seem to count as 61966-2-1. Also, from a practical standpoint, are there important situations where someone would want to tag a PNG as sRGB, but where simply applying the actual sRGB color profile wouldn't be a reasonable substitute to the sRGB PNG chunk? ::snip? SNIP!:: After a bit more thinking, it occurs to me that it makes no sense for us to not have a a copy of the working-space color profile, if we want to consider the image tagged with that profile. Consider the following: 1) Suppose we consider the image not to be associated with _any_ profile. We use our default working-space profile because that's why it's there. When we export an image, it should not be tagged as associated with any color profile. 2) Suppose we consider the image to be associated with our working-space profile. When we export an image, it should be tagged with our working-space profile. If what we export is a JPG or a TIFF, they have no equivalent to PNG's sRGB chunk — we need to have a copy of the actual sRGB profile on hand so that we can apply it to the exported file. For exporting to PNG here, if our working-space is sRGB v2, we have the option of applying the color profile or adding the PNG sRGB chunk. According to the standard, these should be equivalent. Whether this is the case in practice is something I'm unsure about. 3) If the user tags the image with some color profile from her filesystem, then we cache that profile in the icc-profile parasite. We use the parasite to tag the image when we export it. 4) If the user opens an image that is already tagged with some profile, the profile is already in the icc-profile parasite. We use the parasite to tag the image when we next export it. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Minimal color management strategy for GIMP 2.8
On 01/24/2010 08:29 PM, Hal V. Engel wrote: On Sunday 24 January 2010 01:35:20 am Omari Stephens wrote: ::snip? SNIP!:: After a bit more thinking, it occurs to me that it makes no sense for us to not have a a copy of the working-space color profile, if we want to consider the image tagged with that profile. Consider the following: 1) Suppose we consider the image not to be associated with _any_ profile. We use our default working-space profile because that's why it's there. When we export an image, it should not be tagged as associated with any color profile. This does not seem correct to me. How do you know that the working space profile is correct for this image? If you are assuming that all users will have sRGB as their working space this assumption will fail for at least some subset of users. For example it is common for photographers to use wider gamut color spaces such as ProPhotoRGB or BetaRGB as their working color space. Using one of these color spaces for viewing untagged images is definitely not correct. The general guidance from CM experts is that if you are going to make assumptions about what color space should be used with an untagged RGB image then it should be sRGB. But for the general case you should also allow the user to specify how they want this to be handled. Most users will just let you do the default handling of untagged images (IE. use sRGB) but other users may want to be asked what should be done for each image or to setup some other default behavior like always using some other (IE. not sRGB) profile. Good catch. Your suggestion is indeed what I had intended. It means that every image is tagged with a profile. It seems the easy way to implement this would be to just assume that empty icc-profile parasite == image implicitly tagged with sRGB. An image with only an implicit sRGB tag is exported without any color profile or tag attached. If it's PNG, it is exported with neither an sRGB chunk nor an iCCP chunk. As always, the user may assert (aka apply) some color profile for the image, or may convert the image to some color profile, in which case the starting profile will be whatever lives in icc-profile, be it the implicit sRGB profile or some explicit thing. Furthermore, the user may chose to have GIMP prompt them as to what to do, with options being (1) assert some color profile (2) leave untagged, in which case we implicitly use sRGB, (3) convert from an implicit sRGB to some explicit profile, like AdobeRGB or ProPhotoRGB. 2) Suppose we consider the image to be associated with our working-space profile. When we export an image, it should be tagged with our working-space profile. If what we export is a JPG or a TIFF, they have no equivalent to PNG's sRGB chunk — we need to have a copy of the actual sRGB profile on hand so that we can apply it to the exported file. Again it appears that you are assuming that sRGB will always be the users working space profile. This is not a valid assumption. This was more an argument for we need to have sRGB profiles on-hand than anything. If our working space is anything other than sRGB v2, we're guaranteed to have a file somewhere. We've only been lazy with sRGB v2 because lcms has the profile built in somewhere. For exporting to PNG here, if our working-space is sRGB v2, we have the option of applying the color profile or adding the PNG sRGB chunk. According to the standard, these should be equivalent. Whether this is the case in practice is something I'm unsure about. PNG appears to be a special case where the specification states that any untagged image is sRGB by default. So it appears the PNG needs to be handled in a different way than JPG, TIF .. files. Since the specification is clear about this there is not need to assume how this should be handled. If the PNG image is not tagged it is sRGB. From the reading I've done, there is a practical difference between PNG-with-sRGB-chunk and untagged-PNG: According to the CSS2 specification, the CSS color values refer to the sRGB color space. In practice, however, all browsers except Mac IE 5 with ColorSync enabled (disabled by default) seem to just treat the CSS color values as values in whatever color space the system color space happens to be. Still, it would be reasonable to expect the colors of an sRGB-labeled PNG image to be treated consistently with CSS colors. (from http://hsivonen.iki.fi/png-gamma/) We need to enable the practical use of GIMP, and as such, we need to differentiate between untagged and tagged-with-sRGB-chunk. This is why GIMP's current behavior of always-tagging, while correct in theory, is incorrect in practice. My question was essentially whether we _also_ need to differentiate between PNG-tagged-with-sRGB-chunk and PNG-with-sRGBv2-color-profile. In theory, the two options are equivalent. In practice, though, this may not actually be the case. --xsdg
Re: [Gimp-developer] Minimal color management strategy for GIMP 2.8
On 01/23/2010 08:04 AM, Martin Nordholts wrote: Hi Right now we don't have a clearly defined color management strategy for GIMP. I would like us to settle a minimal color management strategy for GIMP so that we can fix some inconsistencies in our color management, in particular for PNG [1], for 2.8. In short the problem with PNG is that the current code always writes an sRGB chunk to a PNG file if no color profile is attached to the image and no gamma is specified. I suggest that we formally settle with this minimal color management strategy: An image either has or has not a color profile attached. A color profile is attached as a GimpParasite named icc-profile. For images that have a color profile attached, this color profile is used when displaying the image and is embedded when the image is saved or exported. For images that does not have a color profile attached, the global color profile defined under Color Management in Preferences is used to display the image, but no profile is embedded into saved or exported files. So, does the above sound like a sound foundation for color management in GIMP? I don't expect us to have time to apply this strategy consistently all over GIMP for 2.8 but at least we have settled on something that we can put in devel-docs and continue to build on later, and it allows us to fix the PNG problem for 2.8. Sounds eminently reasonable; I had run into this issue also. I had naively signed up for the work on color management job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o) I had also been taking a peek at [2] and [3], which also seem to fall under the umbrella of this desired behavior. Finally, [4] is something that bites me a lot, but needs some UI/UX work. guiguru? [2] https://bugzilla.gnome.org/show_bug.cgi?id=556608 Monitor color profile is not applied to filter preview [3] https://bugzilla.gnome.org/show_bug.cgi?id=478528 Layer previews are not color managed [4] https://bugzilla.gnome.org/show_bug.cgi?id=320447 fast switching between 'color managed display' and 'softproof' --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Just a reminder of 48 bit color support
On 12/31/2009 10:57 AM, Sven Neumann wrote: ::snip? SNIP!:: You are free to start working on it today. GEGL needs more contributors and there is also a lot that can be done in GIMP today working towards the goal of better GEGL integration. As the GEGL website is down, is there somewhere folks can look to see what sorts of things need to be done, and (perhaps) what skillsets are required? If not, what can interested folks do to figure out how they can get involved and contribute? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP T-shirts in our online store
Guillermo Espertino wrote: Ismael: I don't know the official position about this, but I think that the Wilber image you used looks pretty dated. I'd use the Tango version or the icon for Mac that Jimmac designed. They look much better and as far as I could see, the Tango version is being used for GIMP since 2.4 http://macin.files.wordpress.com/2008/09/gimp-icon-512x512.png http://jimmac.musichall.cz/images/blog/gimp-mac.png Gradients are hard and expensive to do on T-shirts. Most t-shirts are screen printed, which means that distinct colors are layed down one at a time. Usually, there is no blending. Additionally, because colors are added one-at-a-time, adding colors directly increases the production time and cost of the shirt. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + Export proposal
photoco...@gmail.com wrote: ::snip? SNIP!:: As you may see the idea is not to replace the Export dialog, but to offer a handy option from the Save dialog, to simultaneously export , with same name and in the same directory in other file formats Wouldn't this be fairly straightforward to do as a plugin/python-fu/script-fu? Adding code makes things slower. If this isn't something that would benefit the vast majority of GIMP users (and I'm not sure it would), it seems better to offer it as an option for those who want it, rather than to add extra code for the users who won't touch it. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Martin Nordholts wrote: Hi, We are making pretty good progress towards GIMP 2.8 which has turned into an everything but GEGL release. I think it would make sense to also go for a single-window mode in 2.8 and not 2.10 as originally planned. ::snip? SNIP!:: Hi, all. I might be daft, but what exactly _is_ a single-window mode. It feels like I'm the odd one out, here, and that everyone else knows what's going on, but I can't really imagine that's the case. What window are we talking about? The phrase single-window mode really means absolutely nothing to me. Can someone draw a simple mock-up to make it clear? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
Sven Neumann wrote: Hi, On Fri, 2009-07-24 at 11:48 +0200, gg wrote: I added a comment to a png image and pressed Save. I was averted to the fact it failed by the fact it was too quick (a fairly large file). On repeating the save to see what happened I caught a glimpse of a subliminally fast message at the bottom off the screen. I repeated again to have time to read it. Basically it told me it was not saving because there were no changes. That's simply a bug then. Changing an image parasite should mark it as dirty. Please file a bug-report for this. As gg was trying to point out, I think there is a more fundamental problem here with how GIMP reports feedback. A message that is subliminally fast is no message at all. At the very least, a message to the user should be visible for at least long enough for it to be read in its entirety (or the user should be able to go somewhere to read the message in its entirety). I just discovered that when I import an image from a Nikon raw file, the Export to menu item shows up as Export to 300_1234.NEF. Of course, this is bogus, because GIMP doesn't have a NEF export plugin. Even worse, though, is that when I click the menu item, _there is no feedback_. As gg mentioned, the real problem here is not that GIMP does not do what you tell it to, but rather that it ignores your command and _doesn't tell you that it did_. More specifically, once I hit Ctrl+E and see the status message not saying anything about exporting, I expect the file to have been saved. If GIMP thinks there were no changes, it should say no changes to save in a way that is visible, easy to notice, and easy to read. If GIMP failed to save because there's no actual export plugin for the default export filename, it should say that too. Just playing the silent game is not an option. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Export spec should be augmented to handle an important usecase
UI powers that be: any ideas/status on this? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] The Export spec should be augmented to handle an important usecase
The spec is here: http://gui.gimp.org/index.php/Save_%2B_export_specification#exporting_files Quick version: The default export path needs a settings switch for whether the original file path (number 3) is higher-priority than the most-recently-used paths (numbers 1 and 2). This would support the use-case where input and output files are associated by directory, but you may open multiple input files at once. Detailed version: My photo-storage hierarchy looks like .../photos/(date)/(filenames). Whenever I modify an image, I save it to .../photos/(date)/pp/(original filename) — pp means post-processed Now, I open two images in gimp from different dates using my image viewer. I edit them, and then try to save them. The first one works fine. When I go to save the second file, however, I end up (by default) in a directory associated with the first file. Furthermore, because I was in the image viewer (and not the command line), I often have _no idea_ what the directory is that I now need to manually navigate to. In the case where I open a couple (=3) images in a row from different directories, this means that I have to re-find the images in the image viewer, mentally remember the directory names, then manually navigate to the appropriate directories in the export dialog. Suffice it to say, this is more of a roadblock than a workflow. On the other hand, there are other situations where I want all the photos to end up in one place. For instance, when I post-process photos for a blog post, they will all end up in .../photos/pblog/(year-month)/(post title)/ . Thus, it seems like both ways of handling this default ([1, 2, 3] priority as well as [3, 1, 2] priority) are viable and useful. This is why I suggest having a setting to switch between the behaviors. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Genetic Python plugin - faster draw and fill
Freddy wrote: Alec Burgess (bura...@gmail.com) wrote (in part) (on 2009-06-19 at 05:45): Have you considered ImageMagik? I'm not well-qualified at either scripting Gimp nor anything but simplest tasks in ImageMagik (just lurk on the IM-list) but the tasks you describe *might* be possible in it and possibly somewhat quicker? Thanks, ImageMagick looks interesting, I guess I could use it for my project. But I found several similar projects that are stand-alone, online Flash-based or JavaScript. I want to try something new, and so far nobody made a script or plugin for GIMP / Photoshop or any other image editing software that uses genetic algorithms to approximate an image. At least I could not find any. If I dont get it to work with GIMP, ImageMagick will be the next thing I am going to try. You might want to look at Inkscape. Polygon manipulation is more of a vector than a raster process, and Inkscape already has useful functionality that you can likely build off of. For instance, potrace (which is built into Inkscape), could save you a lot of trouble in implementing a quantitative, deterministic fitness measure (which you could subsequently fiddle with, of course). While gimp might tell you whether pixels are close, a traced image may be better able to tell you if the _shapes_ are close. http://www.inkscape.org/doc/tracing/tutorial-tracing.html --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
kevin wrote: I have been using GIMP for a few months now and there is a feature that I have wanted to have and think about every time I open up GIMP. The feature is mainly for the possibility of having templates. The idea is that you can place a layer that is a link to a certain image, so you can have 9 layers on top of each other and each one being an image. The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. To give an example, let's say you have a template with different images being buttons, menus and background/foreground. You have a window open with all the different linked layers positioned to be how you want it on your site or final look. Now, when you change one of the images, you can see what the result will look like from looking at the window with the template. Benefit being speed ( you don't have to look for the file or any of the tedious crap ) and ease which are two things I like to think GIMP excels over all competitors with. TBH, this sounds more like a vector editing feature than a raster editing feature. Have you tried inkscape? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Robert Krawitz wrote: From: Christian i...@zwahlendesign.ch Date: Sun, 31 May 2009 17:53:43 +0200 Hi Michael The HSL is one of the best color models. The colors are symmetrical ordered. Advantages 1. symmetrical 2. color values are not rounded (you have more colors than in the HEX model) 3. logical (no senselessly black axis) 4. equidistant colors in the color picker 5. the right color theory. In the middle is the neutral gray [1] Bad's in the HSV color picker 1. not symmetrical 2. color values are rounded (in HEX a base color can have only a value of 0 - 255) 3. not logical (a senselessly black axis) 4. not equidistant colors in the color picker, you can click too many colors in the black area. 5. the color circle is correct but in the middle is not the neutral gray. I favor HSL also, and it's what we use in Gutenprint to perform correction (actually, we perform parts of it in HL+G, but that amounts to the same thing). I also added HSL decomposition to GIMP several years ago, and find it very useful -- a simple manipulation of the L curve can have a dramatic and predictable effect on the image. L conforms much more closely to perception than V, which is a major advantage when lightening or darkening an image -- in HSV space, there's no simple way to do that. The representation certainly seems useful. My major concern is that, as a photographer, saturation in HSL doesn't seem to usefully map to what we typically call saturation (hereafter, psaturation) — if I'm talking about a psaturated red sunset, a mostly-white sky with a touch of red isn't what I'm describing. Put another way, a photographer's sense of psaturation is well-represented by saturation in HSV. In HSL, the concept of psaturation is split across both saturation _and_ lightness — a color which is psaturated tends to have both high HSL saturation and neutral lightness. Note, however, that the HSV and HSL saturation would align to a useful extent if HSL coordinates were defined in terms of a cylinder, but the color space were actually shaped like a double-cone (see [1]). Or really, if it were any shape with single points at full-lightness (white) and zero-lightness (black), and with a circle/hexagon at neutral lightness. In that case, a color could only be described as fully saturated when it has neutral lightness. Colors that are between neutral lightness and extreme lightness have gradations of saturation, and the saturation is bounded such that it must decrease as you approach one extreme or the other (of lightness). Of course, when you do that, computations become harder. *sigh* I'll send out a mockup of what I mean shortly. [1] http://en.wikipedia.org/wiki/File:HSL_HSV_cylinder_color_solid_comparison.png --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Omari Stephens wrote: Robert Krawitz wrote: From: Christian i...@zwahlendesign.ch Date: Sun, 31 May 2009 17:53:43 +0200 Hi Michael The HSL is one of the best color models. The colors are symmetrical ordered. Advantages 1. symmetrical 2. color values are not rounded (you have more colors than in the HEX model) 3. logical (no senselessly black axis) 4. equidistant colors in the color picker 5. the right color theory. In the middle is the neutral gray [1] Bad's in the HSV color picker 1. not symmetrical 2. color values are rounded (in HEX a base color can have only a value of 0 - 255) 3. not logical (a senselessly black axis) 4. not equidistant colors in the color picker, you can click too many colors in the black area. 5. the color circle is correct but in the middle is not the neutral gray. I favor HSL also, and it's what we use in Gutenprint to perform correction (actually, we perform parts of it in HL+G, but that amounts to the same thing). I also added HSL decomposition to GIMP several years ago, and find it very useful -- a simple manipulation of the L curve can have a dramatic and predictable effect on the image. L conforms much more closely to perception than V, which is a major advantage when lightening or darkening an image -- in HSV space, there's no simple way to do that. The representation certainly seems useful. My major concern is that, as a photographer, saturation in HSL doesn't seem to usefully map to what we typically call saturation (hereafter, psaturation) — if I'm talking about a psaturated red sunset, a mostly-white sky with a touch of red isn't what I'm describing. Put another way, a photographer's sense of psaturation is well-represented by saturation in HSV. In HSL, the concept of psaturation is split across both saturation _and_ lightness — a color which is psaturated tends to have both high HSL saturation and neutral lightness. Note, however, that the HSV and HSL saturation would align to a useful extent if HSL coordinates were defined in terms of a cylinder, but the color space were actually shaped like a double-cone (see [1]). Or really, if it were any shape with single points at full-lightness (white) and zero-lightness (black), and with a circle/hexagon at neutral lightness. In that case, a color could only be described as fully saturated when it has neutral lightness. Colors that are between neutral lightness and extreme lightness have gradations of saturation, and the saturation is bounded such that it must decrease as you approach one extreme or the other (of lightness). Of course, when you do that, computations become harder. *sigh* I'll send out a mockup of what I mean shortly. Mockup is here: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/hsl-doublecone.png Note that when I mention HSL below, I mean HSL with its traditional coordinate system, as depicted in [1]. Also note that this is a quick transformation away from the RGB color cube, [2], so many nice properties of RGB are shared by this representation. The lightness axis is just one of the major diagonals of the cube. I think this is a good representation for a couple reasons: - It retains the advantages of HSL over HSV (primarily, the symmetry and the ability to move from a color with a certain psaturation to the equivalent gray). - It retains the photographer's sense of psaturation as its concept of saturation - Unlike both HSV and HSL, it compresses the volumes that are mostly-white and mostly-black. This matches RGB's compression of those same volumes (see [2]), which is nice, assuming that images will be stored in RGBA of some bit depth. This also makes sense in terms of the colors that humans can perceive — we can more-easily perceive differences in highly-saturated colors than we can differences in mostly-white swatches with a hint of color. Also, given that our brains correct for white-balance continuously, the difference between shades of white becomes even less important. And given that our cones hardly work in the dark, the difference between shades of black becomes even less important. - Similarly to the previous point, this representation matches our perception well. Consider any two points in this representation, in HSV, in HSL, and in RGB. This representation and RGB are the only ones where the length of that path MUST correspond to the ease with which we can differentiate between the two colors at the endpoints of the path. That is, the magnitude of a segment corresponds naturally to important aspects of our visual system. - It creates a bijection (a one-to-one mapping) between valid coordinates and points in the color space. Put differently, there is no coordinate change you can make that will leave you at the same color. This property holds for RGB as well, but not for HSV or HSL (in HSL
Re: [Gimp-developer] HSL Color Picker
Hal V. Engel wrote: On Sunday 31 May 2009 01:56:25 pm Omari Stephens wrote: his also makes sense in terms of the colors that humans can perceive — we can more-easily perceive differences in highly-saturated colors than we can differences in mostly-white swatches with a hint of color. This is not correct. Humans are much more sensitive to differences in color near the neutral axis (IE. grays) then in colors that are highly saturated. Oops; I think this was a half-developed thought, and now I'm having trouble defining it well enough to put into words. Oh well. Thanks for the correction. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Robert Krawitz wrote: Date: Sun, 31 May 2009 20:56:25 + From: Omari Stephens x...@csail.mit.edu Omari Stephens wrote: Mockup is here: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/hsl-doublecone.png Note that when I mention HSL below, I mean HSL with its traditional coordinate system, as depicted in [1]. Also note that this is a quick transformation away from the RGB color cube, [2], so many nice properties of RGB are shared by this representation. The lightness axis is just one of the major diagonals of the cube. The lightness axis is indeed the major diagonal between black and white, but the rest of the transformation isn't particularly easy. The circle at the join of the cones represents the other 6 vertices of the cube and the 6 edges connecting them, but that doesn't seem like a simple transformation. Oh, yeah, it's not trivial to well-define the transformation, for sure. But geometrically, in a sort of hand-wavy manner, it's not a radical transformation — colors don't move too far away from their former neighbors. - Similarly to the previous point, this representation matches our perception well. Consider any two points in this representation, in HSV, in HSL, and in RGB. This representation and RGB are the only ones where the length of that path MUST correspond to the ease with which we can differentiate between the two colors at the endpoints of the path. That is, the magnitude of a segment corresponds naturally to important aspects of our visual system. Agreed. Of course, there are always drawbacks: - This requires more computation to use because of the odd shape of the space of valid coordinates. That is, not all valid coordinates are valid colors. What I don't like about this is that it leaves a large fraction (well over half) of the color space unused and functionally meaningless. I agree that this representation is more accurate, but functionally it seems more difficult to work with. Think about the UI implications. Yes, it does leave large parts of the _coordinate_ space invalid. Admittedly, I've primarily been thinking of this as being useful for an RGB color picker, and less as a real color space in its own right. Also, yes, the UI would be tricky. Of course, we have other places where a constrained relationship needs some UI love (the image scale dialog, for instance). Of course, the real question is probably what orthogonal vectors can we use to precisely span this space such that the meanings of the vectors are also useful? If there's a good solution to that problem, then the UI is easy. - HSL and HSV are in wide use, and this is neither HSL nor HSV (though it's just a coordinate transformation away from both HSL and RGB) It's a simple coordinate transformation from HSL: H' = H S' = S * (1 - ((|L - .5|) * 2)) L' = L but it's not any simpler than RGB-HSL. True, I think I misspoke by saying and RGB Operationally, I suspect a problem with this is that transformations in this space that increase saturation will tend to amplify chroma noise (which is more prominent in dark areas) more than transformations in HSL space. In principle, this isn't true, but in practice I suspect it will be. As far as using this space as a color space, it all depends on where you put the bits, right? I believe this suspicion is false when considering a transformation at L=0.5 (that is, this space will undoubtedly have at least as much bit density on that circle as HSL does). In the other cases, I think it depends on what you consider to be saturation. If you mean the S in HSL, then yes, you're correct. I would question the utility of a purely-S increase, though — what would someone be trying to achieve by doing that? Certainly, it doesn't seem like an operation a photographer would undertake very often. The photographer would likely increase saturation while making lightness more neutral (to use my prior terminology, they would want to create a color that is more or less psaturated). I think this space has a lot in common with the HLK space Gutenprint uses for its HL transformations (for additive colors HLW would be used). HLK is computed as follows: K = min(C, M, Y) C' = C - K M' = M - K Y' = Y - K (H, L) = HSL(C', M', Y') Note that S is always 1 in this case, so it's ignored. I'm not sure what S transforms in this space would be. H transforms are the same as in HSL space, but L transforms that are based on hue yield better results (you don't want L transforms where L' = fn(H, L) to operate on the gray component). Also note that for K close to 0 or 1 there's a limit on the value of L similar to your S'. I need to do some more thinking to wrap my head around all this :o) --xsdg ___ Gimp-developer mailing
Re: [Gimp-developer] Shifting rotation grid with center of rotation: need help/feedback
gg wrote: Omari Stephens wrote: Hi, all I'm working on a patch which shifts the rotation grid so that a grid intersection always falls on the center of rotation. The simple use-case for this functionality is when doing a corrective rotation in a photo with a clear horizontal or vertical object. Maintaining an intersection on the center of rotation means that you'd _always_ be able to stick the center of rotation on one end of the straight object, align a gridline along the object, and be done. Currently, this is not always easily doable without futzing with the number of gridlines. My current rough-draft patch (against r28237) is up at: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/shift_rotate_grid.v2.patch.txt At the moment I have a few questions: 1) Let C be the coords for center of rotation, and TC be the coords for the transformed center of rotation. At times, it seems like TC is up-to-date and C lags (such as when dragging the center of rotation with the mouse). But other times, C is up-to-date and TC lags (for instance, when adjusting one of C's coords with the spinbox in the dialog). This makes it incredibly difficult to make the offset always correct. I think this happens because gimp_transform_tool_grid_recalc() and gimp_transform_tool_transform_bounding_box() need to be called in differnet orders depending on where the canonical center of rotation coords are stored (C or TC). When you update the spinbox, the gimp_transform_tool_motion() callback calls gimp_rotate_tool_motion() (which sets C from the values in the spinbox), and then gimp_transform_tool_recalc(), calls ..._grid_recalc() and then ..._transform_bounding_box(). So, in this case, TC will be stale at the point when ..._grid_recalc() is called (since TC is updated from C in ..._transform_bounding_box()). When you move the center of rotation by dragging it with the mouse, however, it seems that sometimes ..._transform_bounding_box() is called without an accompanying ..._grid_recalc() call, which means that C is stale but TC is up-to-date. In particular, when this happens, C is temporarily set to the center of the image, which I find incredibly confusing. I'm not sure how or why this happens. Any suggestions for how should I fix this behavior so that it's correct in either case? 2) I want to only enable shifting when we're doing rotation (as opposed to shearing or scaling, for instance). This is as easy as clamping x_off and y_off to zero in gimp_transform_tool_grid_recalc(). From that function, how do I determine if the transformation is a rotation? 3) The bounding box is drawn in a different function. I would like to avoid splitting the shift logic across functions (or duplicating it in both). Any suggestions on how to keep the bounding-box aligned with the grid (including the shift offset), but still allow the bounding box to work when the grid isn't being calculated? 4) Any other questions, suggestions, or feedback? Thanks, --xsdg Hi, I looked at this centre shift issue a year or so ago. You may be able to find it the archive. I found accumulated errors were leading to the image tracking around a central point. IIRC some improvement was made by someone else at that time but since these base transformations will soon be migrated to gegl it was deemed not worth improving the existing code base in this area. I suggest you dig out that thread before investing too much effort. Do you know more specifically when it happened or what the thread might have been called? I have (local) archives back to Feb, 2008 and didn't see anything pertinent-looking that you had sent. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Shifting rotation grid with center of rotation: need help/feedback
Hi, all I'm working on a patch which shifts the rotation grid so that a grid intersection always falls on the center of rotation. The simple use-case for this functionality is when doing a corrective rotation in a photo with a clear horizontal or vertical object. Maintaining an intersection on the center of rotation means that you'd _always_ be able to stick the center of rotation on one end of the straight object, align a gridline along the object, and be done. Currently, this is not always easily doable without futzing with the number of gridlines. My current rough-draft patch (against r28237) is up at: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/shift_rotate_grid.v2.patch.txt At the moment I have a few questions: 1) Let C be the coords for center of rotation, and TC be the coords for the transformed center of rotation. At times, it seems like TC is up-to-date and C lags (such as when dragging the center of rotation with the mouse). But other times, C is up-to-date and TC lags (for instance, when adjusting one of C's coords with the spinbox in the dialog). This makes it incredibly difficult to make the offset always correct. I think this happens because gimp_transform_tool_grid_recalc() and gimp_transform_tool_transform_bounding_box() need to be called in differnet orders depending on where the canonical center of rotation coords are stored (C or TC). When you update the spinbox, the gimp_transform_tool_motion() callback calls gimp_rotate_tool_motion() (which sets C from the values in the spinbox), and then gimp_transform_tool_recalc(), calls ..._grid_recalc() and then ..._transform_bounding_box(). So, in this case, TC will be stale at the point when ..._grid_recalc() is called (since TC is updated from C in ..._transform_bounding_box()). When you move the center of rotation by dragging it with the mouse, however, it seems that sometimes ..._transform_bounding_box() is called without an accompanying ..._grid_recalc() call, which means that C is stale but TC is up-to-date. In particular, when this happens, C is temporarily set to the center of the image, which I find incredibly confusing. I'm not sure how or why this happens. Any suggestions for how should I fix this behavior so that it's correct in either case? 2) I want to only enable shifting when we're doing rotation (as opposed to shearing or scaling, for instance). This is as easy as clamping x_off and y_off to zero in gimp_transform_tool_grid_recalc(). From that function, how do I determine if the transformation is a rotation? 3) The bounding box is drawn in a different function. I would like to avoid splitting the shift logic across functions (or duplicating it in both). Any suggestions on how to keep the bounding-box aligned with the grid (including the shift offset), but still allow the bounding box to work when the grid isn't being calculated? 4) Any other questions, suggestions, or feedback? Thanks, --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A Photographers View of Gimp 2.6
Stephen DeLear wrote: ::snip? SNIP!:: First off, just to be clear, what OS are you on? The vast majority of gimp users are Linux/some-form-of-UNIX users, so that tends to be what we (or, at least, I) assume. The issues you're facing sound like you might be using a less-tested configuration, though. Locate Center Point: Reviewing a 22MP image a 100% means navigating an image with an equivalent size of several feet. What would be nice is some way to mark the exact center of the image, where the central AF point fell, so that it can be quickly navigated to at 100%. Click and drag on the move icon in the lower-right corner of the image window. Scale to File Size: Many stock sites require an image to be upsized. For example Alamy requires an uncompressed file size of 48megs from a file saved as a 8bit .JPG. It would be useful to be able to set in an uncompressed file size and have the GIMP resize to be exactly that size. This seems incredibly silly and naive. First of, as JPEG is a lossless format, different images will end up at different pixel sizes to reach the same file size. I mean, if you've got a low-key image that's predominantly black (or some other image that JPEG works well on), you'd have to make the thing enormous to hit that. Secondly, upsampling the image doesn't increase the amount of information in the image, so you're essentially just wasting disk space for no gain. If there were a minimum pixel size, I could see upsampling the image to meet that. A minimum file size, though? No way. Are you sure they want you to upsample the image to meet the file size requirement? Are you sure it's not just the case that they want images from a medium-format digital back or something like that? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Duplicate Visible
Sven Neumann wrote: Hi, On Wed, 2008-08-06 at 11:31 -0700, vabijou2 wrote: ::snip? SNIP!:: As far as real estate on the bottom of the layers dialog goes, I would eliminate the raise/lower layer buttons I don't ever use them since it is easier to drag the layer itself to the new location than to select the layer with one mouse click and then find and click on the raise/lower button. I often use the up/down buttons. Clicking a button is much easier than doing drag and drop. We would need to do some user observations to decide this. Without such data I'd vote for keeping the buttons. To add a single data point, I always use the buttons and never use DND for layer ordering. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF data missing after jpg save
Sven Neumann wrote: Hi, On Thu, 2008-06-05 at 07:25 -0400, Paka wrote: the opensuse team that is maintaining gimp/ufraw does not believe that exif data is important to the project and do not include support for exif. Easy enough to copy the plug-in binary from a compatible distribution that compiles GIMP with Exif support enabled. Are you all following a red herring? I think Jim said, in his response to my email, that the EXIF data always exists after the JPEG has been saved from the GIMP. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF data missing after jpg save
Jim Sabatke wrote: Bill Skaggs wrote: Jim Sabatke [EMAIL PROTECTED] wrote: It seems that in 2.4.6 that exif data are missing when saving as a compressed jpg. They are not missing on jpgs with no compression. There is no such thing as a jpg with no compression, so it is pretty much impossible to make sense of what you are saying. It would be helpful if you would describe the actions you took and the error messages you received in a more concrete way. What were the settings you used when saving as jpg? What were the messages that told you whether or not exif data is present? -- Bill OK, I'm processing Nikon D200 NEF (RAW) photos with gimp and ufraw. ufraw shows the exif data properly. When I edit the photo in gimp and go to save with the standard settings, the exif data do not show up on my pbase website. This is a new behavior as exif data have always shown up before. I looked at the help on the pbase site and it said most of the problems saving exif data come from high compression. So, I re-edited a photo and saved it. On the the Save as JPEG screen Save EXEF data was checked. On the Subsampling: drop box, I selected 1x1,1x1,1x1 (best quality). Then I saved and the exif data showed on my pbase photo. I was mistaken that I changed the compression. It was still at 85. Is the EXIF data not visible in the first case with a tool designed specifically for that purpose, such as metacam? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC2008] deadline extension
Zhang Junbo wrote: Is today April 1 ? On Mon Mar 31 08:43:55 PDT 2008, Alexandre Prokoudine salexandre.prokoudine at gmail.com wrote: Hi, Deadline for student applications submission is officially extended by one week. The new deadline for student applications is Monday, April 7, 2008. Timeline in FAQ is updated. Alexandre (first, please don't top-post) I presume you're asking if it's a joke that the deadline was extended. I'm very confident that it is not -- the deadline was extended last year as well (though only by a weekend rather than by an entire week) --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC2008] deadline extension
http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/9fa88f31aa401f70 --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Synchronization of GSoC responses
Sven Neumann wrote: Hi, This is unavoidable on a mailing-list. Not everyone receives the mails at the same time and there is no way you can know if anyone else has already responded to the mail. I can see how that would be the case if the responses were temporally close to each other. However, the receipt times at bc2.EECS.Berkeley.EDU for Rafael's message and the three responses were: Rafael Mesquita: Tue, 18 Mar 2008 16:01:58 -0700 (PDT) Bill Skaggs: Tue, 18 Mar 2008 21:32:51 -0700 (PDT) Sven Neumann: Wed, 19 Mar 2008 00:19:23 -0700 (PDT) Ingo Luetkebohle: Wed, 19 Mar 2008 02:45:31 -0700 (PDT) If you're saying you didn't get Bill's message before responding, then so be it (though I might offer that your email is sort of broken; ignore this quip if you choose to receive daily batches of gimp-developer mail). What I imagine happened, however, is that people read Rafael's message and responded immediately rather than first reading the responses that had already been sent, and only subsequently sending a response. I realize that it's hard to both be lazy and read through an entire thread before responding, but I feel that we should at least be able to put forth the extra effort when trying to convince students to spend their time improving The Gimp rather than going to a more organized project. And, seriously. If multiple hours of delay isn't enough time for at least the majority of respondents to get on the same page, then we should probably have one person acting as a liaison between the folks on gimp-developer and inquiring students. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
