Re: [Gegl-developer] [Gimp-developer] babl roadmap
Hi, I fully agree with Jehan and think it's essential in a healthy software development process to scrutinize and review things. Especially the whole color management stuff is a topic that is not so clear to many of us and - with all my respect to Pippin - depending on a single expert's opinion is a risk in every project. It's natural for this topic that it is also academic. Academic work is the foundation for many things in the computer world, may the hands-on-people like it or not. Perhaps some other color management experts could join in and share their knowledge? One thing could be improved from my point of view: the discussion is spread over the two lists gimp-developer and gegl-developer. As it is all mainly BABL- and GEGL-related it would be more helpful if the discussion took place on a single list. I propose the GEGL-developer list, because this catches both the GEGL-only devs as well as the GIMP devs. Kind regards Sven ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [PATCH 2/2] opencl: Load extension function in a portable way.
Hi Jan, I see you are eagerly taking care for the OpenCL topic and think that's a good idea that doesn't deserve bitrotting on a mailing list. To increase the chances that your contributions get the attention they deserve I think it would be a good idea to: - come to irc.gimp.org, channel #gegl and poke the GEGL developers there. IMHO daniel_s, massimo, victorm and pippin are the right people to talk to. - contribute your patches as described here: https://wiki.gnome.org/Git/Developers#Contributing_patches This means to either contribute patches by Bugzilla (https://bugzilla.gnome.org) where they can get reviewed, or to get a GNOME Git account, push your patches to a GEGL branch, discuss and merge/cherry-pick them to GEGL master. Thank you for your efforts and good luck! Sven ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] GEGL-master build on Jenkins fails
Good job, Michael ;-) On 10.8.2014 at 7:35 PM Michael Henning wrote: No need to use old revisions. It's fixed now. :) commit bfb03d9b34b5607ff33ea688fc078b656672ffae Author: Michael Henning Date: Sun Aug 10 12:45:05 2014 -0400 tests/simple: Don't call gegl_color_new until after gegl_init If you call gegl_color_new before gegl_init, it will now try to call babl before babl was initialized and segfault. On Sun, Aug 10, 2014 at 2:54 AM, scl scl.gp...@gmail.com wrote: Hi, the gegl-master build on Jenkins fails, see https://build.gimp.org/job/gegl-master/565/console For latest changes see https://build.gimp.org/job/gegl-master/565/ Maintainer resp. latest committer, please fix it. Contributors who want to use the latest stable version are recommended to build GEGL revision 1fd50fd390aae0abb33b8c94ce37e80a31e6752a Kind regards, Sven ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [PATCH 1/1] cl: Make noise-simplex kernel OpenCL 1.1 complaint
Hi Jan, my local 'make check' tests passed and the GEGL developers had no objections, so I've committed your patch to GEGL master. Thank you for your contribution and feel free to continue your work! Greetings, Sven ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] Getting contributors via OpenHatch
Hi, lately somebody committed to [OpenHatch] spoke to me in IRC whether we at GIMP want to work with OpenHatch to gain more contributors. OpenHatch defines itself as 'a non-profit organization with the goals of lowering the barriers to entry into open source community and increasing diversity'. They also teach the next generation of students on colleges how to participate in open source communities, so 'Hello, next GSOC students'. I personally think it's a great chance to get some open problems solved: To push the things a bit forward: - Can we mark some more trivial and gnome-love bugs? - Is anybody willing to mentor some students or give a classroom presentation and if yes in which topic/area? - Are there any topics we've been putting off, neglecting or just plain avoiding? - IMHO the GEGL ports and Windows bugs need some care. If we have this, we can update [GIMP's and GEGL's pages there]. I'm cross-posting this message to the GIMP and GEGL developer lists, because I think also GEGL could benefit from it. Kind regards, Sven [OpenHatch]: https://openhatch.org/ [GIMP's and GEGL's pages there]: https://openhatch.org/projects/GIMP https://openhatch.org/projects/Gegl ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] Changes in continuous integration server
Hi, our continuous integration server Jenkins has got a new address. You can now access it via https://build.gimp.org. Please update your bookmarks. I'd like to thank Cameron Gregory, Andrea Veri and Mitch for their efforts and contributions. If you face trouble with the new address, feel free to let me know. Greetings, Sven ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] Fwd: Re: [CREATE] OpenRaster specification: updates to support masking
Hi, the following discussion on the CREATE mailing list looks relevant for GIMP and GEGL, so I'd like to point you to this. For those who don't know about OpenRaster: it's a graphical interchange format for raster-based applications. Currently MyPain and Drawpile use it and for GIMP there is an [OpenRaster plug-in]. Perhaps the topic is sth. for LGM, too. Kind regards, Sven [OpenRaster plug-in]: http://registry.gimp.org/taxonomy/term/797 On 17.1.2014 at 11:08 PM Andrew Chadwick wrote: There is now some working code to test this concept out! → https://gitorious.org/mypaint/achadwick-mypaint/commits/layer-enhancements-exp This partially implements the proposal at → https://gist.github.com/achadwick/7827931 To mask with this branch, open the layers panel, then drag a layer into another layer to start building structure, Group ├ Layer 1 └ Layer 2 then draw a mask in pure white in the top layer and something you want to mask in the lower layer in any colour you like. Set the top layer's compositing mode to Destination In using the right button menu, and the bottom layer (and anything else in the group) will be masked by the top layer. You may need to refresh the view by dragging it around a bit at the moment, but this annoyance should be gone soon. (It has to be in a group because MyPaint does non-isolated rendering onto its internal background layer. Currently you see black if a layer erases the background layer... The layer group implementation you see here uses isolated rendering only, however, and the results of that are then composited onto the background normally. This is just a workaround for now, allowing some masking experiments.) On 13 December 2013 12:01, Boudewijn Rempt b...@valdyas.org wrote: I firmly intend to look into this into detail -- I'm not forgetting about it :-) On Friday 06 December 2013 Dec 16:49:10 Andrew Chadwick wrote: I'm in the process of (slowly and experimentally) refactoring the layers code in MyPaint to add a bunch of fancy features like masking, nested layers, and layer formats other than raster (but which either rasterize (like SVG) or can be represented usefully as an icon (like basically nothing right now)). I've noticed that the OpenRaster specification will need to be updated to support the Porter-Duff in operator, and I'd like to take the opportunity to allow sub-stacks to be composited with user-specifiable blending and compositing operators. Conveniently enough, the W3C Compositing and Blending Level 1 specification has evolved into a very helpful and complete form, and defines neatly an important aspect of how groups in formats like SVG - equivalent to our nested stacks - should be expected to render. Therefore I'd like to update the OpenRaster draft specification[1] in accordance with the attached proposal. See https://gist.github.com/achadwick/7827931 in case the attachment hasn't made it through the mailing list software. [1] http://www.freedesktop.org/wiki/Specifications/OpenRaster/Draft -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl ___ CREATE mailing list cre...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create -- Andrew Chadwick ___ CREATE mailing list cre...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Gegl Operation : Retinex
Hi, On 18.12.2013 at 10:29 PM Joao S. O. Bueno wrote: It looks like this still remains to be rewritten for GEGL? Looking at the [GEGL porting matrix] you are right. (what lead me to do this? I've hit the retinex filter description while translating the GIMP manual, and went happily to gimp master to check how retinex would behave in a 32 bit per channel image - just to find it was not there) I just tried with a quite current master build on Linux and found it at the end of the Colors menu. You can find the code in GIMP 2.8 and master sources - it's /plug-ins/common/contrast-retinex.c. I looked in the help and found the [webpage of the plug-ins author]. It seems the algorithm dates back to 1996, which is quite old and in the meantime there happened [further research] about the topic. IMHO to go with GIMPs product vision to provide cutting-edge and fast algorithms it should considered to first check whether now exist improvements to the 1996 Retinex algorithm (resp. Rahman Tone-mapping operator). Perhaps there's also something usable in the former years' GSOC GEGL branches. The best would surely be if the potential contributor came to IRC and spoke with the devs. Kind regards, Sven [GEGL porting matrix]: http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL [webpage of the plug-ins author]: http://www-prima.inrialpes.fr/pelisson/MSRCR.php [further research]: http://scholar.google.com/scholar?q=multiscale+retinexhl=deas_sdt=1%2C5as_ylo=1996as_yhi=2013 ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] VIPS library
Hi,
these days I was pointed to the [VIPS library].
It's an image processing library with a focus
on high performance and low memory consumption.
Given this it can address two basic requirements
of image editing software:
- working fastly, i.e. see the [GIMP product vision],
- increasing image size as result from increasing
camera sensor resolution.
VIPS' main features include i.e. a wide range of
image file formats and colour formats, optional
inclusion of LCMS, almost complete support for
non-destructive editing and a great amount of
[image-processing operations]. From a developers
point of view a clever, low-memory architecture
('demand-driven' processing) and multi-threading
are some points of it. It's open source
and free under the LGPL 2.1.
I explicitly don't argue to make GEGL obsolete.
My aim is to share this information with you.
I already saw, 0yvind has dealed with VIPS and
the topic came up here some times during the last years.
Currently the only two points where I find hints
to VIPS in GEGL are N. Robidoux' lowhalo and nohalo
samplers. But perhaps the library can provide us more
and can take some work from us by using it in GEGL
or giving us some inspiration.
Kind regards,
Sven
[VIPS library:
http://www.vips.ecs.soton.ac.uk/index.php?title=Libvips
https://github.com/jcupitt/libvips
[GIMP product vision]:
http://gui.gimp.org/index.php/Vision_briefing
[image-processing operations]:
http://www.vips.ecs.soton.ac.uk/supported/current/doc/html/libvips/index.html
___
gegl-developer-list mailing list
List address:gegl-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] Wiki: new 'Problems and solutions' page
Hi, I added a new page for developers problems and solutions to the wiki: http://wiki.gimp.org/index.php/Hacking:Problems_and_solutions May it be a good help for us all. Feel free to update with your own findings. Kind regards, Sven ___ gegl-developer-list mailing list gegl-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Qt bindings and gegl_node_set*
On 28.06.13 at 02:19 AM Jon Nordby wrote: Ok, these two things should be fixed in master now. Thank you Jon, for fixing it so quickly despite your own strained situation. With that being said, it would be nice if the Jenkins job could also trigger on a for-master, integration or test branch, if people would like to test their changes outside of master. Yes, it's a good idea to have separate branches for work in progress and to merge only a finished state into the 'master' branch. I propose to name them 'feat-$Featurename'. It's similar in GIMP and GEGL: the GSOC work is done in separate branches that start with 'soc-'. If I see such branches in GEGL-Qts Git repo, I can create new Jenkins build jobs for them. Kind regards, Sven ___ gegl-developer-list mailing list gegl-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] GSoC 2013 project page
Hi, I updated the GSoC 2013 project page in our developer wiki: http://wiki.gimp.org/index.php/Hacking:GSoC/2013/Ideas Now it contains for every project student, mentor, status, a short description and useful links to specs, former discussions, sources, its continuous integration site and more. Students, mentors and all other involved feel free to update and edit to your further needs. Good luck and have fun. Kind regards, Sven ___ gegl-developer-list mailing list gegl-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] [RESOLVED] Building GEGL fails on 64 bit Linux system
Thanks to pippin and Massimo the bug is fixed. It turned out that different versions of libjpeg was causing it. Using a PNG image in the test proves more stable. Kind regards, Sven ___ gegl-developer-list mailing list gegl-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gegl-developer-list
