Re: [Gimp-developer] What Would It Take To Add Native Dialogs?
There has been some work on native file-chooser dialogs recently in GTK+, the UI toolkit GIMP uses. https://blogs.gnome.org/alexl/2015/11/05/native-file-choosers-in-gtk/ On 22 December 2015 at 03:55, john smith wrote: > The GTK Open/Save Dialogs look really odd on a Windows system. > > What would it take to put an if statement in the code that checks for the > OS and delegates to the Win API if it was a Windows system? > https://msdn.microsoft.com/en-us/library/bb776913%28v=VS.85%29.aspx > > It looks like there is already platform specific builds > https://git.gnome.org/browse/gimp/tree/build/windows > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] xdg-app; was: WGO Transition Meeting
On 17 November 2015 at 18:42, Michael Natterer wrote: > On Tue, 2015-11-17 at 11:17 +0300, Alexandre Prokoudine wrote: > > On Tue, Nov 17, 2015 at 11:07 AM, Sam Gleske wrote: > > We need a *relocatable* build, but it doesn't need to be static. > > - build all deps into a prefix > - enable relocation on all of them where needed/possible > - provide a launcher script > - tar up the install prefix > - ... > - profit > We do this in imgflo, which is based on GEGL. There is no GTK+ though, and would need to build more dependencies to be fully distro-independent*. https://github.com/jonnor/imgflo-dependencies/blob/master/Makefile https://github.com/jonnor/imgflo-dependencies/blob/master/env.sh.in This also includes headers, including some trickery to make pkg-config relocatable, so can also be used for developing. If someone was to make a relocatable GIMP build, please consider the same, then people can also develop just by downloading a single bundle. By building a git checkout of GIMP/GEGL/BABL against the bundled prefix and then installing into it, one could also develop core things this way (not just plugins). https://github.com/jonnor/imgflo/blob/master/Makefile#L66 https://github.com/jonnor/imgflo/blob/master/Makefile#L55 * it can be quite tricky to avoid host dependencies leaking into the build, and quite a lot of work to build absolutely everything needed (down to or including glibc). So it is practical to use something that provides some isolation and some ready-made recipies - like Docker, makechrootpkg (from Arch), or similar. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] segmentation fault in 2.9 at start
On 23 January 2015 at 22:42, Jon Nordby wrote: > Hi Alexander, > this is https://bugzilla.gnome.org/show_bug.cgi?id=743296 > A workaround is mentioned there. > > It has been hard to reproduce this issue. Let me give it another go > tomorrow, otherwise I'll disable the json handling until issue is resolved. > > This bug should now have been fixed. Let us know if the issue persists after pulling GEGL master and rebuilding. commit 08c4063702aaecbb9b777706e7b469a3b171b877 Author: Jon Nordby Date: Sat Jan 24 13:45:39 2015 -0500 meta-json: Force module to be persistent Hopefully fixes segfault in some cases where libgegl/executable does not link json-glib, and the shared lib which GType database referred to was unloaded. https://bugzilla.gnome.org/show_bug.cgi?id=743296 > On 23 January 2015 at 12:32, Alexander Rabtchevich < > alexander.v.rabtchev...@gmx.net> wrote: > >> Hello >> >> I have a problem with the current git master - it does not start. Linux >> Mint 17 64. >> >> Starting program: /opt/bin/gimp-2.9 >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> [New Thread 0x7fffe9465700 (LWP 24613)] >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x7368cc56 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >> (gdb) bt >> #0 0x7368cc56 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >> #1 0x7408ffc9 in g_str_equal () >>from /lib/x86_64-linux-gnu/libglib-2.0.so.0 >> #2 0x7408f5f0 in g_hash_table_lookup () >>from /lib/x86_64-linux-gnu/libglib-2.0.so.0 >> #3 0x740af7c0 in g_intern_static_string () >>from /lib/x86_64-linux-gnu/libglib-2.0.so.0 >> #4 0x7fffe8a50d30 in json_object_get_type () >>from /usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 >> #5 0x7fffe8a52083 in ?? () >>from /usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 >> #6 0x7438d56e in g_type_class_ref () >>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #7 0x74376159 in g_object_newv () >>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #8 0x743768bc in g_object_new () >>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #9 0x7fffeaa09878 in json_op_register_type_for_file ( >> filepath=0xc92ee0 "/opt/lib/gegl-0.3/grey2.json", >> type_module=0xc2feb0) >> at json.c:525 >> #10 load_file (file_data=file_data@entry=0x7fffdbd0, >> user_data=user_data@entry=0xc2feb0) at json.c:552 >> #11 0x750e3def in gegl_datafiles_read_directories ( >> ---Type to continue, or q to quit--- >> path_str=, flags=G_FILE_TEST_EXISTS, >> loader_func=0x7fffeaa09830 , user_data=0xc2feb0) >> at gegldatafiles.c:214 >> #12 0x740bc6b8 in g_slist_foreach () >>from /lib/x86_64-linux-gnu/libglib-2.0.so.0 >> #13 0x7fffeaa09aa3 in json_register_operations (module=0xc2feb0) >> at json.c:565 >> #14 gegl_module_register (module=0xc2feb0) at json.c:589 >> #15 0x750e46b4 in gegl_module_load (module=0xc2feb0) >> at geglmodule.c:160 >> #16 0x743930a1 in g_type_module_use () >>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #17 0x74393129 in ?? () >>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #18 0x7438b9aa in ?? () >>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #19 0x7438d157 in g_type_class_ref () >>from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #20 0x750f0daf in add_operations (parent=) >> at gegl-operations.c:82 >> #21 add_operations (parent=) at gegl-operations.c:84 >> #22 0x750f1225 in gegl_operation_gtype_from_name ( >> name=0x79ba0b "gegl:alien-map") at gegl-operations.c:218 >> ---Type to continue, or q to quit--- >> #23 0x750f1259 in gegl_has_operation ( >> operation_type=operation_type@entry=0x79ba0b "gegl:alien-map") >> at gegl-operations.c:231 >> #24 0x00489348 in sanity_check_gegl_ops () at sanity.c:570 >> #25 sanity_check () at sanity.c:84 >> #26 0x00487f82 in main (argc=, argv=0xbafb90) >> at main.c:447 >> >> >> With respect, >> Alexander Rabtchevich >> ___ >> gimp-developer-list mailing list >> List address:gimp-developer-list@gnome.org >> List membership: >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> List archives: https://mail.gnome.org/archives/gimp-developer-list >> > > > > -- > Jon Nordby - www.jonnor.com > -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] segmentation fault in 2.9 at start
Hi Alexander, this is https://bugzilla.gnome.org/show_bug.cgi?id=743296 A workaround is mentioned there. It has been hard to reproduce this issue. Let me give it another go tomorrow, otherwise I'll disable the json handling until issue is resolved. On 23 January 2015 at 12:32, Alexander Rabtchevich < alexander.v.rabtchev...@gmx.net> wrote: > Hello > > I have a problem with the current git master - it does not start. Linux > Mint 17 64. > > Starting program: /opt/bin/gimp-2.9 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [New Thread 0x7fffe9465700 (LWP 24613)] > > Program received signal SIGSEGV, Segmentation fault. > 0x7368cc56 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt > #0 0x7368cc56 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x7408ffc9 in g_str_equal () >from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x7408f5f0 in g_hash_table_lookup () >from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #3 0x740af7c0 in g_intern_static_string () >from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #4 0x7fffe8a50d30 in json_object_get_type () >from /usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 > #5 0x7fffe8a52083 in ?? () >from /usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 > #6 0x7438d56e in g_type_class_ref () >from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #7 0x74376159 in g_object_newv () >from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #8 0x743768bc in g_object_new () >from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #9 0x7fffeaa09878 in json_op_register_type_for_file ( > filepath=0xc92ee0 "/opt/lib/gegl-0.3/grey2.json", > type_module=0xc2feb0) > at json.c:525 > #10 load_file (file_data=file_data@entry=0x7fffdbd0, > user_data=user_data@entry=0xc2feb0) at json.c:552 > #11 0x750e3def in gegl_datafiles_read_directories ( > ---Type to continue, or q to quit--- > path_str=, flags=G_FILE_TEST_EXISTS, > loader_func=0x7fffeaa09830 , user_data=0xc2feb0) > at gegldatafiles.c:214 > #12 0x740bc6b8 in g_slist_foreach () >from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #13 0x7fffeaa09aa3 in json_register_operations (module=0xc2feb0) > at json.c:565 > #14 gegl_module_register (module=0xc2feb0) at json.c:589 > #15 0x750e46b4 in gegl_module_load (module=0xc2feb0) > at geglmodule.c:160 > #16 0x743930a1 in g_type_module_use () >from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #17 0x74393129 in ?? () >from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #18 0x7438b9aa in ?? () >from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #19 0x7438d157 in g_type_class_ref () >from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #20 0x750f0daf in add_operations (parent=) > at gegl-operations.c:82 > #21 add_operations (parent=) at gegl-operations.c:84 > #22 0x750f1225 in gegl_operation_gtype_from_name ( > name=0x79ba0b "gegl:alien-map") at gegl-operations.c:218 > ---Type to continue, or q to quit--- > #23 0x750f1259 in gegl_has_operation ( > operation_type=operation_type@entry=0x79ba0b "gegl:alien-map") > at gegl-operations.c:231 > #24 0x00489348 in sanity_check_gegl_ops () at sanity.c:570 > #25 sanity_check () at sanity.c:84 > #26 0x00487f82 in main (argc=, argv=0xbafb90) > at main.c:447 > > > With respect, > Alexander Rabtchevich > _______ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp- > developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] gegl bug in git master
Hi Thorsten, thanks for reporting. This should be fixed now: commit 51621f9fb36d37556162ad514dc1492d84270d7e Author: Jon Nordby Date: Tue Jan 20 18:27:42 2015 +0100 gegl-init: Fix only returning GEGL_PATH for module directories On 20 January 2015 at 17:47, Thorsten Stettin wrote: > Hai, > > sorry, but I'm too stupid to use bugzilla. :-[ > > Here is my bug report: > > commit 89775bd29970ca26961b5b5bc49f500f696b4d76 > Author: Jon Nordby > Date: Mon Jan 19 23:51:18 2015 +0100 > > gegl-init: Split out module directory logic to function > > This commit leads to a wrong gegl module search path. > Gimp are unable to find the gegl modules. > > Workaround: export GEGL_PATH=/usr/lib/x86_64-linux-gnu/gegl-0.3 before > starting Gimp 2.9.1 > > OS: Ubuntu Linux 14.10 64 bit. > > Cheers > > PS: In my latest PPA build I reverted gegl/gegl-init.c. Now it works. > > -- > Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. > Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. > Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist > die Demut. > Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der > Demütige ist fähig zu herrschen. > > > -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
On 19 November 2014 23:57, Elle Stone
wrote:
> In case you don't understand this, HDR sRGB data is still *bounded* by the
> sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO
> negative channel values in HDR sRGB data unless the *user* chooses to do
> something odd, in which case the *user* is responsible for fixing the
> results.
>
Doesn't this contradict with the following, from your recent mail? (I don't
know what particularly is the definition of HDR used)
"We've also agreed that for chromaticity independent RGB editing operations
("CI ops", for short), by definition the same colors (as located in the XYZ
reference color space) are obtained regardless of the chromaticities that
are used to encode the data."
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP should fork babl and GEGL
On 5 November 2014 14:50, Elle Stone wrote: > On 11/05/2014 08:22 AM, Jon Nordby wrote: > >> What you just described IS side-by-side implementations of >> operations. In an ICC profile color-managed application, sRGB is >> just another RGB working space. You don't need to special-case sRGB. >> >> >> No it is not. There will be one implementation of say "multiply". It >> will be able to work on any RGB color space. Including sRGB, but without >> need for special casing. >> >> Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc. >> >> In Pippin's originally planned "unbounded sRGB architecture", >> "bablRGB" meant "convert the image to unbounded sRGB before >> perfoming *any* editing operation". Now the plan is that bablRGB >> will mean "convert to unbounded sRGB for *some* operations". >> >> >> The meaning of the "bablRGB" specifiers has not, and will not change. >> The vast majority of operations will just stop using them (because they >> have hardcoded sRGB parameters), and instead use the new specifiers, as >> per the roadmap. >> >> > For the babl code that converts an sRGB image to grayscale for use as a > layer mask, do you plan to add a new set of functions that convert from > UserRGB to grayscale? > > That code would, of course, need to pull Y values from UserRGB. Which of > course means that the new code for UserRGB would also work for sRGB images. > > For the babl code that converts from color to Y for painting on a mask, > that code currently is hard-coded to use sRGB Y values. Do you plan to add > a new set of functions that convert from UserRGB to Y for painting on a > mask? That code would also, of course, need to pull Y values from UserRGB. > Which of course means that the new code for UserRGB would also work for > sRGB images. > > For all the GIMP UI functions that currently use hard-coded sRGB Y values > sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of > alternate functions that will use Y values pulled from UserRGB? Again, that > new UserRGB code will also work for sRGB images. > > How is this not side-by-side implementation? > When I said "operations" I meant GEGL operations: There will be no side-by-side implementation of GEGL operations. Yes, we will have to introduce new babl color conversion functions which handle arbitary RGB color spaces by looking up parameters from UserRGB. Both to convert from&to grayscale and between the various RGB spaces. There is no escaping that, as we don't have any code that can handle these cases right now. Whether the existing conversion functions with hardcoded sRGB parameters for bablRGB will remain once general functions exists, is an open question. It could be that they will just call into the general RGB color conversion functions with the particular parameters of sRGB. Or it could be that keeping the functions as-is has benefits that outweigh the cost of keeping the code around, like being able to do performance optimization tricks not possible in the general case. What part of the latest new plan am I missing? Could you explain the > purpose that is served by having all the functions with hard-coded sRGB > parameters sit side by side with equivalent functions that use UserRGB > parameters? > > Or are you really getting rid of *all* the hard-coded sRGB parameters? In > which case, what is the new purpose for the bablRGB formats that "will not > change" their meanings? For operations which have an actual dependency on sRGB parameters, like the previously mentioned operations emulating color blindness. Or for interacting with (sometimes broken) operating-system/library interfaces which expects sRGB. I don't expect it to be particularly common. The primary reason (as I see it) for not changing the semantics of existing specifiers is to preserve compatibility. Code outside of BABL/GEGL/GIMP could very well be reliant on the current meaning of the bablRGB formats. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP should fork babl and GEGL
On 5 November 2014 13:50, Elle Stone wrote:
> On 11/04/2014 02:31 PM, Jon Nordby wrote:
>
>> (apologies for top-posting)
>>
>> Hi Elle,
>>
>> The BABL roadmap[1], which was written in response to comments raised by
>> you (and others),
>> details a mechanism for working with multiple RGB color spaces. It will
>> be possible to create a babl format specifier which means
>> "whatever-the-artist-chose-for-this-image RGB".
>> All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
>> float" and similar) will be changed to use this new specifier.
>> Duplicate/side-by-side implementations of operations is not necessary
>> nor planned.
>>
>
> With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
>> ICC color profiles from inputs and set up the parameters for this color
>> space.
>>
>> I do not understand how this solution (once implemented) will not work
>> for your usecase. If you think it will not, please explain why.
>>
>> I have no desired for a "sRGB only" workflow, and it does not help the
>> discussion to jump such a conclusion. Please do not assume that the
>> different needs are in conflict/adverserial to each other.
>>
>> 1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74
>>
>
> What you just described IS side-by-side implementations of operations. In
> an ICC profile color-managed application, sRGB is just another RGB working
> space. You don't need to special-case sRGB.
>
No it is not. There will be one implementation of say "multiply". It will
be able to work on any RGB color space. Including sRGB, but without need
for special casing.
> Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.
>
> In Pippin's originally planned "unbounded sRGB architecture", "bablRGB"
> meant "convert the image to unbounded sRGB before perfoming *any* editing
> operation". Now the plan is that bablRGB will mean "convert to unbounded
> sRGB for *some* operations".
>
The meaning of the "bablRGB" specifiers has not, and will not change. The
vast majority of operations will just stop using them (because they have
hardcoded sRGB parameters), and instead use the new specifiers, as per the
roadmap.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GIMP should fork babl and GEGL
(apologies for top-posting)
Hi Elle,
The BABL roadmap[1], which was written in response to comments raised by
you (and others),
details a mechanism for working with multiple RGB color spaces. It will be
possible to create a babl format specifier which means
"whatever-the-artist-chose-for-this-image RGB".
All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
float" and similar) will be changed to use this new specifier.
Duplicate/side-by-side implementations of operations is not necessary nor
planned.
With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
ICC color profiles from inputs and set up the parameters for this color
space.
I do not understand how this solution (once implemented) will not work for
your usecase. If you think it will not, please explain why.
I have no desired for a "sRGB only" workflow, and it does not help the
discussion to jump such a conclusion. Please do not assume that the
different needs are in conflict/adverserial to each other.
1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74
On 4 November 2014 19:27, Elle Stone wrote:
> Below explains why GIMP should fork babl and GEGL for use just with GIMP:
>
> Hacker News picked up an article from my website: The Sad State of High
> Bit Depth GIMP Color Management
> (http://ninedegreesbelow.com/photography/sad-state-of-high-
> bit-depth-gimp-color-management.html)
>
> In the Hacker News comments (https://news.ycombinator.com/item?id=8549560
> ), "unhammer" said:
>
> //begin quote
> From glancing over it, it seems to me like Elle Stone wants GIMP to make a
> rather radical shift to Do The Right Thing, while Øyvind Kolås (Pippin)
> values making small improvements one step at a time to avoid breaking
> current functionality.
> //end quote
>
> unhammer's otherwise excellent summary overlooks one very important point,
> which is that there is absolutely *no* current functionality in GIMP that
> would be broken by Doing the Right Thing, which is to give GIMP proper ICC
> profile color management.
>
> The only caveat is that a very few GIMP UI functions really do need to be
> labelled as "only for device sRGB images" or in some cases "only for device
> NTSC images". This article lists all such functions:
> http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html
>
> Moving back to the Hacker News comments, our very own Jon Nordby
> ("jononor") reveals precisely where the "current functionality" that would
> be broken by Doing the Right Thing actually resides:
>
> //begin quote
> GEGL is developed for GIMP, and other projects.
> http://www.jonnor.com/2014/04/imgflo-0-1-an-image-processing...
> http://www.jonnor.com/2014/11/imgflo-0-2-the-grid-launched/ Disclosure:
> I'm a GEGL dev and the imgflo maintainer.
>
> The 'other projects' part is one of the reasons why the proposed solution
> 'just strip all colorspace info, assume it is the same throughout entire
> processing pipeline' is not acceptable for GEGL, even if that might
> somewhat close to the typical usecase for GIMP.
> //end quote
>
> In other words, nothing in *GIMP* would be compromised or broken by Doing
> the Right Thing. However, Nordby's other projects *would* be affected. Of
> course his other software could be patched to assume sRGB as the image
> input profile, but perhaps that is something he doesn't want to do.
>
> As an aside, by "just strip all colorspace info", Norby seems to mean
> replacing hard-coded sRGB parameters with equivalent parameters pulled from
> the user's chosen RGB working space, which is precisely the Right Thing to
> Do for GIMP.
>
> The ICC profile color management problem with current GIMP 2.8/2.9 is that
> some babl/GEGL/GIMP functions are written using hard-coded sRGB Y and XYZ
> parameters. These functions necessarily give wrong results if you, the GIMP
> user, try to edit images in other RGB working spaces such as AdobeRGB1998,
> BetaRGB, or ProPhotoRGB (http://ninedegreesbelow.com/
> photography/users-guide-to-high-bit-depth-gimp.html).
>
> The "Right Thing to Do" for GIMP is to use LCMS to retrieve the Y and XYZ
> values from the image's actual user-chosen ICC working space profile and
> then use the Right values instead of the Wrong values.
>
> Moving back to the Hacker News comments, Jon Nordby said:
>
> //begin quote
> This article is primarly a strawman argument, the 'architecture' which is
> so adamantly argued against has already been abandoned (much thanks to
> arguments from OP). https://git.gnome.org/browse/
> babl/tree/docs/roadmap.txt#n74 It has however not magically implemented
> itself yet.
>
>
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On 16 October 2014 21:37, Øyvind Kolås wrote: > On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone > wrote: > > On 10/15/2014 01:46 PM, Simon Budig wrote: > > If I understand them correctly, Michael Henning and Jon Norby are saying > > that the criteria is something along the lines of: "For RGB editing > > operations, use UserRGB primaries *unless* there's a really, really good > > reason why only sRGB primaries will work." > > > > Is there in fact general agreement among the devs that the criteria for > > deciding when to use sRGB primaries instead of UserRGB primaries is > > approximately as follows? > > Once we have the vocabulary to also describe this aspect of the > pixelformats used by operations, the first thing we should do is to > annotate all the operations which are broken when done with sRGB > primaries, then we will be able to continue refactoring, profiling and > optimizing; without breaking existing functionality/rendering. Not > only in terms of making more operations request directly userRGB, but > also doing things like make some linear operations accept any of > userRGB or bablRGB (or other linear RGB); and creating output buffers > in the same format – to avoid unnecessary conversions in such cases. > > Using a fixed linear RGB format instead of userRGB is what for some > operations will provide the consistent results for the same property > values / slider positions. Knowing which operations this is important > for is easier to determine when we have code providing the vocabulary > in babl. The further along on the roadmap, more of the road will have > to be laid/determined as we walk it. Hi pippin, you are answering in detail 'how we will get "there"' but Elle (as I see it) is asking more 'do you agree that we want to go "there"'. This leaves me unsure if you are implicitly agreeing, if you disagree and have a different "there" in mind, or if you think it is too early to decide this. "There" being the goal that *eventually* in GEGL 'For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work.' -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On Oct 15, 2014 4:19 PM, "Elle Stone"
wrote:
>
> On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
>
>> On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote:
>
Hi, I fear you two are talking past eachother.
> I will ask again:
>
> For which specific RGB editing operations do you plan to convert the
image from fooRGB to unbounded sRGB before performing the operation?
>
> Either the answer is "None. For color-managed fooRGB images, all RGB
operations will be done on data encoded using fooRGB primaries."
The answer is (to best of my understanding): Typically none. When chosing
to work in myfavoriteRGB for one "scene" (can be a GIMP document), all
operations which specify that they work in any RGB color space, using
babl_format("scene:RGBA float") will operate on myfavoriteRGB data. So if
there is myfavoriteRGB image as input, and that also is the desired output,
there will be zero data conversions.
Supporting any RGB spaces should be the case for the vast majority of
operations dealing with RGB data, including multiply/invert and similar.
With respect to the roadmap, these operations are *currently wrongly
tagged* to only work in unbounded sRGB. This is only because we don't have
the new architecture implemented yet!
I say 'typically' because if some operation *does* specify
babl_format("RGBA float") to indicate that it just works with unbounded
sRGB, a conversion will happen. This should of course *only be used in some
cases*, when it actually just works with the specific format. I can't
immediably think of any usecase for this, but there probably are some.
I hope this addresses some of your concerns,
Regards Jon
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On 11 October 2014 13:41, Elle Stone wrote: > On 10/10/2014 07:49 PM, Øyvind Kolås wrote: > >> >> This is not about how images with no embedded profile are handled. >> sRGB derived 8bit (and to a lesser degree 16bit) formats are used for >> many other things than images with no embedded profile. >> > > You falsely assume that 8-bit images are always sRGB images and that > 16-bit integer images are probably sRGB images. > No-one said always. sRGB is however the most common for 8-bit images. > These pixel >> formats are crucical for integrating with existing file formats and >> libraries; >> > > File formats that only work with sRGB images should not impact > color-managed image editing. Advise the user to convert to sRGB. > > Accurate UI colors is a desktop color management issue, entirely > irrelevant to programming a color-managed image editor. > The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 7 October 2014 20:13, scl wrote: > Hi, > > On 4.10.2014 at 5:59 PM Øyvind Kolås wrote: > > Almost, developers decide which pixelformat is appropriate for their >> operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale >> formats as well as formats used with digital video with different data >> types; currently the set of babl formats. >> > > perhaps I missed or forgot something: what happens if a GEGL operation > is called with a wrong pixel format - will the operation refuse to work > or the data be converted to an appropriate format? > The data will be transparently converted (using Babl) so, apart from performance, there is no "wrong" pixel format when passing buffers to GEGL ops. Assuming that one does to mark the GeglBuffers with misleading BablFormats. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Great work
Hi Thorsten, what kind of patches were neccesary? Will you submit them upstream? 2014-08-12 20:59 GMT+02:00 Thorsten Stettin : > Great work, > > I'm building Babl, Gegl and Gimp 2.9.1 for some time now. > Ok, I had to add some patches but it works. > > https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/ > gimp-edge/+packages > > You'll never walk alone. :-) > > Right on. > > Regards > > Otto > > -- > Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. > Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine > ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. > Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der > Demütige ist fähig zu herrschen. > > > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp- > developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Jenkins: mypaint brush builds are failing
On 20 July 2014 11:26, scl wrote: > > On 20.7.2014 at 9:11 AM Martin Renold wrote: > >> I don't know where GIMP gets its libmypaint from. But it's probably just a >> matter of running "scons" in the libmypaint directory, to update the >> generated headerfiles. >> > > Hi Martin, > > thank you for your hint. > > I get our libmypaint version from > git://gitorious.org/mypaint/libmypaint.git > Use https://github.com/mypaint/libmypaint.git instead. Possibly the floating-point branch. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Building GIMP on OSX 10.9
On 8 May 2014 23:00, scl wrote: > Hi, > > I'm building GIMP on OS X 10.9 with an updated version > of Clayton Walker's JHBuild script. The command I use is > JHB=gimp GIMP_SDK=10.9 jhbuild build gimp-osx > > Now that I have all my dependencies built, building GIMP > itself fails with the following messages: > > Making all in core > make[4]: warning: -jN forced in submake: disabling jobserver mode. > CC gimpmarshal.o > CC gimp-user-install.o > CC gimpbrushpipe.o > CC gimpbrushpipe-load.o What does the actual compiler line look like? (make V=1) > I have glib 2.39.1 installed and the sources I build with are > in [GIMP's osx-build branch] plus Simone's and su_v's patches > to treat C files as Objective C files. However, this doesn't > seem to solve the problem. What patches are these, and why would such a thing be neccesary? -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Big problem with Gimp G'MIC with upcoming Gimp 2.10
One could set up g'mic or another well-maintained C++ plugin for GIMP
to build on Jenkins? That way these errors would be quickly (and
hopefully fixed).
On 26 April 2014 18:44, Joao S. O. Bueno wrote:
> And of course, becoming incompatible with C++ all of a sudden, if it
> builds today, would be a serious bug - so
> don't be afraid that would happen for free like that. And please,
> complain otherwise.
>
> On 26 April 2014 04:39, Thorsten Stettin wrote:
>> Am 26.04.2014 04:29, schrieb Michael Henning:
>>
>>> This was just fixed a day or two ago on gimp master. If you pull and
>>> rebuild gimp, you should be fine.
>>>
>>> https://git.gnome.org/browse/gimp/commit/?id=c808789e1df880046273c9de0a8e61b1b232ebd3
>>
>> Great work. Thanks
>>
>>>
>>> But, thanks for the report!
>>>
>>> 2014-04-25 19:24 GMT-04:00 Thorsten Stettin :
>>>>
>>>> Hi, folks,
>>>>
>>>> I have a big problem. The Gimp G'MIC code is written in C++. The problem
>>>> is
>>>> the variable name "private". It is a C++ keyword.
>>>> E.g:
>>>> *
>>>> struct _GimpColorProfileView**
>>>> **{**
>>>> ** GtkTextView parent_instance;**
>>>> **
>>>> ** GimpColorProfileViewPrivate *private;**
>>>> **};**
>>>> *
>>>> In file /usr/include/gimp-2.0/libgimpwidgets/gimpcolorprofileview.h
>>>> Please avoid using C++ keywords in C code. Could you change it?
>>>>
>>>> Thanks in advance
>>>>
>>>> Thorsten
>>>>
>>>> --
>>>> Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
>>>> Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine
>>>> ist
>>>> die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur
>>>> der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige
>>>> ist fähig zu herrschen.
>>>>
>>>> ___
>>>> gimp-developer-list mailing list
>>>> List address:gimp-developer-list@gnome.org
>>>> List membership:
>>>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>>> List archives: https://mail.gnome.org/archives/gimp-developer-list
>>
>>
>>
>> --
>> Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
>> Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist
>> die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur
>> der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige
>> ist fähig zu herrschen.
>>
>>
>> ___
>> gimp-developer-list mailing list
>> List address:gimp-developer-list@gnome.org
>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> List archives: https://mail.gnome.org/archives/gimp-developer-list
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives: https://mail.gnome.org/archives/gimp-developer-list
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Fwd: [CREATE] Only 3 days left to submit your proposal for LGM!
Don't forget, we want you at Libre Graphics Meeting in Leipzig in April! -- Forwarded message -- From: Femke Snelting Date: 12 January 2014 20:53 Subject: [CREATE] Only 3 days left to submit your proposal for LGM! To: Create ML The deadline for submitting proposals to LGM is Wednesday 15 January. Please don't forget to submit your proposal for a talk, workshop or meeting here: http://libregraphicsmeeting.org/2014/submit/ If you are planning to join us at LGM this year in Leipzig, you are welcome to sign up: http://libregraphicsmeeting.org/2014/register -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Need help for gegl translation
On 9 January 2014 10:40, Simon Budig wrote:
> Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
>> On Thu, Jan 9, 2014 at 12:11 PM, Julien Hardelin wrote:
>> > Some strings are difficult to translate in gegl interface. Could
>> > developpers
>> > give some explanations? This would be useful for all translators:
>> >
>> > 1- "FFmpeg video output sink"
>> > German translated "sink" to "ziel" (something related to "target"),
>> > italian to "recezione" ("reception"),
>> > spanish to "sumidero" (something related to sewers).
>> > What sink means here?
>>
>> Target
>
> Sometimes "sink" gets translated to "Senke" as in "Datensenke" (and
> "Quelle" for "source".
>
> If that is applicable for video data I don't really know.
Doesn't "output" already say enough, and one can drop the "sink"?
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] how far from 2.10?
On 2 January 2014 15:04, Joao S. O. Bueno > On the other hand, it is not currently easy to use GEGL bindings to > the Python linguage - > due to tha fact that all binding is delegated to be auto-generated by > gobject introspection, which in, its turn, is only maintained for > glib3, gtk+3 - (while GEGL is tied to glib2). > > I could get it working, more or less here - some calls simply crash - > and started a small project to wrap the g.i. automatically generated > objects ito things friendler to the Python developer (check > https://github.com/jsbueno/python-gegl), but that depends that one > sets-up g.i. and pygobject, correctly previously. And these projects > branchs to support glib2 are apparently unmaintained, and had already > bit-rot a bit. (If someone can get pygobject working cleanly with > GEGL, please do tell me and say which versions you have used) First of all, there is no glib3. The relevant incompatibilities here are (as I understand). 1) One cannot combine pygobject-2.0 with pygobject-3.0 (crashes horribly). 2) GTK+2 is not well supported by gobject introspection, and never will be. 3) PyGTK (the Python bindings for GTK+2) cannot be combined with PyGI. In practice this means, one can only use GEGL from Python in programs which does not use GTK+2 (GTK+3 is fine). Is this a problem for GIMP 2.10 (do Python plugins run in-process)? These are my experiences from experimenting with using GEGL in MyPaint, and working on GEGL-GTK. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] how far from 2.10?
On 2 January 2014 16:05, Michael Natterer wrote: > On Thu, 2014-01-02 at 00:48 +0100, Ofnuts wrote: >> In the usual V.R.M numbering, the situation above is typically when you >> change the version number (and maybe the file extension)... because my >> point here is not the (completely understandable) incompatibilities, it >> their understatement by calling the next version 2.10. > > It's called 2.10 because it's binary and source compatible to 2.x. > We did not remove any functions, we only deprecated. That's the > only thing that counts, not how much has changed behind the > public API. This means that plugins/scripts that worked in 2.8 should work in 2.10 and if things break it is considered a bug. So please report such issues in bugzilla! -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] how far from 2.10?
On 31 December 2013 23:26, Ofnuts wrote: > On 12/31/2013 06:36 PM, Marco Ciampa wrote: >> >> Presumably how far are we to the new 2.10 gimp version? >> How many blocking bugs are left and what are these? >> >> thanks and happy GNU year... > > > Will it really be 2.10? Its internals are different, the file format is > different (will 2.8 be able to load 16/32/FP files saved by the next > version?), and it looks like many plugins won't work anymore and will need > seroius rework... Which plugins do you expect not to work anymore, and why? 2.8 will not be able files from 2.10 using new features (naturally). I believe files produced with 2.10 which _does not_ make use of 2.10-only features can be opened in 2.8. Correct me if I am wrong. 2.10 will be able to open all 2.8 files, of course. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Single build for various OSX versions (Was: [Gimp-user] Open Gimp)
On 8 December 2013 23:45, Partha Bagchi wrote: > It means that I installed Xcode from Snow Leopard on my system. While gcc > has not changed (version 4.2.1) I believe the support files are different. > > So what I do is set /Developer/usr/bin as the first entry in my path. Also, > I pass LDFLAGS and CPPFLAGS to point to /Developer/SDKs etc. > > I do have 4.8.0 which I built and installed in ~/local/bin I'm pretty sure that you don't need a custom XCode install. The 10.6 SDK comes with XCode for OSX 10.9 (or you can install it from inside XCode). You do need to set all the right flags though. I beliieve these are all, but I don't have a Mac to verify now. -mmacosx-version-min=10.6 -isysroot/Developer/SDKs/MacOSX10.6.sdk -DMACOSX_DEPLOYMENT_TARGET=10.6 Apart from that, I think the solution for regular and consistent builds that many can contribute to is to get the build scripts upstream, and set up continious integration. TravisCI is free for open source projects and can build for Mac OSX. http://about.travis-ci.org/docs/user/osx-ci-environment/ -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Fwd: [CREATE] Getting GSoC students to LGM'14
Hi fellow GIMPers, is there any interest for this among GSoC mentors and students for getting together at LGM2014? -- Forwarded message -- From: Mario Behling Date: 8 November 2013 02:10 Subject: [CREATE] Getting GSoC students to LGM'14 To: cre...@lists.freedesktop.org Hello, I would like to follow up on getting GSoC students to LGM. The idea is, that we ask Google to support travel to get students and mentors to the event. On Google Melange I identified the following graphics projects, that participated in GSoC this year. Did I miss any? Please let me know. I have written to some core-contributors of those projects, but at the moment only got feedback from Blender and Inkscape, that they are interested. So before I can talk about details with Google I need to be sure, projects are interested to organize this together. If you know someone from thos projects who would be the right person to talk to about this, please direct them to me. Projects: Blender http://www.google-melange.com/gsoc/org/google/gsoc2013/blender Status: Follow up with different team member Inkscape http://www.google-melange.com/gsoc/org/google/gsoc2013/inkscape Status: Emailed with Tavmjong and they are interested in this. OGRE (Object-Oriented Graphics Rendering Engine) http://www.google-melange.com/gsoc/org/google/gsoc2013/ogre BRL-CAD http://www.google-melange.com/gsoc/org/google/gsoc2013/brlcad Gimp http://www.google-melange.com/gsoc/org/google/gsoc2013/gimp Thank you, Mario ___ CREATE mailing list cre...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] opencl error - gegl won't build without hard-resetting to an earlier version
On 28 October 2013 21:18, Victor Oliveira wrote: > It looks like the problem is that this script depends of Python 2.x and > you're using Python 3.x. The script should be updated.. ? If the autoconf/autotools detecs and uses Python correctly, using PYTHON=/usr/bin/python2 ./configure . will work. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Displaying linear gamma images
On 12 September 2013 16:08, Elle Stone wrote: > I've made progress getting a linear gamma image to display without > posterization in the shadows. I put up a temporary web page with the > modified code and a picture: > http://ninedegreesbelow.com/temp/convert-buffer-before-cairo.html > > The problem at this point is that the image won't display properly > until something like doing a very small levels correction forces a > screen redraw. After forcing a screen redraw, the image is displayed > without any posterization, but with magenta lines (outlining the > tiles?). The screen redraw lasts until the level dialog is closed. > > I think the problem is that I'm not properly merging and updating > "buffer" after the hard-coded transform. The corresponding code from > the lcms.c file uses layer buffers, which seems not applicable to a > projection: > gimp_drawable_merge_shadow (layer_id, TRUE); > gimp_drawable_update (layer_id, 0, 0, layer_width, layer_height); I do not know the GimpDisplayShell code well, but try to just read out data from the projection GeglBuffer instead of modifying it. And instead of the the "gegl_buffer_get (buffer, ... "cairo-ARGB32", ... data ...)" that you have marked, do the lcms transform such that the 8bit ready-for-display ends up in the "data" buffer. Also, can you please post your changes as a (git formatted) diff? It is much easier to read and apply for another contributor trying to help you out. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Displaying linear gamma images (Was Re: Update on my Gimp color management coding efforts)
On 10 September 2013 17:15, Elle Stone wrote: > On 11/12/12, Elle Stone wrote: >> On 11/10/12, Michael Natterer wrote: >>> On Sat, 2012-11-10 at 15:17 -0500, Elle Stone wrote: >>>> On 11/8/12, Jon Nordby wrote: >>>> > * Change the lcms-based conversion (modules/display-filter-lcms.c) >>>> > from being a generic display filter to be something that takes a >>>> > GeglBuffer in and blits into a cairo_surface_t. >>>> > * Change the display filter interface to accept a GeglBuffer instead >>>> > of a cairo_surface_t. As gimp_color_display_convert_surface is public >>>> > API, it should probably become a stub and be marked as deprecated. New >>>> > interface could for instance be called >>>> > "gimp_color_display_convert_buffer" >>>> > * Adapt all the display filter operations (modules/display-filter-*.c) >>>> > to the new interface and to working on 32bit floating point. If any of >>>> > the operations are no longer useful, now would be the time to drop >>>> > them. >>>> > * In the use of the display filter stack (in >>>> > gimp_display_shell_render), first let the filter stack operate on the >>>> > GeglBuffer from the projection (or possibly a copy), and then pass it >>>> > to the lcms-based color conversion, and then pass that to cairo. >>>> I'm looking forward to taking another look at the monitor display code >>>> path. Your suggestions sound very helpful. >>> >>> It does, but it's clearly step 2 (or step n). IMO we should first >>> get the lcms plug-in right so the data GIMP is dealing with is >>> correct in the first place. >> Hi Elle, nice to see this picked up again! > Step 1 happened a long time ago. I'm trying to implement Jon Norby's > suggestions because it would be nice to see a linear gamma image > displayed without posterization in the shadows from the conversion to > 8-bits that happens before the conversion to the monitor profile. > Quoting Jon's suggestion: > > (1)call a "GeglBuffer from the projection (or possibly a copy)" and then > (2)pass it to the lcms-based color conversion, and then > (3)pass that to cairo. > > So how does one "call a GeglBuffer from the projection"? I said "operate on", not "call". :) The projection has a GeglBuffer associated with it, see https://git.gnome.org/browse/gimp/tree/app/display/gimpdisplayshell-render.c#n77 That is what the color conversion needs to use as an input, basically*. * It should probably go through the display filters first, if any exists. But that can probably be solved later. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Of Palettes and Plug-ins
On 6 September 2013 19:11, Chris Mohler wrote: > On Thu, Sep 5, 2013 at 11:30 PM, Warren Turkal wrote: >> Just so you all know, this actually started with my wife wanting to import >> *.ase palettes in . > > > Back to your main question: unless I'm out of touch, I believe all of > the file loader plugins need to be written in C. I could well be > wrong though. It's been quite some time since I touched anything > having to do with GIMP besides the occasional plug-in in Python. The OpenRaster file loader/saver (file-ora) is written in Python. It does not do any pixel manipulation of its own though. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] non-destructive editing and adjustment layers
On 1 September 2013 22:33, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Mon, Sep 2, 2013 at 12:22 AM, wrote: > > Okay. so do you mean that any non-GEGL plugins or filters should > > be treated as not 32-bit compatible and is therefore capable of > > silently clipping data? > > By the time GIMP 2.10 is out, there will be no such plugins in GIMP, > so what you are suggesting simply doesn't make much sense :) What about all the plugins using the legacy APIs found at registry.gimp.organd other places? -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP python (pythonfu) plugin: How to include the PreviewArea from gimpui
On 21 July 2013 04:47, Joao S. O. Bueno wrote: > On 20 July 2013 17:58, Alexandre Prokoudine > wrote: > > On Sat, Jul 20, 2013 at 9:22 PM, Akkana Peck > wrote: > >> Michael Schroeder writes: > >>> I am writing a plugin for Gimp. It works alright via the GIMP UI and > >>> command line by registering it to gimp. But I would wish to offer also > a > >>> Preview area in the UI, and apparently it is not so easy to add the > >>> PreviewArea from the gimpui python package to the input dialog. > >> > >> Since I haven't seen any other responses: > >> > >> I don't think there's a way to add a formal preview area in Python. > > > > AFAIK, that was one of the points of GIMP's GSoC2010 project re > > Python. The one that was never merged. > > That part was not complete, anyway. :-/ > > But in current GIMP what makes sense is to figure out how to make GEGL > calls from GIMP-Python plug-ins, and create an on-screen preview API > using the GEGL capabilities. And while one is at that, there is the > need port Python-fu from pygtk to gobject introspection as well - I > hacked a bit on it a while ago, and I think it can be done while > keeping backwards compatibility for python-fu scripts. > GI bindings are not very well supported for GTK+2, and probably will never be. So switching to GI makes sense to do together with GTK+3 switch, that is GIMP 3.0. That also means that compatibility does not need to be 100%, though it should be possible to keep most things compatible. In MyPaint we used pygtkcompat and some compat wrappers of our own for that: http://gitorious.org/mypaint/mypaint/blobs/master/gui/gtk2compat.py One thing that gave us hell is that when using PyGI one cannot import anything that uses PyGTK. Doing so led to instant crash... This might make it neccesary to install an import handler to make sure that plugins don't accidentially pull in PyGTK when the core/new plugins uses PyGI. As for preview with GEGL, gegl-gtk has a widget should work just fine for that - and will automatically handle updates and transformations. Long-term, I hope that we can find a way for plugins to have on-canvas preview. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Parallelization project (for students)
On 8 July 2013 11:59, Thomas Karcher (IPD) wrote: > Dear GIMP developers, > > we're a team of teaching assistants at KIT Karlsruhe. We'd like to offer > a hands-on parallelization course for master students of computer > science in the upcoming semester, and our idea is to teach > parallelization while actually parallelizing "real" software. > > For this, we're looking for a suitable project - this is where GIMP > comes in: We're hoping that GIMP includes an image filter or some other > component that is more or less compute-intense and worth parallelizing. > We aspire to provide a contribution to GIMP in form of a working patch > that incorporates the parallelization we worked out. > > Do you see a component in GIMP that would be suitable for us _and_ you? > (I am asking you because a) I am lazy and b) as a non-GIMP-developer, I > can't possibly have the insight you have or even remotely guess which > component might be suitable for us _and_ of use to you once it's > parallelized.) > Hi Thomas, first I'd like to commend you on chosing to work on real, useful, software while teaching. GIMP is moving towards using GEGL as its image processing engine. This means using GEGL operations, either to directly replace existing image processing code, or to use operations as part of a GIMP plugin or tool (or as a minimum work on GeglBuffers). http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL GEGL uses OpenCL to provide parallelizated operations, grep for gegl-cl.h in the source tree for examples. A Google Summer of Code project is also taking place for porting filters from GIMP to GEGL. This work is mentored by Victor Oliviera (victorm) and done by Carlos Zubieta (zurwolf) , so you should probably check in with them. http://wiki.gimp.org/index.php/Hacking:GSoC/2013/Ideas So if working with OpenCL is not a problem, there is plenty of suitable work. The nice thing about operations for student work is that they are self-contained and can be understood quite easily in isolation. PS: 1) wiki pages may be out of date 2) most devs prefer IRC over email, so get on #gimp and #gegl on GimpNet 3) ask if you get stuck -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Crowdfunding proposal
On 11 July 2013 21:47, Burnie West wrote: > On 07/10/2013 11:22 PM, Abraham Levi Mireles Alvarez wrote: > >> Hello Gimp team >> Crowdfunding proprosal >> ---Introduction--- >> I am an artist and big fan of Gimp and the great job you have done so far >> with it. >> > Since many - if not most - of the replies to your query on the gimp-user > list came from people also subscribing to the gimp-developer list, I hasten > to suggest that you reread them -- > For reference, this seems to be the thread: http://www.gimpusers.com/forums/gimp-user/15724-gimp-kickstarter -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Writing a totally different UI for GIMP
On 17 June 2013 17:14, Alberto Mardegan wrote: > Hi all, > a parallel-universe question: if I were to make a gimp-like application > (just somewhat simpler and more limited) with a different UI and toolkit > (say, QML), are there some parts of the GIMP codebase that would be useful > to me, or would I be better forget about it and start with just using GEGL? > > I see that the GIMP codebase consists of many different libs, but I don't > have a clear picture of what they do and how much they depend on Gtk. > > Ideally, I'd like to be able to re-use the gimp plugins, or at least make > porting quite easy. > The file-loaders in GIMP may be of value, to be able to support many different file formats. Using libgimp to allow GIMP plugins to work without porting could also have significant value. Apart from those, GEGL + Qt + gegl-qt should get you a long way. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] How to deal with pixel-per-pixel operations?
On 11 June 2013 14:03, Alessandro Francesconi wrote: > Got problems here... > > Following the goat example, I downloaded the libgegl-dev 0.2 package (I'm > on Debian) and I've started including the necessary libs in my source code: > > - > #include > > #include > > #include > - > > gegl_init() is recognized, but gimp_drawable_get_buffer() and > gimp_drawable_get_shadow_buffer() don't. > They appears to be defined in the git repository, here: > https://git.gnome.org/browse/gimp/tree/libgimp/gimpdrawable.h > But looking at the gimp 2.8.4 libs I have in my machine, gimpdrawable.h > does not contain those definitions! > > Don't tell me... gimp_drawable_get_buffer() and similar are not yet in the > set of available APIs for GIMP-dev 2.8.4 is it right? How can I develop > a GEGL plugin for 2.8.4 application in these conditions? .-. > I am afraid that is the case. These APIs were introduced after 2.8.x was released, and will be available in GIMP 2.10. The existing (non-GEGL) pixel manipulation APIs will be removed in GIMP 3.0, which will follow after 2.10. I recommend just making sure that the code that manipulates pixels/tiles is clearly separated in the plugin and that they fit OK with the API model that GeglBuffer has, to make porting when 2.10 comes out quick and easy. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP for iPad
On 3 May 2013 01:11, Michael Schumacher wrote: > On 03.05.2013 00:26, DAVID D BEAZER wrote: > > Sent from my iPad - Is anything in the works for developing a version >> of GIMP for the iPad. if so then also being able to link with a desk >> top version with changes to the image on the iPad. As their is a >> growing base of iPad users, this might be a very good app to create. >> > > Apple has found this neat hole to make their terms incompatible with the > GPL, most likely to quench at least some competition on their closed > platforms. > > See http://www.zdnet.com/blog/**open-source/no-gpl-apps-for-** > apples-app-store/8046<http://www.zdnet.com/blog/open-source/no-gpl-apps-for-apples-app-store/8046>or > https://www.fsf.org/news/2010-**05-app-store-compliance<https://www.fsf.org/news/2010-05-app-store-compliance>or > http://adium.im/pipermail/**devel_adium.im/2011-January/**007973.html<http://adium.im/pipermail/devel_adium.im/2011-January/007973.html>or > https://www.fsf.org/blogs/**licensing/more-about-the-app-** > store-gpl-enforcement<https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement> > > You shouldn't expect to see GIMP or other GPL'ed FLOSS software you like > on the iPad anytime soon. Or even using LGPL libraries, for the same reasons. This unfortunately also means anything using GEGL. http://stackoverflow.com/questions/459833/which-open-source-licenses-are-compatible-with-the-apples-iphone-and-its-offici I believe the problem also exists for Google Play store. Then again Firefox for Android is available there, but it could be Google is just to wary of anti-trust to shut it down. /speculation -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp-plugin profiling
On 10 March 2013 22:55, Tibor Bamhor wrote: > Hi, > > Thank for you interest. Today I spent some time reading about perf - it is > quite complex tool or rather it measures things that I am not familiar with. > However I did some primitive testing and got this output: > > 7729.437618_task-clock#0.386_CPUs_utilized__ > ___8556_context-switches__#0.001_M/sec__ > __0_cpu-migrations#0.000_K/sec__ > 899_page-faults___#0.116_K/sec__ > 20346686795_cycles#2.632_GHz_[92.65%] > __0_stalled-cycles-frontend___#0.00%_frontend_cycles_idle[99.92%] > __51284_stalled-cycles-backend#2.89%_backend__cycles_idle[67.69%] > _2234245557_instructions__#0.11__insns_per_cycle > __#0.26__stalled_cycles_per_insn_[71.21%] > __931561726_branches__#__120.521_M/sec___[77.62%] > _1877007958_branch-misses_#__201.49%_of_all_branches_[84.88%] > > I dont dare to interpret it, but the "201.49%" in last line was in red so > there is obviously a problem there. Here I would start. > > If you (or anybody else) can point me at some source on internet I would be > thankfull. Or perhaps shortly explain how to mitigate the problem. But I > understand this is not gimp-specific issue... Yes, if you have branches in inner loops eliminating them can give large speedups. A quick google search gave this reference which looks like an OK start: http://software.intel.com/en-us/articles/avoiding-the-cost-of-branch-misprediction Less branching may also allow the compiler to auto-vectorize more. If you are unable to remove the branches in your inner loop, you can try to guide the branch predictor using GCCs __builtin_expect: http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Note that not just if/case statements introduce branching, do/while/for do as well. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP - flesh out a way of allowing lazy rendering?
On 4 March 2013 15:24, Joao S. O. Bueno wrote: > Hi all -- > > While GIMP 2.9 is thriving with lots of possibilities, one thing remain as > fact: > it is dead slow. > > I most likely missed some of the efforts being done to try to > compensate for that - > like avoiding unnecessary pixel format conversions in some operations - and > the possibility of having GEGL to run with open-CL acceleration. > > I think it is not an exaggeration to add that even with this, the > current rendering model > is dead slow. > > To the point of being unfeasible to work on a 1024x768 image in modern > hardware - > one simply can't paint. Other raster application, including GIMP 2.8, are doing OK performance wise with a rendering mode that is very similar to GIMP uses now, so I don´t we necessarily need to do drastic changes there in order to fix the performance. I think a useful GSoC project would be to define and implement some meaningful benchmarks for GIMP. If successful, that would give insights into what the causes of the current performance problems are. I believe that is needed for coming up with a good solution for current, and future performance issues. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp choking on python invocation
On 19 November 2012 22:54, Vio wrote: > print 'TRACE> entering serve_forever()' > server.serve_forever() > This script will not return control back to GIMP, so the application probably cannot continue past the loading of this script. You will need to do this in an async fashion. You can try to register a glib timeout/idle handler, though I am not sure if it will work. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On 19 November 2012 15:21, Robert Krawitz wrote: > On Mon, 19 Nov 2012 15:30:38 +0400, Alexandre Prokoudine wrote: > > On Mon, Nov 19, 2012 at 3:28 PM, Alberto Mardegan wrote: > > > >> Reformulating: is it possible for a user *who reads and understands all > >> question dialogs which appear to him/her*, to actually lose the layers > >> when saving to JPEG with gimp 2.6? > > > > Yes. > > > >> If yes, how? > > > > By being overly confident and not forward-thinking. > > And guess what? I've done that on occasion myself. But I don't blame > my tool for that. I blame the tool for that, even if this is the status quo in most of todays desktop applications. Software tools should take into account and be able to compensate for our sometimes flawed behaviour. In a future fairytale non-destructive world that we are moving towards, it could perhaps work something like this: * All actions the user does to a document inside GIMP is automatically stored. * "Save As" would become an *optional* action, allowing to chose where the document is stored. * "Save" would be come an *optional* action that allows to describe that particular state of the document, so that particular revisions are easy to find. * Export would work like now. In this model, if you you opened a JPEG file, added some layers, did some processing and then exported to another JPEG and quit GIMP - nothing would be lost[1]. All the actions of the document would be stored. The document would appear in "Recently used Documents" or similar. Exactly like a document that you have explicitly saved. Such a work-flow would mean that the user is not required to be forward thinking in order to preserve his work. He or she can focus 100% on the task at hand (here, creating a derivate JPEG file from an original JPEG image), without having to actively keep in mind to not make destructive actions. 1. Tthere would of course be no prompt in this case. Alexandre: this is my proposal for the better image-exported-but-not-saved prompt. Make it obsolete. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On 19 November 2012 12:11, Karl Günter Wünsch wrote: > Worse still, since most > of the time I am opening and preparing a preview image out of a > previously created XCF via export - having the program prompt me to save > to the original name resulted in overwritten valuable XCF with rubbish > ones which only ever should exist in exported format! So basically > because of your idiot proof mode prompted me to lose my time consuming > work because it was overwritten with an inferior version from which I > can not recover! > This is a real issue. It is caused mainly by GIMP not having a good way of creating/exporting multiple views of a document. It is further exacerbated by us not storing undo/redo history in the document. Both these are things to fix on the path to less/non-destructive workflows. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On 19 November 2012 11:50, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Mon, Nov 19, 2012 at 2:45 PM, Alberto Mardegan wrote: > > > Is it actually possible for a user to lose the layers when saving to > > JPEG with gimp 2.6? The JPEG plugin asks to flatten the image, at which > > points the users would cancel the process if he really cares about them. > > You seem to be under impression that people actually read text in prompts > :) > In fairness, that also applies to the prompt that now reminds the user of exported-but-not-saved images. A difference is perhaps that closing an image/application (which is when this prompt is shown) is expected to be potentially destructive (where as saving is not), so the prompt gets more attention. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On 16 November 2012 11:54, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Fri, Nov 16, 2012 at 2:45 PM, Alberto Mardegan wrote: > > > I'm not here to reignite the discussion about the new save/export > > behaviour, don't worry. :-) > > and > > > So, given the inconcialiability of the opinions in the same UI, I > > propose to have an option in the preferences dialog to go back to the > > old behaviour (with the 2.8 behaviour as default). > > are mutually exclusive statements :) > > We have discussed it in the future and decided against it. With that being said, it is already easy to (mostly*) revert to the old-style behaviour: http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes * It will still prompt you about unsaved document but exported) as you close the image. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Update on my Gimp color management coding efforts
On 8 November 2012 21:29, Elle Stone wrote: > I was hoping that by removing all the deprecated functions the problem > with high bit depth color conversion being subverted by the background > TRC conversions would be resolved, but it wasn't. I am unsure how to > procede, although I have pinpointed exactly where in the Gimp code the > Babl functions are called (it's not in the lcms plugin code) and which > particular Babl functions are being called. Has your work on replacing the deprecated functions found its way into git master? > In the existing "image color space to monitor color space" code, the > image RGB values are converted to 8 bits *before* the RGB values are > sent to the code that converts from the image color space to the > monitor profile. Which means the monitor display of linear gamma color > space images has severely posterized deep shadow detail (the image > itself isn't damaged, just the monitor display of the image). > > I've been tracing the "image color space to monitor color space" code > execution path, looking for a place to intervene to give the > color-space-to-monitor-space lcms profile conversion 16-bit integer or > 32-bit floating point values instead of 8-bit values. It turns out > that the relevant "image color space to monitor display space" code is > spread out over quite a few gimp, babl, and gegl c-code files, and > makes heavy use of Cairo-related functions. I looked into this code a bit earlier. Here is one way of approaching it: * Change the lcms-based conversion (modules/display-filter-lcms.c) from being a generic display filter to be something that takes a GeglBuffer in and blits into a cairo_surface_t. * Change the display filter interface to accept a GeglBuffer instead of a cairo_surface_t. As gimp_color_display_convert_surface is public API, it should probably become a stub and be marked as deprecated. New interface could for instance be called "gimp_color_display_convert_buffer" * Adapt all the display filter operations (modules/display-filter-*.c) to the new interface and to working on 32bit floating point. If any of the operations are no longer useful, now would be the time to drop them. * In the use of the display filter stack (in gimp_display_shell_render), first let the filter stack operate on the GeglBuffer from the projection (or possibly a copy), and then pass it to the lcms-based color conversion, and then pass that to cairo. In the longer term, one can consider making the display filters GEGL operations and the display filter stack a GEGL subgraph. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] building git on SuSE 12.2
On 22 October 2012 22:04, Dexter Filmore wrote: > Am Monday 22 October 2012 21:17:32 schrieb Dexter Filmore: >> Am Monday 22 October 2012 18:00:23 schrieb Jon Nordby: >> > On 22 October 2012 16:52, Dexter Filmore > checking for gtkdocize ... > You must have gtk-doc installed to compile GNU Image Manipulation Program. > Install the appropriate package for your distribution, > or get the source tarball at > http://ftp.gnome.org/pub/GNOME/sources/gtk-doc/ > You can also use the option --disable-gtk-doc to skip > this test but then you will not be able to generate a > configure script that can build the API documentation. gtk-doc looks to be missing. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] building git on SuSE 12.2
On 22 October 2012 16:52, Dexter Filmore wrote: > Hi all, > > I made some futile attempts to build git on SuSE 12.2 but as soon as I try and > build gegl it claims that babl (which I just built and pointed autogen for > gegl at) does not exist. > > > So far I hacked up some scripts, the babl script for example looks like this: > > #!/bin/bash > export PATH=/opt/gimp-git/bin:$PATH > export PKG_CONFIG_PATH=/opt/gimp-git/lib/pkgconfig > export LD_LIBRARY_PATH=/opt/gimp-git/lib > export ACLOCAL_FLAGS="-I /opt/gimp-git/share/aclocal $ACLOCAL_FLAGS" > export XDG_DATA_DIRS=/opt/gimp-git/share > > cd babl > ./autogen.sh --prefix=/opt/gimp-git && make > > > which then results in babl being installed in /opt/gimp-git Not unless you also run "make install"? ;) If that is not the problem, check that "babl.pc" ends up in the expected directory ($libdir/pkgconfig) and that PKG_CONFIG_PATH is set accordingly. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] using the capabillities of gimp through Java
On 3 October 2012 10:45, Ziyad Mohammad wrote: > Hi > > can i connect java to gimp so that i can do some image processing on a map > using java ide > the ide that i will use will be either eclipse or netbeans Hi, have you tried http://jgimp.sourceforge.net/? You should also be able to GEGL with gobject introspection bindings using JGIR: https://live.gnome.org/JGIR -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
On 19 September 2012 16:10, Elle Stone wrote: > My lcms.c high bit depth profile conversion code still some major > issues to iron out, including: > > *I haven't rewritten to use nondeprecated functions the code section > that takes care of alpha channels. > > *The show-stopper: the code still doesn't work correctly at high bit > depths unless some/all of the Babl functions that convert back and > forth between the sRGB TRC and linear gamma TRC are modified to stop > the back-and-forth conversion. Otherwise, as I've noted before, > tonality AND color are wrong after the profile conversion. > Unfortunately, replacing the deprecated functions didn't fix this > problem. > > The problem seems to be that when doing an ICC profile conversion on > an image with a bit-depth greater than 8 bits, a couple of functions > in babl/base/model-rgb.c are called midway through the ICC profile > conversion. These functions are not called when converting an 8-bit > image. I haven't been able to track down what bit of Gimp/Babl code > calls the functions in model-rgb.c while the ICC profile conversion is > in progress. > > Elle Hi Elle, glad to see you are still working on this. Could you provide a patch with your changes? This makes it easy for others to review your changes and apply them. The easiest way (unless you've added files) to make a plain patch is to do the following in the GIMP git directory: git diff origin/master > geglify-lcms-plugin.patch For more info on git usage, including how to make a git-formatted patch see for instance: http://git-scm.com/book -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 2GB limit on Resource Consumption: Tile cache size
On 17 September 2012 20:23, Elle Stone wrote: > While making changes to "Edit/Preferences/Environment, Resource > Consumption: Tile cache size", I noticed a warning when I tried to > increase the cache size to 2 gigabytes, or 2048 megabytes (terminal > output, Gimp 2.9, started from the command line): > > (gimp-2.9:3518): GLib-GObject-WARNING **: value "-2147483648" of type > `gint' is invalid or out of range for property `cache-size' of type > `gint' > > If I set the cache size to 2047 megabytes, there is no warning. If I > set the cache size to more than 2048 megabytes, the > 'GLib-GObject-WARNING **: value' gets correspondingly larger. > > I only have 4 GB of ram on my computer, but I have successfully given > more than 2GB to other image editing programs. A lot of people have > computers with way more than 4GB of ram. Would it make any practical > difference to be able to use more than 2GB of ram for the tile cache > when using Gimp? It seems odd to be limited to less than 2GB for the > tile cache size, solely because the type is gint. > It is probably this issue: https://bugzilla.gnome.org/show_bug.cgi?id=648265 -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] Gimp 2.8 : my opinion
On 8 September 2012 09:32, Michael Natterer wrote: > On Sat, 2012-09-08 at 00:25 +0200, Alexandre Ravaux wrote: >> *BEFRORE READING, EXCUSE THE SEVERAL MISTAKES YOU MAY READ IN THIS MESSAGE. >> I'M FRENCH (I KONOW IT IS NOT A GREAT EXCUSE BUT I DO NOT FIND ANYTHING >> ELSE...)* >> >> Hello, >> I am a french young Gimp user (since 2.0 version) and I wish to tell my >> opinion about the latest version (2.8). In fact, I did not know to whom I >> have to send this message.I suppose you'll tell me where's the exit door, >> or, at worst, to whom I have to write. >> >> I congratulate you for the hard work you do. All these improvements: >> improved layers manager (with folders...), awesome text editor... But (yes >> there is always a "but" in this kind of message) I do not appreciate the >> deliberate choice that you made to save the file within the xcf format and >> to export for the other formats. It is even contrary to the freedoms of the >> user I think. Don't feel aggressed, but one of the priorities of GNU, if I >> understand Stallman's philosophy, it is the user's freedom (short reminder >> : GIMP, GNU Image Manipulation Program). Stallman's philosophy or not, I >> think it is important to let people choose the format of the picture when >> they're saving their file. >> >> I know there is little chance that you return to the saving mode into any >> format.(I hope I contributed by exposing my opinion to the improvement of >> GIMP). > > Thanks Alexandre for being friendly and not right away bitching > like many others :) > > However, we did this change for a reason: > > http://gui.gimp.org/index.php/Save_%2B_export_specification > > It's really only about getting used to a new keyboard > shortcut when exporting. Libre Graphics World has an article on the subject which is also worth a read: http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Compile module like display-filter-lcms.c
On 31 August 2012 17:39, Elle Stone wrote: > What's the right way to compile a module such as display-filter-lcms.c? The build of the in-tree modules is already set up in automake. Just change the file after having compiled GIMP without modifications, and run "make" (and "make install"). Only the neccesary files will be recompiled when you do this. I recommend doing the same when working on the in-tree plugins, or any other part of the GIMP source code. If the build parameters needs changing, like for building against LCMS 2 instead of 1, I'm afraid you will have to look into the autotools files (configure.ac and Makefile.am). Read up on autotools on the web, and ask if you get stuck. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 31 August 2012 17:37, Elle Stone wrote: > On 8/30/12, Jon Nordby wrote: >> This is actually one more conversion and one step earlier than we need >> to. Ideally the pipeline should look like this: >> >> GeglBuffer -> | display filter stack | -> sRGB in monitor profile -> | Cairo >> | >> >> That way we only convert to the monitor profile as a last step. This >> would require GEGLifying the display filter stack and all the modules >> it uses. > > (I think "sRGB in monitor profile" probably means "sRGB or monitor > profile". Jon - yes? no?) Yes. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 30 August 2012 13:55, Elle Stone wrote: > On 8/30/12, Jon Nordby wrote: >> On 30 August 2012 01:01, Elle Stone wrote: >>> Regarding sRGB and rendering to the screen: >>> Could you explain more about what you mean by "rendering to the screen >>> is done using sRGB"? What about the actual monitor profile? >> >> Cairo, the library used for rendering to the screen in GTK and GIMP >> expects its input as sRGB*. See app/display/gimpdisplayshell.c for >> example of how we use this library. The Babl format "cairo-ARGB32" is >> short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected, >> pre-multiplied alpha. The LCMS plugin is used before this step to do >> the conversion with the actual monitor profile. > > So if I understand what you are saying (I don't think I do): > First the lcms plugin converts the image to the actual monitor display > profile. > Then "something" converts the image to sRGB and sends the image to Cairo? > And then Cairo sends the image to the screen? You understood me correctly, but what I said it turned out to be wrong. Quoting myself from the follow up email: "Corrections : the LCMS display filter module is used, not the LCMS plugin. File: modules/display-filter-lcms.c The conversion is done _after_ the image has been rendered into the Cairo image buffer. See the call to gimp_color_display_stack_convert_surface in gimpdisplayshell-renderer.c" So the pipeline is at the moment: GeglBuffer (format depending on image precision setting) -> | gegl_buffer_get | -> sRGB (without a profile or with the profile of the document?) -> | display filter stack | -> sRGB in monitor profile -> | Cairo | This is actually one more conversion and one step earlier than we need to. Ideally the pipeline should look like this: GeglBuffer -> | display filter stack | -> sRGB in monitor profile -> | Cairo | That way we only convert to the monitor profile as a last step. This would require GEGLifying the display filter stack and all the modules it uses. > I don't think that is what really happens. If it were happening, all > images displayed by Gimp would have a magenta color cast as displayed > on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to > the screen (and doesn't care what these numbers "mean"), and Gimp is > sending the monitor profile RGB numbers to Cairo. Yes, you are probably right that Cairo itself does not care about the meaning of the RGB values, and that this is up to the display system and screen. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 30 August 2012 12:11, Jon Nordby wrote: > On 30 August 2012 01:01, Elle Stone wrote: >> Regarding sRGB and rendering to the screen: >> On 8/29/12, Jon Nordby wrote: >>> On 29 August 2012 19:03, Elle Stone wrote: >>>> Why does the /babl/babl/util.h code get executed from fast-float.c, >>>> float.c, model-rgb.c, model-gray.c, and several other files, resulting >>>> in endlessly performed conversions between linear and regular sRGB TRC >>>> in the background of all image processing? >>>> >>> >>> Rendering to to screen / the windowing system is done using sRGB. So >>> anything that causes canvas updates when the image itself is not in >>> sRGB will trigger such conversions. >> >> Could you explain more about what you mean by "rendering to the screen >> is done using sRGB"? What about the actual monitor profile? > > Cairo, the library used for rendering to the screen in GTK and GIMP > expects its input as sRGB*. See app/display/gimpdisplayshell.c for > example of how we use this library. The Babl format "cairo-ARGB32" is > short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected, > pre-multiplied alpha. The LCMS plugin is used before this step to do > the conversion with the actual monitor profile. Corrections : the LCMS display filter module is used, not the LCMS plugin. File: modules/display-filter-lcms.c The conversion is done _after_ the image has been rendered into the Cairo image buffer. See the call to gimp_color_display_stack_convert_surface in gimpdisplayshell-renderer.c -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 30 August 2012 01:01, Elle Stone wrote: > Regarding sRGB and rendering to the screen: > On 8/29/12, Jon Nordby wrote: >> On 29 August 2012 19:03, Elle Stone wrote: >>> Why does the /babl/babl/util.h code get executed from fast-float.c, >>> float.c, model-rgb.c, model-gray.c, and several other files, resulting >>> in endlessly performed conversions between linear and regular sRGB TRC >>> in the background of all image processing? >>> >> >> Rendering to to screen / the windowing system is done using sRGB. So >> anything that causes canvas updates when the image itself is not in >> sRGB will trigger such conversions. > > Could you explain more about what you mean by "rendering to the screen > is done using sRGB"? What about the actual monitor profile? Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format "cairo-ARGB32" is short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile. * It is unclear to me how strict this expectation is as this is not documented anywhere in Cairo. Perhaps someone here can shed some more light? > Back in the day, a decent CRT monitor could easily be calibrated to > match the sRGB color space, because sRGB was based on the display > characteristics (tone curve, primaries, "dial-a-white-point" and 0 > black point) of the CRT monitor. (See "All the Colors, Some of the > Colors, the Colors of Daylight": > http://ninedegreesbelow.com/photography/all-the-colors.html). > > Today's LCD monitors are not well-characterized by sRGB. It is not > just a matter of the LCD monitor native white point not being D65. The > phosphors are different, which means the primaries are different, > which means the color gamut is different. And unlike a CRT, with an > LCD you can't get (0,0,0) displayed to the screen (the sRGB black > point assume "zero light" can be sent to the screen). Which means you > cannot really calibrate your monitor to use the sRGB TRC. (See "sRGB — > Not So Good for LCD Monitors": > http://ninedegreesbelow.com/photography/srgb-bad-monitor-profile.html > and "Image Display Technology": http://www.marcelpatek.com/LCD.html.) > > A wide gamut monitor profiled in its native state would be an even > worse fit to sRGB, though compared to a regular LCD, a wide gamut LCD > monitor can achieve a much closer calibration to sRGB, IF one chooses > to give up the extra color gamut. But why would you want to give up > all that extra color gamut goodness? An RGB30 (10 bits per channel) image format was added in Cairo 1.12 earlier this year. I don't know if any if the display backends used on Linux, Mac OSX or Windows handles this format yet. It could be the output it still clamped or converted to 8 bit per channel even on wide gamut displays. I highly suspect that would be the case on X11. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 29 August 2012 19:03, Elle Stone wrote: > Why does /babl/babl/util.h provide functions that transforms back and > forth between linear gamma TRC and the regular sRGB TRC? I'm sure > there is a reason, but the reason is not apparent to me. Babl is a pixel format conversion library. It can convert between RGB pixel representations with linear gamma and gamma-corrected, separate alpha channel and premultiplied alpha, or to/from other pixel formats like HSV, HSL, LAB. > Why does the /babl/babl/util.h code get executed from fast-float.c, > float.c, model-rgb.c, model-gray.c, and several other files, resulting > in endlessly performed conversions between linear and regular sRGB TRC > in the background of all image processing? > > That conversion from linear gamma to the sRGB tone response curve and > back gets executed literally hundreds of thousands of time, every time > you do anything at all using Gimp. Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions. Also, any legacy code paths that are still in place before the GEGLification might cause conversions to sRGB. I don't know exactly which parts those are in the current codebase, but anything that uses the deprecated pixel manipulation functions are likely candidates. I note that the lcms plugin still uses these interfaces, and I suspect that is what is causing the implicit (and unwanted) conversions you are seeing. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 prohibitively slow
On 20 July 2012 03:25, Alexandre Prokoudine wrote: > On Fri, Jul 20, 2012 at 1:04 AM, SorinN wrote: > >> Anyway, nothing is perfect, at least for you Alexandre - so let's >> (unnecessary) complicate the topic, if not related to GEGL transition, >> in a logical consecution next question is - why is slow then ?. >> >>>I'd like to know what developers know that :) >> >> Now this is the real point over the pretty letter I. >> Well, you are free to ask them all - who am I to stop you ? >> Probably not just developers but all peoples who changed 2.6 for 2.8, >> but go on, ask developers just to be sure. > > Let's try again: > > I'd like to know what developers know that :) > > Meaning: "No developers know that, because your assumption about the > transition effect is incorrect" :) > > The bug is known, the fix isn't trivial, mitch didn't have the time to > do it for 2.8. Link to the bugreport please? > If anyone's willing to have a go at it, please join IRC to discuss it. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Motion blur algorithms
May I ask why you are not simply using GEGL as the backend for you application? It implements a large number of image processing operations (every one you've asked about so far) and is designed to be reusable. If there are issues which prevent you from using it we would love to hear about it so we can improve the situation. On 13/07/2012, Calculemus wrote: > Nope I am far from releasing :) > > Why GIMP? It is the only open source for this kinda thing I know. > > Easy to find papers, hmm? Ok, I am a student and need your advice > on this. Let's say I want to find a paper on an algorithm which I know > what it does, and that is all. Where do I search? I am member at > acm.org but usually they have very advanced papers. > -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Developer motivation and user interactions - Re: Bring back normal handling of other file formats
On 21 June 2012 12:59, Monty Montgomery wrote: >> In fact it kills the motivation of developers who are >> putting sizable parts of their life into creating, maintaining and >> improving GIMP. When you kill motivation in volunteer-driven project, >> you are not just destroying someones hobby - the project will >> eventually stagnate, wither and die. > > Oh for fuck's sake. > > I was happy to hold my tongue until this. The developers are > *victims* of users being unhappy with a design decision? Ok, that part of my post must not have come across the way I intended at all. At all. My intent was to say that a volunteer project is driven mostly by the motivation of the contributors, and that the feedback from users can be a major driver in this. I believe that focusing on the things that can be improved is usually more beneficial to motivation than to get stuck in particular decisions that have been made (in the best of intents). It is great that people care, I just would like to see that energy have a more positive outlet. I realize now that my statement above contributed negatively, not positively. I apologize for that. I should have just said: Please write a description of your typical workflow (as a whole) when making an argument. Then we can find the things that can be improved together. And hopefully someone will be motivated to pick that up. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
On 21 June 2012 10:48, Karl Günter Wünsch wrote: > On 21/06/12 10:20, Thorsten Wilms wrote: >> You already mentioned habit. Having such an option would allow you to >> keep what is now a bad habit (to not discern between saving the work and >> exporting), instead of forming a new, productive one. > IMHO the distinction between saving and exporting is an artificial one > no one > really should need to care about. This is the goal to strive for. I think everyone agrees on that. This is however not something we can achieve within a month or two. Currently, and for the immediate future, there is a difference between export and save in GIMP, due to the following facts: [save]: only XCF can store all the information about the document which you have produced. Not storing as XCF means you lose/destroy data [export]: there is a common need for exporting to PNG/TIFF etc. - because XCF documents are not supported everywhere With these current facts, I do not think we shall try to deceive the user into thinking that save and export is the same. They are not and the consequence for mixing them up can result in a loss of data. None of these facts are unchangeable however. We can improve the situation for [export] by identifying in which work-flows people commonly use GIMP and export, and work to simply eliminate the need to care about the PNG/JPEG/TIFF file. For example the user might export to be able to view or work on the document in another libre graphics application. A strategy to get rid of that already exists, just make them support XCF: https://mail.gnome.org/archives/gegl-developer-list/2012-June/msg3.html Another common workflow might be to export a document to get it onto the web. We can eliminate the problem here by creating "export handler" that will let you upload directly, from within GIMP, to online services like Wordpress, Picasa, Facebook and similar. Considering the [save] situation, there is a technical specification GEGL that can help things. Realizing it would make it possible for GIMP to implement a workflow where saving explicitly is never needed. https://mail.gnome.org/archives/gegl-developer-list/2012-June/msg4.html I encourage everyone who wish to contribute to the future of GIMP to find ways to help realize these or other strategies fix the fundamental problems at hand. Arguing about the keyboard shortcut used for export does nothing to positively improve the situation in any significant way. In fact it kills the motivation of developers who are putting sizable parts of their life into creating, maintaining and improving GIMP. When you kill motivation in volunteer-driven project, you are not just destroying someones hobby - the project will eventually stagnate, wither and die. I am done arguing. Lets work to make GIMP-based workflows that currently include export/save inefficiencies better. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
On 20 June 2012 22:04, Jay Smith wrote: > People seem to learn best from adversity. If you corrupt your own image > file and did not make a pre-editing backup copy, you just might learn > something. However, if that same user is "protected" from doing something > stupid, then the user will learn nothing. They will not become a better > user. There is a fine line between successfully using the software and > everything being a "learning by making mistakes" experience. However, if > users are coddled, you will simply end up with users that become > progressively even more ignorant. If users choose not to read warnings or > don't take the time to think about and comprehend the meaning of warnings, > then maybe the users deserve the spanking that they will receive as a result > of their own action / inaction. Or is spanking illegal now too? I do not believe punishment is not a good foundation for teaching users of software. While perhaps effective in isolation as a teaching tool, basing the teaching method on it will lead to users being worried or fearful (due to receiving or anticipating punishment) more often. We want people to enjoy their tools, not fear them. Furthermore it encourages dangerous arguments around interaction design decisions like "we need to teach the user" -> "we need to punish him for wrong behavior" -> "there needs to be ample opportunity for wrong behavior" (otherwise he will not learn). People also learn best when different outcomes follow clearly from difference actions. The new model of save/export/overwrite makes this clearer: save will now _always_ save all your data, export will never. > [Not a serious suggestion] Maybe Gimp should, upon opening a file, make an > archival copy of that file so that he user who fails to make a pre-editing > backup copy, the user will be protected from his/herself. Making a "pre-editing backup copy" shall not be necessary in the first place. Just follow the model that opened files cannot be changed in a non-destructive fashion. We are not there in the general case yet, but for the workflow you describe below, we are already there. And we have made this more clear in 2.8+ Open file "myfile.png" -> work -> Export As "myfile_withchange.png" > Unless something is done to arrive at a reasonable solution, my only remedy > for my company is to lock down Gimp upgrades at the pre-change (save/export > mess) level. When the time comes when the "old" Gimp will no longer run on > our workstations, we will have to switch to another program ... and retrain > staff on that other program. It is a real shame. I would much prefer that > my staff would be able to use one SINGLE program for both highly productive > workflow (open TIFF, make minor tweaks such as Curves, save/close as TIFF) > and major editing/creation work that does need everything that XCF has to > offer. The following article provides information about the workflow in 2.8+, and suggestions how to get the old one back if you really want it: http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
On 17 June 2012 15:24, Robert Krawitz wrote: > On Sun, 17 Jun 2012 12:55:56 +0200, peter sikking wrote: >> >> I am going to summarise it because you are doing some >> catching up in there that bloats the mail: >> >> - you recognise that there is a competing situation between >> two different types of use > > There are more than two different types of use. > >> - you say there is a problem with File->Open importing non-GIMP images >> - you have realised that xcf files are great for persisting work and >> are acknowledging the Project reality of graphics work. > > Absolutely. But sometimes the "project" is very simple, such that I'm > very confident I'm not going to need to revisit it (or that I'm just > going to tweak the curves or otherwise do something that doesn't need > layers -- when GIMP has 16 or 32 bit depth, that might be a different > matter, and if I think I might want to revisit it later, I'll simply > save it as an XCF file). > > Certainly there are other tools around that are designed for simple > things like that, but if I'm familiar with GIMP, it's easier to use the > same tool for both. > >> here is my reaction to that: >> >> in short you want the old situation back, with the clear and >> unambiguous working-on-a-GIMP-file workflows being secondary >> to the one-shot png-in, png-out (same for jpeg, tiff, etc) >> workflows. this is clear from how you label the menus. >> >> I have two reasons to say: no way. >> >> the first one is how GIMP works: it can only edit GIMP files. >> sure, this is a superset of the simple file formats that we all like >> to take as examples: jpeg/png/tiff. it is not for other ones >> (ps to start with, there must be more import/export supported >> formats that have things GIMP cannot do). the old fudge that >> we got rid of in 2.8 is GIMP communicating that it is editing >> a non-GIMP file, when it is not. > > How GIMP operates *internally* and what it presents to the user don't > have to be one and the same. Libre/OpenOffice use ODF as the native > file format, but if I want to save it as a Word file, I simply Save As, > or Save if what I originally opened was a Word file. Internally, > though, I believe it's operating on (a representation of) an ODF file. You are right that there does not need to be a direct match between the application internals and what is presented to the user. What is important is that the user interface does not give any expectations that the application cannot fulfill. When LibreOffice allows you to save your work as a Word document, it is making the user expect that the work (not just a subset of it) is saved. In the case of GIMP and "saving to" PNG/JPEG that is not an expectation it can fulfill. >> so you either import/export into GIMP format at the boundaries >> of the GIMP app and be clear about it. this is what we do now. >> >> or you do your plan, build in non-GIMP-file-workflows, where for >> each non-GIMP file type, you have to build a mode for GIMP where >> what is on the screen matches what is in the file, right after >> invoking Save. remember, this is the law. > > Why is that the "law"? If I'm saving as a JPEG, I know that there will > be loss. But that's my lookout. > >> the second reason for saying no is checking the vision >> and what it means: >> >> <http://gui.gimp.org/index.php?title=Vision_briefing> >> >> this makes me 100% sure that the Project/Work workflow >> with persisted GIMP files is number one for our target >> user groups. one-shot working is a distant second. > > That's fine, but how does preventing "Save" to a JPEG file interfere > with that? Your target audience knows that a JPEG file will lose > information. The target audience knows that JPEG will lose information. But if one is basing the interaction design on that foundation, the user will be required to not only know this, but to always keep this information in mind when interacting with the software. Is this a burden we want to put on the user? Will he always make the right decision? Is it responsible software engineering to assume so? > What it does is require using a separate operation for > exporting, which would seem to get in the way of "speed, speed, speed". Triggering an "export" or "overwrite" action (once you have set up the key binding) is just as fast as a "save action". -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
On 16 June 2012 18:54, Nicolas Robidoux wrote: >> - to really Save the contents of the file has to match what is >> on the screen (save, quit, restart, open file: no change--undo >> history excepted). this is not just a good idea, this is the law. >> breaking the law: usability blooper. > > Indeed, if "Save is lossless" is a law, "Save" has to be to XCF, and > something else has to be used to "save" to any other format. > > Nonetheless, I can't help but think that few people would buy a gun > that makes it hard to shoot yourself in the foot. > > No matter how sensical the feature. Most guns I know have the very sensible feature of a safety switch. It does make it harder to accidentally shoot oneself in the foot, but I have not heard very many people complain about it. Most guns also have a shield in front of the trigger, and require a substantial force to actually trigger. The ease of shooting oneself in the foot is severely hampered by this, but again I do not see many complain about it. > Because most of us like to shoot first and ask questions later. I think that "better safe than sorry" is a more sensible approach. One can in general not revive dead peop^Wdocuments. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On 3 June 2012 23:11, Jacek Poplawski wrote: > On Sun, Jun 3, 2012 at 10:58 PM, Øyvind Kolås wrote: >> >> Caching the LUTs sounds like an optimization that should go in directly, >> though I doubt that is what is taking most of the time. > > > Well my primary concern is - are gimp developers at all interested in any > work on improving c2g. The maintainer (of GEGL) has here expressed an interest in getting this optimization in - that is a pretty strong yes. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On 1 June 2012 17:55, Jacek Poplawski wrote: > hello, > > I like the effect of c2g operation available in GIMP for a long time, lots > of people use it for kind of "HDR" effect but I think it's nice way to > increase local contrast of some specific areas of photo or add nice looking > noise > However, the main problem of current implementation of c2g is its > inefficiency, it takes a lot of time to process standard size photo. > > I am author of delaboratory and I started implementing c2g-like operation in > my project, after few days I was able to achieve something similar to > GIMP/GeGL c2g but much faster. Hi Jacek, c2g is a GEGL operation. You will find it in operations/common/c2g.c in the GEGL tree. I would recommend first finding out what causes the current slowness you experience: Is it the GEGL integration in GIMP? (compare c2g usage in GIMP with using GEGL directly). Is it due to some overhead in GEGL core? Or maybe there is room for optimization in the operation itself? > I would like to implement something like that to GIMP. I don't want to > modify existing c2g code, because I assume current implementation is well > designed (mathematicaly) and should stay. So it would be nice to create > something like "simple c2g" or "c2g lite" or just "local contrast boost" > operation. > > My question is - are you interested at all in this kind of code? Will it be > accepted in GIMP? Because my main concern is that I don't want to implement > something which will never be used. I am not aware of current state of > project (I mean project management, not code) and I don't know what's the > process of submitting code to GIMP/GeGL right now. If you are going to do a new operation, the right way to do it is in GEGL. GIMP and others can then use it. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Cross-application work-flows and document file formats
ing the render. 3. Make GIMP expose the documents it is currently working to Blender, and let Blender provide a UI for importing these. Benefit: No longer necessary to find the file on disk, or even know that it is an .xcf file 4. Make GIMP expose changes to the active documents, and let Blender automatically update the texture when it has changed. Benefit: Don't have to explicitly refresh the texture inside Blender. 5. Implement 2-4 for GIMP itself. Benefit: When the texture is a derivative work of other documents, those links will also be easy to establish and maintain. > Task no 1 is often based on images prepared using 2,3,4 beforehand. This > means that a *vast* majority of saves and opens fall into categories > where xcf seriously slows you down. Point 5. above would directly address that as well. There are some technical challenges to implement these steps, but they are all doable. And I believe that they have a much higher potential to improving this work-flow (and similar ones) than making it easier to save PNG files. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] hesitant about compiling a list...
On 17 May 2012 16:19, peter sikking wrote: > a couple of days ago Bruce appeared on irc and we had a chat. > (Bruce is now subscribed to this list) > > within a minute we were talking about whether GIMP has a list > of known UI design issues. as far as I know we do not have one, > it is certainly not part of gui.gimp.org. > - just thinking of what I can contribute to this list, I know > that this list is _not_ going to be short. also because all the > issues that I can put on it are ‘medium level to big-picture,’ > none of them are going to be trivial to solve. thus my hesitation > is what this is going to make GIMP look like, and if the definitions > of open worked where meant to stretch this far. > > - all of the issues that will end up on the list have been > created by contributors to GIMP. some of these issues have been > created 10 years ago, some of them last month. I wonder what it > will feel like to GIMP contributors when something they just made, > almost ‘immediately and automatically,’ (at least, feels like that > to them) ends up on the UI issue list. I support creating such a list. If we hope to solve these issues, and keeping the amount of similar issues we introduce down, they need to be visible for all to see. Being open is about transparency and accountability. And it is just as important, or more, that we act in such a way with respect to our problems. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On 18 May 2012 11:18, Alexandre Prokoudine wrote: > On Fri, May 18, 2012 at 12:59 PM, gfxuser wrote: > >> I wouldn't say that. On Windows 7 the native 'open file' dialog contains >> different views: list, details, symbols in various sizes, tiles. > > This is exactly what I was referring to. > > There's no need to sit down and create a patch for GTK+ which GTK+ > team probably doesn't even want, when you could use native dialogs. > Personally I've no special opinion on native vs. GTK+ dialogs on > Windows. As a non-Windows user I'm fine with both :) Please fix GTK+ instead of using some platforms native dialog in GIMP. That way it will work for all GTK+ based applications and on all operating systems supported by GTK+. Remember also that GtkFileChooser is the native dialog for GNOME (and XFCE). Some work was done recently, but never ended up in mainline. https://bugzilla.gnome.org/show_bug.cgi?id=141154 -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] new interaction project starting...
On 14 May 2012 07:21, peter sikking wrote: > I wrote: > >> Marinus Schraal, from Holland, will be with us for the next 10 weeks. >> his project subject will be picked by him in the next couple of days. >> if you see ‘foser’ on irc, that’s him. he will be happy to talk to >> you about it. Thats great! > update: > > Marinus had talks with you on irc in the last couple of days > about possible topics. > > this morning on irc we talked through the scope, size and impact > of these possible topics. > > then Marinus picked the topic for his project: A small suggestion on work-flow: Ask Marinus to subscribe to the mailing list and to post the question he has himself here. This makes the interaction between the designers doing the work and the rest of the project more direct, which I believe is the best. As discussed in Vienna... -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] GEGL porting matrix
On 10 May 2012 17:31, Alexandre Prokoudine wrote: > On Fri, May 11, 2012 at 3:02 AM, Jon Nordby wrote: > >>> I've just created >>> http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL and >>> filled it with initial data to help us tracking progress of the >>> porting GIMP stuff to GEGL. >> >> Is OpenRaster really the only file handler that needs porting to GEGL? >> Every other format is covered? > > Of course not :) Have some more, on the house :) > > I could add some more. Great, thanks for putting together the initial document. If there are any pieces of code we know that we do not especially want to port, it could be useful to put them in a table too with a short comment/explanation. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] GEGL porting matrix
On 7 May 2012 02:31, Alexandre Prokoudine wrote: > Hi folks, > > I've just created > http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL and > filled it with initial data to help us tracking progress of the > porting GIMP stuff to GEGL. Is OpenRaster really the only file handler that needs porting to GEGL? Every other format is covered? I'll assist anyone interested in working on getting OpenRaster support into GEGL. For applications like GIMP and MyPaint with "full" OpenRaster support it will probably make sense to keep the existing ORA implementations though, as they want to integrate it with their document model (which is built on top of GEGL). -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
