Rod wrote:Is the new Matting tool going to be introduced in GIMP-2.10?
Yes, most likely. It's by no means complete:we still need to improve the user interaction aspect at the very least. But it's unlikely that we will roll back changes there.
MareroQ wrote:However, I have not found information about solving the problem loading script-fu (too long - without visualization of progress).
The way Script-Fu is executed makes it difficult to add preview. We'd like to improve that, of course, we just don't have any particular plans at the moment. Kevin Cozens would explain that better, but I'm not sure if he's on this forum.
K1TesseraEna wrote:1. Quote ...a basic loader of OpenEXR loader... Must be a typo?
Will it support/save multilayer EXR? I'm a Blender user.
Yes, a typo. And yes, we'd like to have a complete OpenEXR plugin. It was among
Google Summer of Code project ideas this year. So it's on radar, but needs a developer.
K1TesseraEna wrote:2. What was the deciding factor to go with OpenCL (vs OpenGL) - less coding, better computation times with GEGL ops, etc?
With OpenCL you get handy things like multithreading etc. See
http://www.slideshare.net/lgworld/imple ... l-and-gimp.
K1TesseraEna wrote:This may not directly relate to the summary, however, out of curiosity:
3. Why is CMYK support a low priority?
Before we can work on advanced CMYK support, the foundation (GEGL port) should be done. That automatically means v3.2 at the very least (v3.0 is reserved for GTK+3 port that should restore Wacom support for Windows users). But then you need to consider a few things:
1) We aim to provide tools to different kinds of users. E.g. both photographers, graphic designers, 3D artists, scientists, and desktop publishing professionals need non-destructive editing, but it's mostly the latter who need advanced CMYK (and spot colors) support. So between a) giving much required tools to everyone, then taking care of industry-specific things one by one, and b) giving industry-specific tools to a much smaller group of users while making everybody else wait, our choice is a).
There are other similar considerations like fixing the abomination which is the floating selection
, or the auto-expansion of images (try rotating a layer that's the size of an image -- currently, GIMP permanently clips the content that goes out of bound).
2) None of us are currently awesome at desktop publishing. It's a very specific expertise, and the feature needs a very careful treatment.
Together, that makes advanced CMYK support a low priority. I hope the explanation was clear enough
It's is absolutely possible to make those priorities shift though. For instance, we weren't planning the Unified Transform tool to be as early as part of v2.10, but then we got a dedicated developer who was really committed to making that happen (Mikael did a lot of preliminary work before he chose it as his GSoC2012 project).
So advanced CMYK support in e.g. v3.2 is a possibility in case, similarly, a committed developer stops by to work on that (another prerequisite is that Peter Sikking's usability team has the time/funds for the work with that developer).
K1TesseraEna wrote:4. Why RAW files support is not even on the roadmap?
I don't think we ever discussed that feature long enough. Actually, GEGL already reads various RAW files via libopenraw. So it's kind of done already (it's just several lines of code to add direct RAW files opening via GEGL to GIMP), and in a future non-destructive workflow the kind of interaction that is between Photoshop and ACR, that is, using RAW files as smart objects, would just work in GIMP.
However, again, there are a few considerations here as well:
1) Hubert is currently on his tod with libopenraw, unlike e.g. Rawspeed library that is taken care of by two teams -- Rawstudio and darktable. I can't say how complete it is at this point.
2) Just opening RAW files wouldn't do. You'd also need all sorts of processing features such as hot pixel suppression. Currently we have noone to work on that. One of the ideas was to somehow join forces with the darktable team, but no plans were ever made.
K1TesseraEna wrote:IIUC, Separate+ and UFRaw will have to be ported to GEGL to be able work in 2.10 onward,
and I don't expect it happening anytime soon - both plugins are mostly abandoned by their developers.
Not entirely true
If you have a closer look at the
changes in UFRaw here, you'll see some progress towards making UFraw compatibe with GIMP 2.9-2.10 already. So UFRaw is at least maintained even if not actively developed. Can't speak for separate+ though; indeed, it's been a while since I last heard from Yoshinori-san.
K1TesseraEna wrote:In fact, Separate+ already isn't working in GIMP 2.8.10 on Windows
Any specifics?
K1TesseraEna wrote:GIMP has become a sophisticated piece of software but, after having the numerous discussions with PS and GIMP users, the common opinion is that GIMP can't be considered a 'complete' photo-editing tool without these features.
Your thoughts?
Er, patience is a virtue, perhaps?