Re: [Gimp-developer] Dog-bone

[Simon Budig]

Hi John.

John Tapsell via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> I love the path effects, and there's a particularly useful path effect that
> I use all the time:
> 
> Corners (Fillet/Chamfer)

Are you sure you're reaching out to the right mailing list? I am unaware
of having "path effects" in GIMP...

Possibly you wanted to reach out to the inkscape developers?

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Python vs Scheme

[Simon Budig]

Hi Massimo.

Massimo Fidanza via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> in the source archive there are 51 .scm scripts and 11 .py Scheme scripts
> has a complex syntax and I do not know how much it is used today. What are
> the advantages of Scheme compared to Python? Would it make sense to rewrite
> plugins that still use Scheme in Python and remove the Scheme language?

The main advantage of scheme is, that we can easily ship the interpreter
within gimp. With python we'll always depend on an external python
installation.

Yeah, scheme sometimes can be a bit optuse, but in my eyes having an
interpreter within the gimp distribution is a strong point to consider.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 Open Ports

[Simon Budig]

Hi Estefania.

Hernandez, Estefania [USA] via gimp-developer-list 
(gimp-developer-list@gnome.org) wrote:
> Good afternoon,
> 
> I recently scanned GIMP and noticed that GIMP uses TCP 2177.
> 
> I was wondering if I could get information on TCP 2177, such as, what is the 
> purpose of TCP 2177?

I am right now unaware of gimp opening a port.

Did you install Gimp from the official packages referenced at
https://www.gimp.org/downloads/ ?

In the past there have been instances of unofficial installers, which
bundled unwanted addons or even malware. Please make sure to only use
official installers.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 in the textile industry: handling of indexed colors

[Simon Budig]

Hi all.

Please see my previous mail for more context of this problem.

So here we go about the handling of colors in indexed images:

In the current toolchain for the carpets the images are indexed, i.e.
instead of RGB data per pixel each pixel stores an index into a color
palette.

At the company it is important to have good tools to manipulate color
palettes and I think there definitely is room in GIMP for a plugin that
provides advanced control over the colors contained in a project
specific palette as well as tools to control names and order of the
color entries.

In GIMP color palettes are available and they also can carry names. But
while you can use these palettes to create indexed images, the indexed
image itself carries a "colormap" which does not provide named colors.
It would be necessary to extend the core to store names associated to
the indexed colors. A small sideproject then is to make sure that these
color names also end up in the final resulting image, one thought there
was to define and write a specific text chunk into a PNG file that
provides advanced information about the palette.

I personally think that this would be a welcome addtition to GIMP. It
also is a project that is not too huge and might be beneficial to other
usecases as well.

I'd welcome input on that topic.

Bye,
 Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Using GIMP in the textile industry

[Simon Budig]

Hi all.

Please see my previous mail for more context of this problem.

Working with indexed images:

I witnessed one very funky way of working with indexed images and I am
not sure if I have fully wrapped my head around the ways they use some
features of the proprietary tool they're using now.

The tool in question does not provide multiple layers, but it does have
some sort of floating selection. It however has funky means of dealing
with indexed images. For each entry in the color palette you can
  a) set the resp. color to transparency  and
  b) protect specific colors

I've seen these features used in various workflows:

* If you want to extend a patterned area you'd drag the pattern onto the
canvas and roughly align it to an already patterned area. You'd then
swich some colors to transparency, making it easier to align the
patterns in a pixel exact manner. To actually do the expansion of the
patterns you'd then make the colors visible again and drag on the
bounding box of the pattern to extend it into the desired areas. That
way it is ensured that the alignment of the new area fits the old area
pixel perfectly.

* if you want to combine a decor element of a pattern over a different
pattern (with the same repeating properties) you can place the new
pattern on top of the old one, then protect certain colors of the old
pattern and expand the area of the new pattern by dragging on the
bounding box. This basically places the new pattern "behind" certain
areas (as defined by the protected colors) of the old pattern. This also
can be used in conjunction with swiching some colors of the new pattern
to transparent, making parts of the new pattern invisible.

As I said, I was kind of swamped by the speed the operator toggled the
properties of the different indexed colors and it was hard to judge what
she actually was trying to do.

I kind of suspect that it is worth evaluating if there are more
straightforward ways to arrive at the same goal of the workflow, but
right now I do not have specific ideas there. That having said: being
able to "protect" some indexed colors (in a similiar way to a protected
alpha channel maybe?) as well as temporarily making some indexed colors
invisible/transparent might be helpful to other pixel based artists as
well. Opinions?

An interesting side problem is: If we had patterns with indexed colors
and would want to use them in an indexed image - how could we go about
mapping the two palettes to each other?

I'd welcome input on that topic.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Using GIMP in the textile industry: Document Management

[Simon Budig]

Hi all.

Please see my previous mail for more context of this problem.

Integration into a Document Management System

It will be necessary to incorporate GIMP into a site specific Document
Management System. I kind of suspect that this will end up being either
a separate plugin to access the files within the DMS. As of now I am
unsure what is needed there exactly and if it maybe is feasible to
develop something a bit more flexible, allowing for an integration into
different DMS backends. This very well might end up in a customer
specific plugin. If someone more familiar with DMS's than me has any
input on that I'd be glad.

I'd welcome input on that topic.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Using GIMP in the textile industry

[Simon Budig]

Hi all.

Please see my previous mail for more context of this problem.

In the textile industry working with patterns is hugely important:

One quite important aspect of designing carpets is dealing with
patterns. The kind of projects we're talking about here is of the scale
"print carpet for a whole building, adhering to a common design across
the building".

So the layout of the building is known and the area of the floors gets
"sliced up" in advance so that it is known, which part of the room will
be filled with what part of the carpet run. It is vital that the
patterning of the carpet will seamlessly match when the carpet runs are
finally placed in the building.

In GIMP the fill tool provides no control over how a pattern is placed
in the selection to be filled, which in this context obviously is a huge
problem. I imagine it should be feasible to provide on canvas controls
for the fill tool, allowing to move a pattern around and to finetune how
a pattern is placed inside the selection.

I also saw other workflows where they worked with patterns dragged onto
the canvas and subsequently being expanded onto the image by dragging on
the pattern bounding box. The pattern in this case would be "locked"
into a specific position. One application is to place a pattern for a
trim on the carpet and then expand it in a repeating manner across one
side of the carpet.
I am not sure if this is a feasible thing for GIMP.

I'd welcome input on that topic.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Using GIMP in the textile industry

[Simon Budig]

Hi all.

Please see my previous mail for more context of this problem.

We also discussed some changes to the UI:

The company representative I was talking to was also concerned about the
amount of functionality in the GIMPs UI and fears that it might be
overwhelming to the operators, plus that it also makes it easy to use
functionality that actually is harmful to the task at hand. I explained
that it is possible to reduce the amount of stuff shown on screen
(including making specific tools invisible, possibly even changing XML
files to reduce the number of menu entries), but also mentioned that
we're not too keen on having that, since it possibly increases the
support ballast for our community. It remains to be evaluated how much
changes are actually needed there.

One thing which came up though (and which we already have discussed in
the past IIRC) is the need for a better support for multiple documents
in single window mode. The software they're using currently is using a
classic Windows Multiple Documents Interface (MDI) and they do in fact
make use of it. I tried to explain why I personally consider GIMPs
multiple window interface as quite good, but the not-so-great support
for multiple desktops in windows (and the bad window management) made
this a tough point to sell...  :)

I see two options here and I think we've been discussing these in the
past.
  a) create multiple side-by-side image views within the single window
 mode. We could allow for tiling the image area into multiple
 notebooks, each containing its own set of images, allowing for
 Drag'n'Drop between them etc. ppp. My gut feeling is that this
 should be quite doable. It might be a bit tricky to control the
 keyboard focus there and to make it clear to the user, which of the
 images will be affected by the next keystroke.

  b) (not necessary XOR) it might be feasible to allow for a kind of
 hybrid single/multiple window mode, where one can drag out notebook-tabs
 into their own image view that then is managed by the window
 manager. So we would have one dedicated main window containing the
 toolbox and the notebook-area with image views as well as separate
 windows containing image views (or a notebook of image views?).

Not sure how much consensus we have on this point and what amount of
effort is needed here.

Another thing related to the UI was to have a dockable, which would
contain a configurable set of buttons referring to specific actions (as
in "menu items"). That might be a handy thing for quickly acessing
frequently used functionality.

Another thing was a histogram for indexed images: Obviously counting the
indexed colors is important to calcuate the amount of color needed for
the carpet. The current histogram dockable could be extended with a more
tabular view for indexed images.

I'd welcome input on that topic.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] What would it take to add an option for the Pencil tool to support brush transparency? (James Houx)

[Simon Budig]

James Houx via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> How difficult would it be to modify the pencil tool to support transparency?

the regular paintbrush and the pencil tool are both using the
gimppaintcore for painting the brushes. The difference between pencil
and paintbrush is controlled by the "brush mode" property of the paint
options. If it is == GIMP_BRUSH_HARD then the pencil behaviour is used.

In app/paint/gimpbrushcore.c this is used to request the "solidified"
variant of the brush, in app/paint/gimppaintcore.c it is used to round
the coordinates.

If you want to just change it in your personal copy without changes to
the UI it seems to be fairly trivial. If you want to offer a UI it might
be a bit trickier, but it should be doable.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] A Process for Each Plugin

[Simon Budig]

Hi Ahmad.

Ahmad Nouralizadeh via gimp-developer-list (gimp-developer-list@gnome.org) 
wrote:
> I wonder why GIMP spawns a separate process for each plugin (e.g., by
> calling g_spawn_async() @app/plug-in/gimpplugin.c:368). For example, I
> opened an image and the contents of the image was loaded in the memory of
> process gimp. But when I applied a VanGogh filter on the image, a new
> process, van-gogh-lic, started and processed the image contents.

Yes, this is completely as designed and expected.

> - Why another process is forked? AFAIK, a fork is used only for the cases
> when the tasks of the parent and child are completely different.

Having the tasks in different processes has a few advantages:

 * plugins can be small completely separate entities with a very
   specific small scope. This makes them easy to understand and fast to
   develop
 * buggy plugins don't case the main gimp process to crash and burn
 * they work independently of the actual GIMP version.

An alternative would be to create plugins as shared libraries that get
linked into the main application. This might have some complications
with the build process as well as the intricacies of the dynamic
linking. But it would be doable.

> - How does van-gogh-lic access the contents of the image, while it is
> loaded in its parent (i.e., the gimp process)?
> - I also traced the parent process using Pin, which showed that during the
> application of the filter, many accesses were made by gimp. Why?

Plugins use libgimp, which takes up the task of communication with the
main application. There is quite some back and forth between these two
processes using an IPC mechanism. A plugin that invokes a PDB function
basically asks GIMP to do the task.

The actual image data is transferred via shared memory: The two
processes work on the same pixel data, which avoids expensive copying of
data.

In the future more image operations will become GEGL-Ops, This is indeed
a step into "dynamic linking" area, but hopefully the GEGL
infrastructure is good enough to make it reasonably easy to wrap the
head around.

I hope this helps,
 Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Business usage of GIMP

[Simon Budig]

Hi Ivan.

Edgar Iván López via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> We do not sell ads or things related, the only thing we would use your
> software for is in-company communication of events photos, meetings,
> posters and so on.

You're welcome to use GIMP for all the purposes you mentioned. In fact
we do not pose any restrictions on the use of the program.

Certain restrictions apply if you're working with the Source Code of
GIMP, but that does not seem to be the case here.

Please feel free to use GIMP as you wish.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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-web] Alexandre Prokoudine attacks on GIMP critics around the Web

[Simon Budig]

Ryan Stark via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> Ardour is poor and there were lots of DAWs being developed on Linux
> (probably still are but I don't look into it any more). Paul at Ardour is
> arrogant. It doesn't matter if he is funded.

Since on these issues you apparently are the only arbiter on what
determines the success (or not) of software I am going to stop
considering your viewpoint, since something like an productive exchange
seems impossible.

I strongly suspect that we're not going to resolve your issues here and
I doubt that your style of arguing will help in interesting developers
in your issues. Speaking for me as a long-term-although-not-as-active-as-i-
would-like-developer of GIMP I can attest that I certainly have no
interest in pursuing this discussion.

Feel free to stick to your opinion, feel free to put me in your
"arrogant" camp and lets hope that at some point you'll succeed in
finding your software ecosystem adjusted to your needs.

Have a good time.
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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-web] Alexandre Prokoudine attacks on GIMP critics around the Web

[Simon Budig]

Hi Ryan.

Your collection of pet peeves is impressive. Yet I believe that your
generalization that they must affect everybody is blown way out of
proportion.

Ryan Stark via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> So many of Gimp's features seem unfinished. For example, look at the
> guides. There are horizontal and vertical guides similar to Inkscape in
> operation yet no diagonal guides which would be an obvious addition.

Why not go a step further? Have e.g. bezier shaped guides you could
manipulate freely? Wouldn't that be wonderful?

Wait, thats already there. Never mind. What was your point again?

> Applying any dynamics to a brush causes Gimp to go at an absolute snail's
> pace. Why? And why on earth are all those hideous brushes, patterns etc
> still included in Gimp when there are other better and free ones available?
> This makes Gimp look very poor to any new user.

Brushes and Patterns may get referenced by user scripts. We consider it
a bad thing to break compatibility for no good reason (and "someone
might not like this pattern" is not a good reason).

Suggestions for new good patterns with a clear and unambigous statement
about them being in the public domain are welcome.

> The little sliders to
> adjust values are not very good and text entry is horrible.

Please elaborate.

> You can't go
> from from single window mode to multiple without your layout being messed
> up.

Works for me. What window manager do you use?

> Having a UI like this without being able to save your windows layouts
> is crazy.

My window layout gets remembered. Again: What window manager do you
use?

> I've encountered many bugs and a few crashes in Gimp 2.10 which
> never used to happen. For example there is some kind of problem where
> certain actions with a mouse or pen causes docked tabs to constantly break
> free without reason.

Gimp 2.10 is pretty much rock solid for me. No idea what you're witnessing.

> The problem is that some people may be prepared for a few problems, report
> a few bugs etc but then it just gets tedious and they move to another app.
> I believe many will do this with Gimp.
> As for any contribution I could make, that would only be with using Gimp as
> a painting app and the brushes because I've been through the brush engines
> of just about every app out there. This is why I like Mypaint and the new
> features. However, every time I try to use Gimp I end up in other programs,
> including Clip Paint Studio which I run in Wine. I would much rather use
> Gimp.

But why don't you use the tool that works best for you? Why do you
insist on using Gimp if it is as bad as you claim it to be?

If Clip Paint Studio does everything you need, why switch?

And I do mean this: I stopped evangelizing in favor of Gimp ages ago. If
someone is happy with a tool there is nothing to gain to convince them
to use a different tool, it always results in frustration about the fact
that GIMP is different from the other tool.

And it also leads to a lot of frustration on the developer side, because
we then do get the pressure to align GIMP with the behaviour of the
random other tool, because that is the one true way (tm) on how certain
workflows have to work.

> What are the solutions to these problems? I don't really know but i think
> once some bad design decisions are made with an app it is very hard to fix
> things. The developers or at least some developer who has a vision on how
> to improve things is the most crucial component. I think the problem with a
> lot of software is that the developers do not use the software extensively
> or study how other programs do things.

That is true and this matches our experience. We have a ton of bad
decisions in the GIMP codebase (Images are always 8-bit RGB, right?) and
their legacy haunts us to this very day, although a lot of progress has
been made in the last few years. As for not using our own tool
ourselves: we do know that we have that kind of blind spot, but then we
also have the dialog with our users.

And if the lack of diagonal guides would be as neck-breaking as you make
it sound then we'd have a ton of feedback from all kinds of users about
it. We do have tons of users and it is not very hard to find quite
positive reviews of GIMP. The lack of diagonal guides is not a common
talking point. Neither is the selection of default brushes or weird
behaviour of the gui window management.

I suspect that the problems you see as absolutely crucial are quite
irrelevant for others and easily compensated by the ton of other
features where Gimp works quite well for them. Please try to consider
that before claiming that GIMP is doomed because we do have bad default
brushes.

Thank you.
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: 

Re: [Gimp-developer] small suggestion for consistency

[Simon Budig]

Hi Marco.

Marco Ciampa via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> On Thu, Oct 25, 2018 at 11:37:12AM +0200, Simon Budig wrote:
> > Marco Ciampa via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> > > The menu layer should named layers for consistency with the other
> > > menus like colors, tools, filters.
> > 
> > Would you suggest to change "Image" to "Images" as well?
> 
> No. Image deal with _one_ image at a time. Level deal with one or more
> levels at a time (see below).
> 
> > Both feels wrong to me, since the "Layer" menu mostly deals with actions
> > affecting just one layer (the current one).
> 
> Layer groups are made not of just one layer.
> Same as for a stack of layers.
[...]
> and layers deals with multiple layers in the image, in groups and in a stack.
> 
> ... but this is just an observation and a suggestion ...

I might be missing something obvious, but when looking at the Layer-Menu
I can see one menu entry that affects all layers simultaneously:
Layer->Stack->Reverse Layer order.

All other entries are really quite specific to the currently selected
layer: either by moving it to some other position in the stack,
selecting a layer in a specific relation to the current layer, Change
the current layer size etc...

Granted, some of these implicitely affect the other layers in the stack,
but there always is the one designated layer that the operation is
defined by.

True, if the current layer is a layer group, these operations work on a
set of sub-layers, but that is more an effect of having currently
selected a layer group - the operations still work on the currently
selected item in the layer stack (and its child items).

It feels a little bit like bike shedding, but I still believe that
"Layer" is correct.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] small suggestion for consistency

[Simon Budig]

Marco Ciampa via gimp-developer-list (gimp-developer-list@gnome.org) wrote:
> The menu layer should named layers for consistency with the other
> menus like colors, tools, filters.

Would you suggest to change "Image" to "Images" as well?

Both feels wrong to me, since the "Layer" menu mostly deals with actions
affecting just one layer (the current one).

"Filters" is a collection of multiple filters, "Tools" is a collection
of multiple tools, "Colors" deals with multiple colors in the image.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 branched: new stable branch gimp-2-10

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
> On 05/21/2018 11:13 AM, Jehan Pagès wrote:
> > Just to be clear, the toolkit update here is not*just*  a necessary evil.
> > It will also be totally awesome, even feature-wise!
> 
> 
> 
> > Simply to get there, we have to pass through an "unstable" phase, that's
> > all there is to it.
> 
> Apparently GTK+3.22 is considered "long term stable" (that is, supported for
> three years? starting from when?) and is the last minor release in the GTK+3
> series: 
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

Just to clarify, the "unstable" phase happens because we're migrating
the toolkit, not because the toolkit we're migrating to is unstable...

> Will the port from GTK+3 to GTK+4 be as difficult as the port from GTK+2 to
> GTK+3? Looking at various NEWS postings in the 3.93/.92/etc releases leading
> up to GTK+4 (http://ftp.acc.umu.se/pub/gnome/sources/gtk+/), it looks like a
> fair amount of stuff will change.

I guess we'll see. The major concern I have is related to our own ABI
compatibility. Is there a way to decouple our ABI version from the GTK
version? This is what forced us to stick with gtk2 for that long
timeframe, and that sucked...

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Rectangle selection tool - fixes and more

[Simon Budig]

Hi Samuel.

Samuel Rats (samuel.r...@gmail.com) wrote:
> I noticed a TODO in the code of the rectangle selection tool, about
> changing the internal representation of the selection zone from gdouble
> ((x1, y1), (x2, y2)) to gint (x1, y1) + width & height.
> So, that's basically what I did. Since then, I'm not able to reproduce
> either of the bugs.

Thanks for investigating this issue!

> I couldn't find information on the gimp wiki on how to send a patch for
> review, so I'm asking here: what should I do with it?
> Should I send it here, by email? Should I push a branch somewhere?
> Something else?

Basically the best method is, to attach the patch to a bug report,
either open a new bug or reuse the one you mention.

Also please feel free to pester us on IRC (#gimp on irc.gimp.org) about
this issue...  :-)

Thanks,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Paths, selections, and stroking

[Simon Budig]

Dov Grobgeld (dov.grobg...@gmail.com) wrote:
> My guess is that this happens is that the original ellipse is first reduced
> from a contour to a bitmap "selection", and then the edges of this bitmap
> is somehow traced.
> 
> On the other hand the result may be improved by instead of stroking the
> selection, you convert the selection to a "path" and then stroke the path.
> This approach is practically identical to the Inkscape result:
> [image: stroke-path.png]
> But why are these different? What use then is stroke selection? Shouldn't
> stroke selection use the same algorithm?

You're right: Stroking a selection means, that the stroke follows the
"marching ants" exactly, which means that there are a lot of 90° turns,
which are executed according to the line-join property. Especially with
the "miter" join style this leads to a pretty significant change in
the perceived stroke width. It is slightly better with the "round" join
style.

I've tried ages ago to address this problem, but it turns out it really
is hard. There is some discussionn of this problem in
https://bugzilla.gnome.org/show_bug.cgi?id=50730

I hope this helps,
 Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Participation at Apple Developer Program

[Simon Budig]

alexandre.prokoud...@gmail.com (alexandre.prokoud...@gmail.com) wrote:
> Wed like to know opinions of all developers and contributors of GIMP,
> but not everyone is on IRC. Please vote :)

I voted "I don't care".

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] IRC?

[Simon Budig]

Jehan Pagès (jehan.marmott...@gmail.com) wrote:
> What's up with the IRC channel?

We had a mass join/spam event happening.   :-(

The restrictions will be lifted hopefully soon. send a private message
to someone of the regulars to get invited into the channel.

> I just come back from shopping, and now I can't connect.
> It says:
> 
> 20:14 -!- Cannot join to channel #gimp (You must be invited)

That'll teach you to leave the channel!!!1!   :)

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 license from the GIMP team ?

[Simon Budig]

Hi Miguel.

Entertainment Mobile wrote:
> My understanding is that GIMP trademark and logo is free to use
> according to GPL. However Google Team says that I must have the GIMP
> team permission in order to use the word "GIMP" in the app name. Do
> you know how we could obtain the GIMP team permissions to include the
> word GIMP in the app name taking into account that our app provides
> access to a GIMP desktop app ?

Well, asking the GIMP team here is a good start.  :)

Personally I consider it a bit misleading to include the name "GIMP"
into a remote desktop app that happens to be used to connect to a remote
gimp.

The User Experience for this kind of application will always be tricky,
since GIMP is designed for the desktop and is not really adjusted to the
Android UI.

I would prefer to reserve the name "GIMP" for an app that uses gimp's
technology with a suitable UI layer. While we currently don't have any
plans to do this it might happen in the future.

I appreciate your efforts and your enthusiasm for gimp, but please try
to find a different name for your application.

Thank you,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Proposal for erasing background from an image

[Simon Budig]

John Tapsell (johnf...@gmail.com) wrote:
> So to restate this again - I want to know how to change the top layer
> $latex src$ so that I can have the maximum possible alpha without changing
> the final visual image at all.  I.e. remove as much of the background as
> possible from our foreground+background image.

This is what color-to-alpha does. Except that it uses a constant color
for the whole image. It might be interesting to convert this to a gegl
op that takes two input drawable and picks the "background color" from
each corresponding pixel in the background image.

Should be an easy fun hack. Who wants to take it?

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Wilber Logo

[Simon Budig]

Riley Tallman (rptall...@gmail.com) wrote:
> I would like to design t-shirts with the Wilber logo and commercially sell
> those shirts online. I have not made the designs yet because I wanted to
> make sure that I have the right permission and legal ability to do so.
> 
> The design will have nothing other than a modified version of the Wilber
> logo, and perhaps the text "GIMP".
> 
> Let me know how to proceed,

You seem to have interpreted C R's mail as a permission. Note that he is
not in a position to give that permission (and did not even claim to in
his mail).

A big chunk of the Gimp Team is currently sitting together and we will
discuss your request. Note that we'll probably ask for the actual
designs you want to put on the shirts and also want to know about your
plan to contribute back to the community. Maybe you can elaborate on
that a bit.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] I'm going slightly mad.

[Simon Budig]

Thorsten Stettin (thorsten.stet...@gmail.com) wrote:
> Why do you need libpng >= 1.6.25, and lcms2 >= 2.7 in order to build Gimp
> 2.9.5 - commit 36ebe03770fd8b87102e95cd6c45b194a45a8ba3?

Libpng is due to security issues:

commit a5073ad9289f7e05ef38d2ce99dc71e91983b434
Author: Michael Natterer 
Date:   Mon Oct 31 09:36:15 2016 +0100

configure.ac: require libpng 1.6.25

Addresses bug #765850, and probably avoids a gazillion of
vulnerabilities in the versions since the ancient 1.2.37
we required before.


For libcms2 this is due to some rounding errors that affected some
blending modes in gimp:

commit 0ce364ee4dd2200e6607a4575af0cc657600afc9
Author: Michael Natterer 
Date:   Thu Sep 15 12:52:20 2016 +0200

configure.ac, app: require liblcms2 >= 2.7

and add an lcms2 runtime version check to app/sanity.c

Fixes:
Bug 736701 - LCMS2 rounding errors cause problems with certain
GIMP blend modes

I hope this helps,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Plans to resolve hotkey conflicts?

[Simon Budig]

C R (caj...@gmail.com) wrote:
> > Uh. In what way isn't that the case currently?
> 
> Try Alt-C, s for hue/saturation
> Then try it again after you complete the hue saturation action
> On the second run alt-C, s skips to Colourise

Oh, indeed. That feels stupid.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Plans to resolve hotkey conflicts?

[Simon Budig]

C R (caj...@gmail.com) wrote:
> I should be able to hit a sequence of hotkeys to get to sub menu items, and
> doing it again should get me to the same function each and every time I
> perform them.

Uh. In what way isn't that the case currently?

GTK+ cycles through all the "conflicting" mnemonics. So (for british
english) ALT-C, s, s  consistently brings you to "Colouri_se".

I usually don't use the mnemonic-based menu navigation, so I might be
missing something...

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Pencil - Tool Options and Hardness

[Simon Budig]

C R (caj...@gmail.com) wrote:
> Yes, it saves time if everyone reads the entire thread before commenting.
> I'm guilty of this too sometimes, though, so don't worry about it. :)

You know, I actually reread, and I find the thread highly confusing.

It starts with the hardness-parameter in the pencil tool, then goes on
to how paintbrush is so similiar to the pencil tool, how the pencil tool
can get removed, then pat getting confused that "hardness" would be the
relevant property here (hint: it isn't), then brush presets and then
Americo (wrongly) claiming, that (currently!) "anti-aliasing" is the unique
difference between pencil and paintbrush. Which I disputed. Then you
proposed that a "pixel brush" (whatever that means - I read that as "a
1x1 hard-edged brush) would be an adequate replacement for the pencil
tool (And no, a brush alone can't solve this problem).

And now I am the one to blame for getting tetchy when all those weird
terms are thrown around and everybody seems to talk about different
things?

> You are describing the behaviour as "snapping". It's not snapping, it's
> just not averaging.
> The effect is the same, however. One click of the mouse, one pixel is
> coloured in. It does not matter what you call it.

Ah, "averaging". Another term that yet has not been used in this thread
(I think).

What does it mean to "average" a pixel brush on a drawable?

And why is it not snapping when the pixel grids of the bŕush and the
drawable keep getting aligned to pixel borders?

> The options for drawing a line in a raster image are generally either
> 1.Anti-aliased
> 2.Nearest-neighbor (aliased, or "snapping" as you like to call it. :) )
> Ah, I thought you understood. Please go back and read the entire email
> thread.

The fun fact is, that neither the paintbrush nor the pencil tool "draw
lines" in the sense of a line in inkscape. They just repeatedly stamp
the brush onto the canvas (or an intermediate canvas for non-incremental
painting) at certain coordinates. "Anti-Aliasing" in the sense of
"rendering a vector polygon onto pixels cairo-style" does not apply here.

So what are we talking about when we're talking about "anti-aliasing"
for the paint brush? Just the resampling that happens when the
pixel-grids of brush and the drawable don't align properly?

> *It's not "rocket science" to do that either, or to understand that it's
> not possible to show what the brush tool would do with no anti-aliasing in
> GIMP.
> I already know that the brush tool currently averages, this whole thread is
> about adding a feature to the brush tool to replace the pencil tool.*

What do you mean by "averaging"?

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Pencil - Tool Options and Hardness

[Simon Budig]

C R (caj...@gmail.com) wrote:
> > Have you actually tried to do what I outlined above?
> >
> >
> Have you? lol
> No - I haven't. It's not currently possible to turn off anti-aliasing on
> the brush tool, so it's not possible to "test" it.

Ah, sorry. I missed that we're discussing hypothetical future
characteristics of the tools here. I was just looking at the current
difference between the pencil and the paintbrush tool.

> However, knowing how anti-aliasing works, your statement is incorrect...

Well, if you choose to label the behaviour I described as
"pixel-grid-snapping" (or the lack thereof) as "anti-aliasing" then it
is not me who is making the error here. I actually don't think that they
are the same.

> The paintbrush tool resamples the brush when the pixel grid of the brush
> > is not perfectly aligned to the pixel grid of the image.
> 
> Yes, but with anti-aliasing turned off (which you can't presently), it
> wouldn't.
> 
> > A perfect non-antialiased 1 pixel brush typically gets spread across
> > four adjacent pixels in the image, assuming you're working with a high
> > zoom level and don't specifically align the brush to the pixel grid of
> > the image.
> 
> I don't know why you would assume that. :)
> It's incorrect at any rate.

This is *exactly* what the current paint brush tool does. And it really
is no rocket science to test it. Just do as I explained above. I even
did just a few moments ago, even if I knew this behaviour for years.

> Anti-aliasing IS what average pixels to spread over a 4-pixel block.
> If you turn it off (which, again, you can't currently in the brush tool),
> and a single click with a 1px brush fills more than one pixel, then that
> would be incorrect behaviour.

The Pencil tool does two things (compared to the paintbrush) that are
independent of each other:

a) it thresholds the alpha channel of the brush (with a quite low
threshold)

b) it snaps the pixels of the brush to the pixels of the image, so that
no resampling occurs.

This is the *current* state of Gimp. And it has been like this for ages.

If we want to put that as an option into the paintbrush (and lose the
pencil) then describing both of these behaviours combined as
"anti-aliasing" is IMHO misleading and wrong.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Pencil - Tool Options and Hardness

[Simon Budig]

C R (caj...@gmail.com) wrote:
> > C R (caj...@gmail.com) wrote:
> > > A pixel brush seems like an adequate replacement for that functionality.
> >
> > Again, no.
> >
> > Try working with a pixel brush in a bigger magnification and check how
> > the pixel-grid-snapping of the pencil tool makes a huge difference to
> > the paintbrush.
> 
> If there's no anti-aliasing on the pixel brush, please explain how it would
> differ from the behaviour of the pencil tool.
> 
> I think you'll find it wouldn't. :)

Have you actually tried to do what I outlined above?

The paintbrush tool resamples the brush when the pixel grid of the brush
is not perfectly aligned to the pixel grid of the image.

A perfect non-antialiased 1 pixel brush typically gets spread across
four adjacent pixels in the image, assuming you're working with a high
zoom level and don't specifically align the brush to the pixel grid of
the image.

The pencil tool doesn't do that.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Sometimes the contents of config/devicerc are not read

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
> "Error while parsing '/home/elle/code/gimpdefault/install/config/devicerc'
> in line 7: unexpected character '-', expected number (float) - fatal parse
> error"

Yay, now the implicit assumptions crop up   :)

Thanks for spotting this.

> 2. From glib:
> 
> When using GIMP, when the color picker picks an out of gamut color, glib
> prints to the terminal the following message:
> 
> (gimp-2.9:1865): GLib-GObject-WARNING **: value "((GimpRGB*) 0xde2f30)" of
> type 'GimpRGB' is invalid or out of range for property 'color' of type
> 'GimpRGB'

This is not actually glib. Somewhere in the definition of GimpRGB we
apparently register one getter/setter function that errors when
encountering negative or >= 1 values. This needs fixing in gimp itself.

Mitch: is extending the range of GimpRGB harmless enough to do?

Bye,
 Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] New Image/Color Management option

[Simon Budig]

Hi Gez.

Gez (lis...@ohweb.com.ar) wrote:
> Although I share your shock, I think Michael is right. Almost nobody
> using GIMP understands color management, because there is virtually
> nobody using GIMP seriously, and probably nobody will because of this
> kind of design decisions.
[...]
> Instead of focusing on imagers devs seem to be focusing on eventual
> users who only use the tool once a month for scaling some photos and
> remove red eyes or making banners for online forums.

I don't understand your line of reasoning. Did you realize, that Mitch
has literally spent months to make color management actually work in
Gimp - i.e. cut'n'paste between images with different color profiles
attached, color managed color selectors etc. pp.

And now all this work is jeopardized, because he made a preferences
option to disable this stuff a little bit more visible? And we seem to
have troubles in finding a correct way to describe what this toggle
button does?

If this is your line of reasoning, then, sir, your priorities are messed
up.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] [darktable-dev] Darktable plug-in in GIMP - Darktable for Windows?

[Simon Budig]

Michael Natterer (mi...@gimp.org) wrote:
> On Thu, 2016-04-28 at 15:43 -0400, Elle Stone wrote:
> > On 04/28/2016 03:40 PM, Elle Stone wrote:
> > > 
> > > Delete the following text from pluginrc after you uninstall
> > > darktable,
> > > and you can use a different raw plug-in:
> > Is there an "order of preference" in the pluginrc file such that if
> > a 
> > user installs a raw plugin, the installed raw plugin would take 
> > precedence over the built-in darktable raw plugin?
> 
> No there isn't but there will. This is work-in-progress. We'll
> probably end up with the plug-in having to specify "I am a raw
> importer", and a page in prefs to pick one of the installed
> importers.

An alternate idea might be to en/disable the file-plugins manually in
the preferences. That would allow users to cut down on the number of
file format options in the dropdown in the file open dialog. That way
the really obscure file formats can be disabled and don't clutter the
list...

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] London/Harrow calling...

[Simon Budig]

Hi all.

The Libre Graphics Meeting 2016 is rapidly approaching and we need to
get our act together to rent the usual gimp-appartment.

If you are a london resident and if you happen to know of an appartment
where 8-12 people could reside in the weeks surrounding 15-18 I'd love
to hear from you. The closer to the Harrow Campus of the University of
Westminster the better.

Note that there are funds available, we don't expect to be hosted for
free...  :)

It would be really great to get some help here   :)

Thanks,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] 10 bit color

[Simon Budig]

MassimoIT (massimo.bertine...@tiscali.it) wrote:
> I'm a windows user, so I've tried the 2.9 available at darkrefraction.com.
> I'm very enthusiastic about the deep color precision introduced with the 2.9
> release, but I didn't find out the way to display 30 bit color.
> Having introduced openGL, I think it may be offered a feature that only
> Photoshop implements by now: it would be great!

For now this is not available in Gimp. The new features regarding high
bit depth are all related to how the image data is stored internally and
what data format the drawing operations use for their calculations.

I know that cairo (the library we use to draw the image onto the screen)
has at least some support for 30 bit depth images, but I am not sure
what is needed to a) make use of that and b) make sure that the results
really end up on the screen.

Sorry for now.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Future of Python v2 scripts

[Simon Budig]

Joao S. O. Bueno (gwid...@gmail.com) wrote:
> While it is is feasible to have Python3 as the system default install,
> it is not practical to remove Python2 from the system. Even if it is
> not installed by default (which I doubt very much) it will be
> reachable via the default packaging system (and therefore available as
> a GIMP dependency).
> 
> Anyway, even if we switched today to Python3 for GIMP, it would only
> be available as of GIMP 2.10 - so GIMP 2.8 would still use Python2
> scripts.

It would make sense to switch to python 3 in sync with the
(plugin-breaking) switch to gtk3 with the 3.0 release.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Future of Python v2 scripts

[Simon Budig]

Ofnuts (ofn...@gmx.com) wrote:
> On 26/11/15 11:53, Simon Budig wrote:
> >It would make sense to switch to python 3 in sync with the
> >(plugin-breaking) switch to gtk3 with the 3.0 release.
> 
> Why would gtk3 break python plug-ins? I don't see that many that come with
> their own UI. I would expect 2.10 and the high bit-depth to break more
> scripts

It breaks all C plugins, since the libraries are no longer
binary-compatible.

2.10 should not break anything - we try to keep the PDB and the libgimp
API backwards compatible. That is until the planned breaking for 3.0.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Portable development environment for GIMP

[Simon Budig]

Liam R E Quin (l...@holoweb.net) wrote:
> The difficulties of using Debian Testing are likely to outweigh any
> benefits, plus anyone working closely with git gimp is likely to want
> to test fixes to babl and/or gegl as they happen.

gimp from git specifically depends on gegl/babl from git.

Bye,
 Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] curvature filter

[Simon Budig]

Hello, Mr. Gong.

Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
 If you don't have either time or interest, I do hope that someone will
 get involved and make a GEGL port of your filters. I'm sure that will
 benefit a lot of users.

Also it would be necessary for someone else to work on that to have a
clear licensing statement within the repository and/or the source code.

To avoid confusion I'd recommend sticking to the accepted free software
licenses.

Thanks!
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Gimp at the Chaos Communication Camp 2015

[Simon Budig]

Hi all.

This year there will be a Chaos Communication Camp again. In August this
epic event will shake the world and you'll look at videos, regretting
that you haven't been there.

OR you could attend and celebrate hacker culture:
   
https://events.ccc.de/2015/04/09/call-for-participation-chaos-communication-camp-2015/

GIMP will have a presence there: quite a few of the developers are
regulars at this event and we hope to have a good time there, which
works better with more people   :)

If you have never heard about the Camp I'd suggest to look up some of
the videos floating around. It really is an amazing event. I was
fortunate to attend all of them and can whole-heartedly recommend it.

I am currently trying to estimate how big a tent we need and would
appreciate, if you could tell me if you want to attend and if you want
to be part of the Gimp crowd.

Thanks,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 in private schools and educational institutions

[Simon Budig]

Gez (lis...@ohweb.com.ar) wrote:
 [...] optional patch
 that provides and easy way to remove the name GIMP from the UI,
 replacing it for a different one?
 
 Now, seriously. What do devs think about this idea? If somebody provided
 a good patch for building GIMP easily with a different name as an
 option, would you accept that patch?

No. It would only play into the hands we already have with fake
packagers who sell Gimp without mentioning the Gimp brand name and
without mentioning that Gimp is available for free as well.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 in private schools and educational institutions

[Simon Budig]

Hi Sam.

Sam Bagot (dsm...@gmail.com) wrote:
 Is there any thought on salvaging the marketing effort and renaming this
 product so that it can be taken seriously by people and institutions?
 Also, a big barrier to entry adopting Linux for people is a solid
 graphic manipulator.  The bad branding is causing many people in my art
 communities around Austin to avoid Linux in general.

 What are the plans on renaming and success?

Basically our approach is to redefine what Gimp means. In the vast
majority of the world Gimp refers to the Gnu Image Manipulation
Program, the alternate interpretation is unknown to most people in the
world.

Renaming Gimp would hurt our brand badly and is not an option.

If it is a problem in your local area (some areas in the US typically)
that is unfortunate, but we need to rely on your powers to explain that
we're helping in getting rid of the derogatory interpretation of the
term Gimp.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Create New Layer Button

[Simon Budig]

Kevin Payne (payn...@hotmail.com) wrote:
 Isn't it about time there was an interim release? - a line in the
 sand if you will.

I think we will discuss this live at the libre graphics meeting at the
end of april/beginning of may.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Create New Layer Button

[Simon Budig]

Gez (lis...@ohweb.com.ar) wrote:
 El vie, 27-03-2015 a las 09:16 -0400, Elle Stone escribió:
  On 03/26/2015 08:16 PM, Ofnuts wrote:
   It was also not so obvious to some more advanced users :) let's face it,
   in a software with the breadth of Gimp, everyone is going to overlook
   some feature.
  +1.
 
 I'm the kind of users who read the tooltips, so I knew the feature and
 although I have no personal interest in having it changed, I wouldn't
 mind if the behavior is reversed (clicking on new layer creates a new
 transparent layer and shift+click brings the dialog for alternate
 options).

we had that this way for a while. Turns out that with the shift-click
not really being discoverable a bunch of features basically
disappeared. We then reverted it back.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Drop shadow - a question from an user - developer-version 2.9

[Simon Budig]

Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
 On Mon, Feb 9, 2015 at 2:44 PM, Simon Budig wrote:
 
  Does this GEGL op do anything for you at all? Because it does
  absolutely nothing for me (duly noted in
  http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL/UI_review),
  seperate layer or no separate layer.
 
  Is the keep transparency toggle enabled?
 
 There is no such toggle in the GEGL op.

I was referring to the keep transparency toggle in the layers dialog.
Which is still alive and kicking, even when used in conjunction with
gegl ops.

Having it enabled would explain perfectly what you're seeing.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Drop shadow - a question from an user - developer-version 2.9

[Simon Budig]

Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
 [drop shadow]
 Does this GEGL op do anything for you at all? Because it does
 absolutely nothing for me (duly noted in
 http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL/UI_review),
 seperate layer or no separate layer.

Is the keep transparency toggle enabled?

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Hi Elle.

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 Whether to *ever* use unbounded sRGB chromaticities to perform edits on
 UserRGB data is NOT AN IMPLEMENTATION DETAIL.
 
 Unbounded sRGB is a mistake, pure and simple, *unless* the data is intended
 by the USER to be HDR sRGB data.

It really is not about editing. Even when for some reason the data in
the graph is present as unbounded sRGB data the multiplication op will
request the data as userRGB which will result in a transform, the op
will get the colors in the desired space.

 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.

I think you are missing that unbounded also allows *negative* R, G or B
coordinates. That makes the colors imaginary in the sRGB color space,
but it still is possible to convert them to all other RGB color spaces.

Unbounded sRGB can express all the colors XYZ can express.
Transformations from userRGB to sRGB to userRGB are lossless.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Since a few questions have popped up on IRC and it really is a weird
concept to grasp I thought I'd expand a bit on the color math that is
being discussed here. Sorry it is so long, I hope it is somewhat
entertaining though  :)

Simon Budig (si...@budig.de) wrote:
 I think you are missing that unbounded also allows *negative* R, G or B
 coordinates. That makes the colors imaginary in the sRGB color space,
 but it still is possible to convert them to all other RGB color spaces.
 
 Unbounded sRGB can express all the colors XYZ can express.
 Transformations from userRGB to sRGB to userRGB are lossless.

The normal sighted human eye contains three types of cones which respond
differently to a given light spectra. In 1931 researchers have tried to
map the response of these cone types by having people stare at
projection screens and match colors. The results of these experiments
were combined and resulted in the definition of a CIE standard
observer, with the most important aspect being functions describing the
standard response of the three cone types to light wavelengths:
  http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg

The Tristimulus values X, Y, Z refer to the three cone types. They can
be determined by weighting the spectral power distribution with the
resp. response curve and then computing the integral over the wavelength
range from 380 to 780nm.

Related to XYZ is xy, which simply is the color information normalized
to a given intensity: x = X/(X+Y+Z) and y=Y/(X+Y+Z).

The horseshoe-diagram you see frequently when colors are discussed
(http://en.wikipedia.org/wiki/File:CIE1931xy_blank.svg ) lives in the
xy plane.

Note that these are absolute colors we're talking about here. For a
given spectral power distribution we end up with certain XYZ values.
This totally ignores other aspects of the human vision system. In
particular knowing the XYZ coordinate of a color does not help at all in
determining if something is perceived as white. This is where the
whitepoint becomes relevant. For example if you look at a piece
of letter paper lighted by candle light you perceive it as white, since
your eye is trained to take the color of the environment light source
into account. Also experiences are relevant as well. You just assume
that this piece of paper is white, since this is what you are used to
and then your vision system takes this as a reference point.

If you'd see the same XYZ color in a daylight context, you'd probably be
surprised how reddish yellow it actually is. Taking a photo of a
candlelight scene with a digital camera set to a daylight whitepoint
will give you an idea. No, the yellow color is not the camera lying to
you, it is the eye not being allowed to lie to you.

Another important aspect of the XYZ system is, that it contains
imaginary colors: Color coordinates where it is impossible to create
light spectra for. If you look at the color matching functions
referenced above you see why: they do have huge overlaps, most
wavelengths trigger two or even all three of the cone types
simultaneously. Looked at it from the math point of view that
means for example that if Y is nonzero, then X or Z will be nonzero as
well.

The XYZ coordinate (0, 1, 0) is an imaginary color. It is impossible to
construct a real world light spectrum that results in this XYZ
coordinate. Pure light with about 520nm wavelengh might get you close,
but you still have X and Z components  0. The rounded boundary in the
horseshoe diagram represents the pure wavelengths and the weird shape is
determined by the overlaps in the color matching functions.

XYZ is very useful in that it is a good tool to describe absolute colors
and it is a superset of all the color impressions the CIE standard
observer can perceive. It is the safe bet of color spaces.

However, since pure X, pure Y and pure Z are basically a physical
impossibility they cannot be used to build real world computer monitors.
It has turned out that variants of Red/Green/Blue are a useful
compromise to compose color impressions. The Phosphors used in CRTs and
the filters used in LCDs have a specific spectral distribution and can
be varied in their intensity, resulting in an absolute XYZ coordinate.
In the real world we have a maximum brightness for each of the
components and reducing the intensity moves the XYZ coordinate on a
straight line towards (0,0,0), i.e. black.

Since the integral math behaves additively the three independent
components construct a skewed cube in the XYZ color space. This is the
gamut: the range of color impressions that can be shown with this
particular monitor. If you now normalize the intensities of the
coordinates within this skewed cube you end up with a triangle in the
xy-space, which is useful to describe the range of colors available to
you with a given set of base colors:
  http://en.wikipedia.org/wiki/File:CIE1931xy_gamut_comparison.svg

The corners of the triangle are the xy-coordinates of the
phosphors

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

[Simon Budig]

As a small aside...

Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
 We'd like to keep the interaction professional, thank you.

I'd like to ask everyone involved in this discussion to remove
the gimp-user mailinglist from the CC-list. The level of this discussion
really is hardcore gimp-devel stuff and there is no need to duplicate it
on gimp-user.

People on gimp-user who are interested in this discussion are welcome to
join gimp-devel.

Let this be the last mail in this thread duplicated to both of the lists  :)

Thanks,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Hi Elle.

The following is my understanding, when pippin answers his answers have
more authority than mine.

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 Putting aside coding considerations that might affect other software that
 uses babl and GEGL, here's my understanding of your current plan for
 babl/GEGL/GIMP:

A slight preface here. I don't consider it important to focus on the
*storage* of the pixel data, as in the actual bulk memory for the pixel
data.

The important part is, that the data is available to the operations in
the format they request upon request. If that is in memory already
pre-converted or if that gets converted on the fly is an implementation
detail.

 1. Upon opening an image, the image will be converted to unbounded sRGB.

I don't think that this is decided yet, I actually consider it unlikely
at the moment. I think it might be more likely to have it sitting in
memory as userRGB. But again, this is an implementation detail, where I
assume that the floating point math is sufficiently precise to avoid
visible rounding errors.

 2. For all chromaticity dependent RGB editing operations:
* Either the image will be re-encoded using the user's chosen RGB working
 space chromaticities, and then the operation will be performed.
* Or else the image will be converted to CIELAB and then the operation
 will be performed.

Conceptually the image won't be converted as a whole. A
pixel-data-flow-graph will be set up that considers the region of
interest.

For all chromaticity dependent RGB editing operations the pixels will be
re-encoded in the format the operations requests. Which most likely will
be userRGB. And the re-encoding-step can be a NOP, if the previous node
in the operations tree already provides the requested format.

 3. For all chromaticity *in*dependent RGB editing operations, the image will
 be converted to unbounded sRGB for processing.

For all chromaticity *in*dependent RGB editing operations the pixels will be
converted to the format the operations requests. Which most likely will
0e sRGB or XYZ. And the re-encoding-step can be a NOP, if the previous node
in the operations tree already provides the requested format.

(Sorry for repeating, but this is an important point: in a given image
context userRGB really is not conceptually different from sRGB or XYZ,
it gets slightly more complicated when two images with different
user chromaticies are to be combined.)

 4. When converting to XYZ/CIELAB/etc, the image will first be converted to
 unbounded sRGB.

Not necessarily. If specific userRGB to XYZ/whatever transforms are
available to babl it will make use of them. This will likely be the case
for e.g. AdobeRGB.

 5. The GEGL developers will specify on an operation by operation basis
 whether the operation requires being encoded using UserRGB/Y/etc, or
 unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent
 RGB processing, or etc.

It probably will be specified within the implementation. I.e. there
won't be a pre-existing separate document with a list for each
individual operation.

However there might be such a document generated from the implementation.

 As an important note, depending on the last operation that was done, the
 image might already be encoded using the GEGL-operation-specified format, in
 which case a conversion to that format is not needed.

Yes, but it is important to keep in mind that we don't sequentially
apply one operation after each other, with image-in-memory-steps
inbetween. We build a graph of connected operations, where the
connections between the nodes will be negotiating the resp. pixel
formats. *Then* the pixel data will be fed from the sources into the
graph, flow through the graph, have the operations operate on them,
potentially converting them to the negotiated pixel formats and finally
get sunk into the output (e.g. the node painting into the image view).

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 A slight preface here. I don't consider it important to focus on the
 *storage* of the pixel data, as in the actual bulk memory for the pixel
 data.
 
 If you choose to *store* the user's RGB data using chromaticities not of
 user's choosing, that suggests that you also intend to *edit* the user's RGB
 data using chromaticities not of user's choosing

I think that this is the core of the misunderstanding here.

In Gegl the *storage* of pixel data in memory is totally and 100%
independent from the colorspace used to *edit* the user's RGB data. You
seem to think that the storage suggests an intent, but a lot of the
communication from pippin, jonnor and me is about explaining that this
is *not* the case.

Obviously it makes a lot of sense to bring storage and editing workspace
in line to avoid computational bottlenecks. But this is just a
performance optimization, i.e. implementation detail.

 1. Upon opening an image, the image will be converted to unbounded sRGB.
 
 I don't think that this is decided yet, I actually consider it unlikely
 at the moment. I think it might be more likely to have it sitting in
 memory as userRGB.But again, this is an implementation detail, where I
 assume that the floating point math is sufficiently precise to avoid
 visible rounding errors.
 
 This is not just an implementation detail. The user has the right to control
 what RGB working space is used when performing RGB edits on the user's own
 RGB data.

We need to make sure two things:

a) upon import of an image the userRGB-format-descriptor within the
images context needs to be set up to refer to the chromaticies of the
source image.

b) whenever a chromaticity dependent operation works on the images data
the infrastructure needs to make sure that the pixel data gets fed into
the operation using the chromaticies of the source image. We'll do this
by having the operation request the image data in the userRGB format
from the images context.

Note that this is totally independent from the pixel *storage* in
memory. This will work the same when the pixel *storage* is in userRGB,
sRGB or XYZ.

 For all chromaticity dependent RGB editing operations the pixels will be
 re-encoded in the format the operations requests. Which most likely will
 be userRGB.
 
 If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user
 really does expect that *all* RGB edits wil be done using the user's chosen
 RGB working space chromaticities.

We agree here. The *edits* for the chromaticity dependent operations
need to be done in the chromaticies of the source image.

 If specific userRGB to XYZ/whatever transforms are
 available to babl it will make use of them. This will likely be the case
 for e.g. AdobeRGB.
 
 OK, if I understand what you just said, this is getting silly.
 
 I think you are indicating a willingness to write hard-coded AdobeRGB
 editing operations and put them right alongside the hard-coded sRGB editing
 operations.

Oh, I was under the assumption that AdobeRGB had well defined
chromaticies. If that is not the case then please consider my example
moot. I am well aware that dealing with color profiles most definitely
is not my area of expertise.

If there were chromaticies for a given userRGB which are widely used
in a lot of real world applications, then it might make sense to support
them in a similiar way like we currently do for the sRGB primaries.

If that is not the case then this indeed would be silly.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Test images and test suite (was Re: GIMP should fork babl and GEGL)

[Simon Budig]

Jehan Pagès (jehan.marmott...@gmail.com) wrote:
 Well for the contribute test images part, I'm not a photographer. I
 have a good enough Canon camera and I can try to shoot some objects
 with RAW on request though, but I won't guarantee the art quality for
 these. Though you'll say that's not the purpose of this test set
 anyway. :P

I do have access to a x-rite color checker which should be in a
reasonably good condition (it is slightly older but has been stored in
the dark).

I could try to set up a colorful scene and shoot it in RAW with my
Nikon D40. Would this be of any help?

(I am right now unsure about the correct lighting, there *should* be
some daylight neon tubes around, but I am at the moment unsure where
they are...)

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 //begin quote from http://color.org/DevCon/devcon14.xalter
 
 While this fixed PCS is capable of delivering unambiguous color transforms,
 it cannot support the increasing demand for spectrally-based reproduction.
[...] 
 Tying GIMP to sRGB as PCS is a dead-end move.

If you take spectrally based reproduction as an argument against sRGB
as PCS you should be at least be so fair to also mention that *any* RGB
based image editing is bound to fail for this.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 On 10/17/2014 06:39 AM, Simon Budig wrote:
 Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 //begin quote from http://color.org/DevCon/devcon14.xalter
 
 While this fixed PCS is capable of delivering unambiguous color transforms,
 it cannot support the increasing demand for spectrally-based reproduction.
 [...]
 Tying GIMP to sRGB as PCS is a dead-end move.
 
 If you take spectrally based reproduction as an argument against sRGB
 as PCS you should be at least be so fair to also mention that *any* RGB
 based image editing is bound to fail for this.
 
 In point of fact, I've already said thist. But I'm happy to say it again.
 RGB data is not spectral data.

I know. Which is why your previous mail could have had the very same
text and the following sentence as the conclusion:

Tying GIMP to RGB based editing is a dead-end move.

Which is exactly the dead end you have been advocating a lot in the
recent discussion.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
 On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone
 When the user opens a color-managed fooRGB image, for which *specific*
 editing operations will the image be converted to unbounded sRGB?
 
 
 If the user is putting a text-layer, which has been rendered using
 cairo and is in 8bit sRGB premultiplied alpha. The compositing of this
 with preceding data in the layer stack the babl-format of the output
 buffer of the over/normal compositing operation, as well as the data
 fetched from both buffer inputs - would likely be RaGaBaA float - if
 the two linear inputs differ.
 
 I'm not sure why your text-layer stack example is relevant to my very direct
 and still unanswered question.

As you very well know we don't *have* the specific list of editing
operations you ask for. I don't know why you keep repeating the
question. You seem to think that not getting an answer to that question
proves a point, but I definitely have no idea what the point is.

What would be the benefit of having such a list?

If the implementor of an operation thinks, that an operation needs to
work in unbounded bablRGB then it will request bablRGB input and gegl/babl
will do its work to provide that.

An example *could* be an operation that does change the warmth of an
image by simulating lighting by a different illuminant. The operation
could request bablRGB input data, convert that to XYZ internally, do the
shift, convert back to bablRGB and provide that as output.

But then the author might be better off with requesting the data in XYZ
directly, saving him from the work of doing the bablRGB to XYZ conversion:
Gegl/Babl does that for him.

Both ways are fine, Gegl/Babl can do this today. It is up to the author
to choose and it will be *completely* transparent to the user of the
operation.

This is completely independent from how the image pixels are stored in
memory, even when they are stored with a different set of RGB primaries.

Gegl/babl in that case will know how to transform the stored pixels into
bablRGB the operation requests, and they'll know what to do with the
output.

The text example from pippin is supposed to illustrate that Gegl in real
world situations has to deal with external sources which are beyond the
control of Gimp. And Gegl/Babl provide the facilities to deal with that.

 At all points we know the CIE Lab or XYZ coordinates of all involved
 pixels
 
 You don't know the XYZ coordinates until you actually convert from fooRGB
 to XYZ. Likewise with CIELAB. So it's not clear what the above sentence
 really means.

If you know the pixel values of a pixel and know how to convert fooRGB
to XYZ there is absolutely no need to do the actual conversion. You can
still claim that you know the XYZ as well as CIELAB coordinates. You
just don't bother to do the conversion until you really need it.

If you know that x is 5 and you know how to calculate the square of a
given value you don't need to do the actual calculation. Yet you still
know in the sense that the specific value is available to you as soon
as you need it.

 But here's a maxim for *RGB* image editing:
 
 For RGB editing operations, don't ever, ever, ever convert color-managed
 fooRGB to unbounded sRGB.

I assume that by RGB editing operations you're referring to the
math-centric ones which bluntly apply a mathematical formula to the
pixel data, not caring if the operation makes sense from a
colorimetric/physics based viewpoint. (Examples would be multiply or
even levels on the RGB channels).

We now have operations who utterly need to know the colorimetric values
of a pixel, because they are based on color theory. Shifting the color
temperature of an image might be a good example.

We have to be able to mix these operations, because Future Gimp (TM)
will head towards non-destructive editing, where the user uses the UI to
construct a graph of operations to combine all the image sources to get
to the desired result. We don't intend to stick to the have-an-image,
do-an-operation, have-a-new-image, repeat paradigm.

So we need infrastructure that can mix both, the colorimetric and the
math-centric approach. Your proposal of never-ever-converting will make
real colorimetric operations a pain, since the color-temperature
operation has to accept the fooRGB data, convert it to XYZ, do its
operation and convert back to fooRGB, because fooRGB is ultimately what
is needed for a potential next math-centric operation.

With the infrastructure proposed by pippin the math-centric operations
will ask for fooRGB data as input and provide fooRGB data as output.
That means that chaining them together will neatly avoid colorspace
conversions.

If the user then decides to put a color-temperature change in the mix
(lets assume it requests bablRGB as input and provides bablRGB as
output, since the author decided against XYZ for some reason) Gegl/Babl
will put a fooRGB-bablRGB conversion into the 

Re: [Gimp-developer] [Gegl-developer] babl roadmap

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 On 10/14/2014 07:52 AM, Øyvind Kolås wrote:
 On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone
 ellest...@ninedegreesbelow.com wrote:
 
 To convert images to and from unbounded linear gamma sRGB, you MUST pass
 through XYZ. XYZ is the PCS.
 
 I remind you that linear RGB spaces are a single matrix multiplication
 away from other linear RGB spaces and XYZ.
 
 Matrix conversions between RGB working spaces can be concantenated. That
 concantenation goes through XYZ. It almost sounds like you want to obscure
 this fundamental distinction between XYZ and unbounded linear gamma sRGB.

for conversions between RGB working spaces there is no fundamental
distinction between XYZ and unbounded linear gamma sRGB.

In mathematical terms both of these span up a three dimensional vector
space (describing color) and the only difference is that they use
different basis vectors.

You can *easily* describe conversions between different RGB primaries
with ulgsRGB as the connecting space (completely replacing XYZ). You
would get a different set of transformation matrices of course.

XYZ is something that has a special role for all of the non-RGB color
spaces Lab, xyY, Luv etc, as well as operations like chromatic
adaptation. Hence it makes sense to use it also as the connecting space
for the different RGB primaries.

 Are you planning on converting non-sRGB images to unbounded linear gamma
 sRGB? Yes or no?

For pixel storage we will use whatever fits our needs, it does not make
sense at this point to specify this.

This might be a Lab-buffer with a cache in front of it that has the
pixels converted to sRGB. Or a Adobe-RGB-Buffer without a cache. Or
unbounded linear gamma sRGB. Or whatever.

The important thing is, that gegl/babl provides the means to access these
data in whatever format is needed by the operation that is happening. A
brightness-invert function might request the data in Lab, do the
inversion on the L channel and feed the results back as Lab to the
gegl/babl infrastructure, which will process it to provide the next
operation in the graph with the input format the next operation needs.

 If yes, are you intending that at least some editing will be done on the
 image while it's encoded using sRGB primaries? Yes or no?

That totally depends on the editing-operation in question and is
orthogonal to the pixel memory storage format.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Hi Thorsten.

Thorsten Stettin (thorsten.stet...@gmail.com) wrote:
 with all due respect to you, I think you should contribute instead to
 babble.

If you perceive Elles texts as babbling it seems that this discussion
is way over your head and you might want to consider staying out of it.

Thanks,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Christopher Curtis (ccurt...@gmail.com) wrote:
 I'll admit that this discussion is way over my head, but as it seems to
 involve only two people would it be better handled over a phone call? It
 appears that there are some basic assumptions that aren't in alignment.

While it certainly could be more concise, the discussion has helped me
tremendously with my glimpse into gegl/babl. So while the
misunderstandings might be easier to overcome within a phone call
keeping the discussion on the list helps with potentially getting the
concepts out there to more people.

That having said, meeting people in person *is* tremendously helpful and
I'd like to extend pippins invitation to the LGM (next year in Toronto)
to everybody who is interested in discussing these topics with e.g.
pippin and me. There will be funds available to help bring people
together.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Precision Conversion Dithering and Triangular wave gradient issues

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 Program received signal SIGSEGV, Segmentation fault.
 0x004e7b7f in gimp_blend_tool_motion (tool=0x33f3370,
 coords=optimized out, time=optimized out, state=GDK_BUTTON1_MASK,
 display=0xe58180)
 at gimpblendtool.c:450
 450   if (GIMP_IS_CANVAS_LINE (blend_tool-line))
 (gdb)

At that point please enter bt (for backtrace) and post the result.

Also a print blend_tool and a print blend_tool-line would be
helpful.

Thanks,
 Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Two-minute(!)-survey on motivation and free time contribution of open source developers

[Simon Budig]

stefankull...@web.de via surveymonkey.com (mem...@surveymonkey.com) wrote:
 for a university research project at the Technical University Berlin
 (Germany) I would like to gather some original input from open source
 software developers. I kept the length of the survey to an absolute
 minimum!!! 

What is the actual goal of your survey? What is the benefit to me when I
invest my time?

 Master student of Innovation Management and Entrepreneurship at TU Berlin

This really triggers how about no? reflexes.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Blend Tool UI

[Simon Budig]

peter sikking (pe...@mmiworks.net) wrote:
  Hmm, you might have misunderstood what I meant by shapebursts. The
  shapebursts are special gradients that mimic the shape of your
  selection (currently labeled Shaped (angular), Shaped (spherical),
  and Shaped (dimpled)). Anyway, at this point I'm really conflicted
  as to what should be done with them. I'm not sure whether they belong
  in the blend tool or not right now.
 
 OK, I should have consulted the manual and now I have done it.
 
 I am now completely convinced that the shape burst belongs
 in the gradient tool. there is nothing contradictory about
 that. the gradient tool applies a gradient fill (as everything:
 modified by the selection) and Shape is a fill ‘mode’.
 
 and when talking interactive: next move would be to control
 these funky fill shapes on the canvas with a handle or two.

A little background on shapeburst modes to get an idea about what might
be adjustable by the user.

When filling with a shapeburst mode, a distance map is computed, where
for each somewhat-selected pixel a distance to the nearest
unselected pixel is computed. The distance is computed using a
manhattan metrics (dx+dy), with some funky shit for partially selected
pixels. For the latter part I am currently not convinced that it works
correctly and consistent.

Computing the distance map is an expensive operation (and unfortunately
the manhattan-metrics approach introduces some quite visible weird
unexpected artefacts). But this actually needs to be done only when the
selection changes, I think right now it is computed every time.

A huge improvement would be to change the distance metrics to something
euclidean. That'd give way more predictable and useful results. However,
this is not easy at all apparently...

The currently selected gradient is then mapped to the distance (think
gradient-map). The angular, spherical and dimpled variants are
basically specifying what function is used to map the distance to a
position in the gradient.

This *could* be something more funky, similiar to how I used the curves
tool to determine the shape of the golden text in my ancient
golden-text-tutorial: http://www.home.unix-ag.org/simon/gimp/golden2.html

angular would be a linear mapping and I believe that spherical and
dimpled basically would be quarter-circle mappings (in different
directions).

Changing this to a generic (editable?) curve should be fairly
straightforward.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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 on Steam

[Simon Budig]

Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
 Also, I don't understand neither why we are having this conversation,
 nor where the word consensus came from. I implied no consensus.

You wrote the core team's opinion currently is, which implies that the
core team (whoever that exactly is) has a consensus on that (which is
probably not really the case).

For the records, I am one of the persons objecting against a use of
Steam. I think I'll try to explain my reasoning later in this thread.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 on Steam

[Simon Budig]

Sam Gleske (sam.mxra...@gmail.com) wrote:
 I'm curious to hear Simon's opinions since he openly admitted he was one of
 the against parties.

Ok, so let me detail some of my concerns. I want to have it clear
however, that this is not some sort of official statement from the
gimp team, this is just my personal opinion.

Also there are multiple issues which I'd like to consider separately,
although of course there are interconnections:

First there is this connection to the SourceForge issue. Some time ago
we did a deliberate move away from SF and we got a tremendous public
response on that. With that as background we need to consider, that a
move towards a different commercial hosting platform probably will be
perceived as an endorsement of this platform. We have proven in the past
that we do very conscious decisions on our software distribution, so
Steam somewhat gets the seal of approval from the gimp team.

And rest assured that a decision in favor of Steam will be news.

I am not sure if I am willing to accept this responsibility. I don't
have the impression that we carefully evaluated the privacy implications
of that move, and we don't know a lot on how good steam as a platform
is. Given that we don't really have an urgent problem with making gimp
available to people I don't see any benefit for us that would compensate
for the Steam-advertizing.


Secondly I believe that we have a certain responsibility towards the
privacy of our users. By using Steam we are encouraging people to create
an account there, provide download statistics as well as (to an unknown
extent) usage data. We let them generate marketing data for Valve, which
they can use to targeted offerings to their users, depending on their
documented gimp download.

If Gimp is the reason why someone creates a steam account: do we want to
accept this responsibility? I know that I am preaching to my friends and
family about how to use adblock and reducing the data footprint in the
net. For myself I am going through a lot of troubles to minimize me
being a data source as well as being locked into certain technologies.

It would be disingenious for me (and that includes me as a gimp
contributor) to advertize Steam.


Thirdly there is the philosophical (and most complicated) aspect: Is
this store way of distributing software something we can accept and
use for ourselves?

By store I am referring to the commercially controlled software
repositories, for the sake of this discussion I am limiting myself to
itunes, google play and steam. Here commercial entities set the
conditions for access to their userbase. The most blatant example is
apple, where developers have to pay fees to be able to provide the
software to their users - and free software seems to be incompatible
with the conditions of the store.

Certainly there are varying degrees of strings attached to the
respective stores. But we have to realize that the conditions for a
store are subject to change depending on money-making interests.

By using a store we are submitting ourselves to the conditions of the
store, we (who?) have to accept the terms and conditions of that store.
Should later something change we have to abandon the users which got
gimp through steam - we lose our communication channel to them.

To me it feels like we are losing some of our freedom.

On the other side this store approach to software distribution is a
highly competitive market, which works by segregating the users into
different camps and keeping them hostage there. We see it with the
smartphones: suddenly it is quite important what brand of smartphone you
have, because the software offerings are quite different. The users lose
their freedom to install the software they need, because the device
determines the software available to them. Dual-booting into different
OSes as a workaround for specific software needs is generally impossible
on smartphones, switching to a different camp means that you lose the
software you bought and/or installed.

I worry about the attempts to introduce this kind of software
distribution to the PC market, because we are already seeing the
mechanisms being developed to make dual-booting harder, introducing DRM
into the whole chain of hard/software, and stores are becoming a thing
for PCs as well. I am assuming that we will see more of that and we
might end up in the same disaster as with smartphones. I don't want that
and I don't want to endorse the development in this direction. To me the
philosophical aspect of Free Software is important and I think it is
vital for our future, that users keep the freedom to tinker with their
devices.

I realize that this is a forward looking statement - using Steam will
not immediately result in the loss of said freedoms. But I really don't
like the development in this direction and would like to avoid backing
it.

TL;DR: Nope, I don't like it.

Bye,
Simon

PS: I realize that there is a lot where one could quibble about the
details. The 

Re: [Gimp-developer] Gimp on Steam

[Simon Budig]

Ofnuts (ofn...@laposte.net) wrote:
 Your reasoning seems to imply that Steam will become the sole source for
 Gimp downloads, while as I understand it it will only be an additional
 source. Making Gimp available on Steam would not be pushing people towards
 Steam, it would make Gimp more easily visible/available to those people with
 a Steam account. And let's be modest here, Steam has 65 millions active
 users, they don't need Gimp to be popular :)

I am fully aware that there will be other gimp sources than steam and I
am fully aware that the success of Steam does not depend on gimp.
However, That doesn't have - as far as I can see - any effect on my
musings.

As for pushing: I did not use that word in my mail. However, it is
easy to imagine that gimp availability on steam might convince people to
create an account, if only for the oh-so-convenient auto-updates. And
immediately we are in the situation I use as the base for my
considerations.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Releasing a new locale?

[Simon Budig]

Michael Bauer (f...@akerbeltz.org) wrote:
 I've asked before but maybe it got missed because it was a
 double-barrel question.
 
 I've completed the main UI translation into Scottish Gaelic (gd) and
 done some of the other ancillary files. What's the process for
 making sure this gets released?

I unfortunately don't know the process itself, but we usually suggest to
contact the gnome language team for scottish gaelic:
  https://l10n.gnome.org/teams/gd/

Maybe they can help.

Thanks for your efforts,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Releasing a new locale?

[Simon Budig]

Simon Budig (si...@budig.de) wrote:
 Michael Bauer (f...@akerbeltz.org) wrote:
  I've completed the main UI translation into Scottish Gaelic (gd) and
  done some of the other ancillary files. What's the process for
  making sure this gets released?
 
 I unfortunately don't know the process itself, but we usually suggest to
 contact the gnome language team for scottish gaelic:
   https://l10n.gnome.org/teams/gd/

Uh sorry - you seem to be aware of that already. Obviously.

Not sure what is needed beyond that.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Changing order of placeholders

[Simon Budig]

Michael Bauer (f...@akerbeltz.org) wrote:
 Tha a' phongalachd \%2$s\ aig an dealbh \%1$s\ (%1$d) ach tha
 dùil ris a' phongalachd \%3$s\

I don't know what the original string is, but you're referring to the
argument no 1 two times: one as a string, one as a decimal. That can't
be right.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] Changing order of placeholders

[Simon Budig]

Michael Bauer (f...@akerbeltz.org) wrote:
 Well, the source string says
 
 Image '%s' (%d) has precision '%s', but an image of precision '%s'
 is expected

Then try this:

Tha a' phongalachd \%3$s\ aig an dealbh \%1$s\ (%2$d) ach tha
dùil ris a' phongalachd \%4$s\

(where I am unsure if 3 and 4 are in the right order - I currently can't
even guess the drift of the sentence  :)

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Search Action dialog feature

[Simon Budig]

Chris Mohler (cr33...@gmail.com) wrote:
 His concerns seem to be be... unfounded.

So, what *is* Tito? A help system or a command line system? I have not
seen an answer to that yet.

And yes, I agree with Peter that this is a vital question.

 I mean: where does the it must be A or B come from?  Wherever it is,
 I'm not following said path.  It does not make sense to me.

Because I think if I add this feature there might be someone who might
possibly find this helpful is not a good guide when sharpening the
features of your system. We want to avoid ad-hoc-design-descisions and
that means that we need to decide on the scope we want to cover with a
new system.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

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.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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 precise is Gimp 32-bit floating point compared to 16-bit integer?

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 My question is, for Gimp from git, is 32-bit floating point more
 precise than 16-bit integer?

Yes, at least for the range from 0.0 to 1.0.

 If so, by how much, and does it depend
 on the machine and/or things like the math instructions of the
 processor (whatever that means)? And if not, how much less precise
 is it?

AFAIK it does not depend on the processor, floating point numbers are
defined in IEEE 754, and to my knowledge that is what all processors
use.

For 32 bit floats there are 23 bits in the mantissa, so in the range
from 0.0 to 1.0 we easily have more precision than with 16 bit ints.

 To restate the question, in decimal notation, 1 divided by 65535 is
 0.152587890625. So 16-bit integer precision requires 16
 decimal places (lop off the four trailing zeros)

you're barking up a wrong tree here. The length of the decimal expansion
is not necesssarily helpful, because most of them represent rounding errors.

(btw. - you divided by 65536)

1.0 / 65535 = 0.15259021896696422

but

1.0 / 0.1525913 = 65534.53... -- gets rounded to 65535

and

1.0 / 0.1525891 = 65535.48... -- gets rounded to 65535

So with 11 decimal digits we easily have all the precision we need to
represent the fractions for a 16bit int.

 How many decimal places does Gimp 32-bit floating point actually provide?

It has 23 bits mantissa, 8 bit exponent and 1 bit sign.

For decimal notation it depends a lot on the range. Numbers with a
bigger magnitude (exponent  0) the number of digits after the decimal
points become less.

BTW: You can view 16 bit ints somewhat like a float with no sign bit,
no exponent bits and 16 bits mantissa. I.e. sign is always positive,
exponent is always 0. That makes it clear that a 32bit float completely
encompasses the 16 bit integer values

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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://gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] How precise is Gimp 32-bit floating point compared to 16-bit integer?

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 So real colors can easily fall outside the range 0.0 to 1.0 if they
 are converted to sRGB. What happens to the precision when dealing
 with RGB values up around 2.5 or down around -0.9?

Sign is stored in its own bit. Precision is not affected there.

Floating point numbers are represented as mantissa * (2**exponent),
So whenever the exponent gets increased by one you lose one bit of
absolute precision.

So for numbers up to two you have 22 binary digits of precision (after
the dual point), for numbers up to four you have 21 binary digits of
precision.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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://gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Setting Up a Release Procedure

[Simon Budig]

Jehan Pagès (jehan.marmott...@gmail.com) wrote:
 Oh right. I just checked again. In the AUTHORS page, there is actually
 a Sven Neumann as maintainer alongside Mitch. I actually realize I
 made a mistake, because that's another Sven!

Indeed  :)

Sven N. hasn't been very active in Gimp development for quite a while
now. He is currently focussing on different things. I met him a few
weeks ago and he is alive and well - just not in the GIMP universe  :)

 I completely understand that each individual enjoys being a maintainer —
 and thus the main actor!

I for one would not enjoy maintainership  :)

Bye,
   Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Quick-edit workflow

[Simon Budig]

Richard Gitschlag (strata_ran...@hotmail.com) wrote:
 And similar to you, one thing *I* don't get is why Export and
 Overwrite need to be separate commands.

Because without this distinction you'd accidentially overwrite your
precious orignal file after accidentially doing an Export instead
of an Export To.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] Documentation on color spaces

[Simon Budig]

Elle Stone (l.elle.st...@gmail.com) wrote:
 On 10/9/13, Simon Budig si...@budig.de wrote:
  Another (slightly philosophical) issue for me is, that you never explain
  what you mean by color.
 
 I added a one-paragraph summary of color:
 http://ninedegreesbelow.com/photography/xyz-rgb.html
 What do you think? Will my one-paragraph summary work?

Yeah, I like it.

  I am not sure if mentioning this helps or if it confuses stuff...  :)
 Based on your input I rewrote the explanation of imaginary colors,
 hopefully clarified what a real color really is, and touched on the
 subject of nonstandard color perception. Metamerism, though very
 important, might be more distracting than helpful?

Yeah, Metamerism probably is distracting.

For my mental model of color the spectral distribution of the light is
quite important and I wonder if it would help a color-newbie to have
more of this tangible stuff in the text. But this certainly also is a
question of personal preference and I don't want to impress my views
onto your text  :)

To look at the weaknesses/hypothetical problems of the XYZ model there
are two things worth noting:

a) two distinct spectral distributions might end up at the same XYZ
   coordinates.
b) there are XYZ coordinates in the first octant, which can not be
   mapped back to a spectral distribution.

(put in mathematical terms: XYZ is neither injective nor surjective)

And I'd explain it by looking at the monochromatic light (visible to the
average human), which has a very specific position at the border of the
horseshoe.

By adding up more wavelengths you'll always end up inside the horseshoe,
(and there is more than one way to add up monochromatic light to end up
at a certain XYZ coordinate). On the other hand, creating an actual light
source with XYZ coordinates *outside* the horseshoe is an impossibility,
even for rocket scientists, unless we assign XYZ coordinates for
invisible wavelengths or allow for negative light sources...

The human aspect of XYZ is visible in two aspects: first the limited
spectrum we consider and then the weird shape of the horseshoe, which is
determined by the response curves of the average cones in the human
eye. But only the first one has an effect on the reality vs.
imaginarity of a XYZ coordinate IMHO.

However, adding tons of more diagrams with spectral distributions,
X/Y/Z response curves etc. would at some point destroy your intentions
with your text, so I won't complain...  :)

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] HELP with SYMBOLIC icon theme for Gimp.

[Simon Budig]

jEsuSdA 8) (lis...@jesusda.com) wrote:
 I have found a file: gimpstock.h that contains this lines:
 
 /*  missing icons:  */
 #define GIMP_STOCK_PALETTE  GTK_STOCK_SELECT_COLOR
 
 I suppose this mean that there is no icon defined, so Gimp load a
 gtk one and it is impossible to force gimp to load another icon from
 theme.

This is a #define pointing to a different #define.
GTK_STOCK_SELECT_COLOR is defined as gtk-select-color and
GIMP_STOCK_PALETTE inherits this definition.

The fun thing is, that the palette color selector uses
GIMP_STOCK_PALETTE as well as the Palette Editor. I don't understand how
this can be different icons.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] HELP with SYMBOLIC icon theme for Gimp.

[Simon Budig]

jEsuSdA 8) (lis...@jesusda.com) wrote:
 Not for me! :(
 What kind of magic is this?! hehehe.

Sorry, my fault. I was looking at the wrong icon.

I see the problem now as well. Not sure what is happening there...

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] HELP with SYMBOLIC icon theme for Gimp.

[Simon Budig]

jEsuSdA 8) (lis...@jesusda.com) wrote:
 El 05/10/13 01:05, Simon Budig escribió:
 jEsuSdA 8) (lis...@jesusda.com) wrote:
 But solving A does not solve B and the old coloured icon still
 appears. ¿?¿?¿? :(
 
 ok, weird.
 
 
 yes. :(

Dunno, I added the following section to the imagerc and it just worked:

stock[gtk-select-color] =
{
{images/stock-colormap-24.png, *, *, gtk-button },
{images/stock-colormap-24.png, *, *, * }
}

 Hum, no idea about that one. gimp-zoom-follow-window should be OK.
 
 It does not work.

the path to the images erroneously contains the /tools/ subdirectory.

Try this:

stock[gimp-zoom-follow-window] =
{
  { images/stock-zoom-follow-window-12.png, *, *, gtk-button },
  { images/stock-zoom-follow-window-16.png, *, *, *}
}

I hope this helps,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] HELP with SYMBOLIC icon theme for Gimp.

[Simon Budig]

jEsuSdA 8) (lis...@jesusda.com) wrote:
 Working on gtkrc I have solved F bug and improve the icons visualization.

Thanks for your efforts, that indeed looks really great. I'm all for
including it in the main gimp source.

 The bug D is almost done: eye icon has changed, bug when clicked,
 there are no closed eye showd, so, I need help to solve this.

I am not sure if I understand the bug: the default theme does not
contain a closed eye icon.

Do you see the default eye when the mouse button is pressed down? Then
apparently the stock icon definition for the ACTIVE widget state is
wrong for some reason.

Thanks,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] gimpshop:

[Simon Budig]

Dulce Oración (escogidapord...@gmail.com) wrote:
 What is Gimpshop? And how I can get it?

If you don't know what it is, why do you want it?

(It basically is a hacked up outdated version of gimp, we strongly
recommend not using it).

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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] New veres old

[Simon Budig]

Chris Mohler (cr33...@gmail.com) wrote:
 I can't speak for everyone, but for me: the day GIMP switches to a
 closed-source model will be a dark one, indeed.

This actually is virtually impossible. There are tons of contributors in
the codebase and relicensing that one would mean getting them all to
agree (or carefully dissect who did what and remove that code).

And there are quite some hells that need to freeze over to get that
agreement from me...   :)

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp multipage tiff

[Simon Budig]

Oleg (lego12...@yandex.ru) wrote:
 On Fri, Dec 07, 2012 at 10:15:58AM +0100, Michael Natterer wrote:
  The only thing that helps is writing a patch :)
 
   Of course :-), but i just think about some donation that can help with
 an intrest in the tiff saving. Is this possible?

It is possible to donate to Gimp and we promise that it will help with
the development of the Gimp (mainly by financing face to face meetings
of gimp developers and relevant projects).

However, we do not want to have feature-specific donation: This would
hamper our independance and would make it harder to reject bad ideas
from the outside.

Of course tiff multipage saving is not really a bad idea - don't get me
wrong there - but we really would prefer a patch over money.

Thanks,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Graeme Gill (grae...@argyllcms.com) wrote:
 Simon Budig wrote:
  We cannot just make the assumption that oh, its a JPEG. *clearly* the
  user wants us to discard information on saving.
 
 You really think they want you to save a lot of invented bits
 and blow their file up in size with all that false data ?

As soon as the User does some little tiny editing we no longer can
discern reliably between invented bits and important bits.

 They want you to save the same visible information, without
 any obvious further degradation. That's easily achieved
 by saving in a lossless format, but not very clever,
 and doesn't honour the quality/file size trade-off they've
 already agreed to and want, since they are saving back
 to the lossy file format they opened.

The whole point we're trying to make and which you refuse to understand
is, that they already agreed to and want only applies for images they
created themselves from scratch. It breaks down immediately when they're
working with images from other sources, like the clueless marketing
droid sending you a jpeg logo file.

Here the user does *not* do a concious descision towards a lossy file
format. He did *not* agree to loose bits on saving even when he opened a
JPEG. This whole user indicates his intent by the file format he opens
just breaks down when working with images from other sources.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Alberto Mardegan (ma...@users.sourceforge.net) 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.
 Or do you have reports when this did not occur for some reasons?

* User creates a multi-layered image
* User saves to JPG, gets prompted for flattening
* User either does not understand about layers or flattening
  or does understand it, but really just wants the JPEG file for sharing.
* JPEG file gets saved
* Gimp 2.6 marks the image as saved.   --- critical!
* User quits Gimp, no prompt for unsaved images

Layer information lost.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Exported-but-not-saved prompt (was: Save/export, option to go back to old behaviour)

[Simon Budig]

Tobias Lunte (tobias.lu...@hfg-gmuend.de) wrote:
 Personally, I've never really understood why GIMP doesn't use more
 graphical elements in its UI (yes, I know, GIMP already uses quite a
 bit, but given that it's a program for photo-manipulation, we can
 assume that most of it's users are inclined towards visual
 information as opposed to textual).

In fact *because* we're dealing with lots of graphical elements we have
to avoid distracting from the image the artist is working on. We had
requests for a grayscale icon theme in the past, I wouldn't be surprised
if too much icon clutter would impact the usability badly.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Alberto Mardegan (ma...@users.sourceforge.net) wrote:
 On 11/16/2012 12:54 PM, Alexandre Prokoudine 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 :)
 
 No, they aren't: I'm not proposing to remove or change the current
 behaviour. I'm proposing to add a configuration option (I don't care how
 hard it is to find) to re-enable the old behaviour.

We discussed adding a configuration option and decided against it, for
reasons discussed in earlier threads about this.

 So, it's an addition that doesn't collide with the UI decisions already
 taken.

It does.

Sorry for being terse, but we've been there...

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Matthew Miller (mat...@mattdm.org) wrote:
 I also find the change frustrating for my workflow. I don't mind learning
 the export-instead-of-save command, but it's bad UI to always confirm on
 exit even after a file is saved -- and, for many actual real world user
 workflows, exported *is* saved for every practical purpose.

Well, there also are many actual real world user workflows, where the
export == save has resulted in loss of artwork. In its most trivial form
it is help, I can no longer edit the text in my jpeg.

We have decided to focus on loss-prevention. We have discussed and
explained this ad nauseam.

So unless you come up with a real usability study within our target user
group that shows that they can't handle this change we won't change
this.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Overlay Mode - fix.

[Simon Budig]

Paul Geraskin (paul_geras...@mail.ru) wrote:
 If you have read the article.. it happens only if you use gaussian
 blur filter which makes some color calculations with alpha.

Please take a deep breath, relax a little and don't jump to conclusions.

This article is exactly about the blending problem which of course
involve a lot of alpha stuff, since blending without alpha channel is
basically meaningless.

You're currently not helping getting things done. You apparently did not
fully grasp the problems we're facing. Your isolated fix is not a
solution unfortunately.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Overlay Mode - fix.

[Simon Budig]

Jeff Maples (grapn...@gmail.com) wrote:
 I agree with Paul on the overlay mode.  The patch is excellent, and it
 makes importing files from Photo$hop more consistent.  I think it should be
 the default.  Just my two cents.

The problem with the approach Paul took in the bug report is, that it
breaks compatibility: Existing Artwork stored in XCF files will change
apperance depending on the Gimp version.

We can't have that.

However, this does not prevent us from implementing a proper overlay
mode. We just need to keep the old (arguably buggy) blending mode around
and introduce a *new* one with the proper implementation. Then we change
labels in the UI.

That'd be the way to go forward with this issue.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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?

[Simon Budig]

Elle Stone (l.elle.st...@gmail.com) wrote:
 The purpose of the constant background converting back and forth
 between two tone curves, sRGB TRC and linear gamma, is not clear at
 all.

Well, it is not on purpose. It is basically a side-effect of trying to
port Gimp to the new infrastructure without e.g. changing the visual
output of e.g. layer modes, while avoiding changing the math (Or do it
in an incremental manner while keeping the results consistent).

 In service of the noble goal doesn't explain *why* the conversions
 are done over and over again instead of just once. I really, really,
 really want to know why those relentlessly repeating background
 conversions between sRGB TRC and linear gamma are happening.

Ok, for an example have a look at gimp/app/operations and grep the
string R'G'B'.

As you can see, a lot of them are designed to work in a R'G'B' mode,
since this was the working assumption in our old 8 bit core. We need
as-identical-as-possible results and the easiest way to port them to
GEGL and adding support for the high-bit-depth modes is to let the
operations work in R'G'B'A float and port the math in the most
straightforward way possible.

Now every time some of these operations is involved, the GEGL core needs
to convert the RGBA u16 data as stored in the image to R'G'B'A float
so that the operation can properly work in its expected working format.
And of course before the new data ends up in the pixel storage it needs
conversion back to RGBA u16.

Of course this is not good and has a massive speed impact, ideally the
operation should be able to work on RGBA u16 directly, but then the
math becomes nontrivial (we need compatible results). This is
optimization work that we have not even really started tackeling.

I fully expect to have other problems like this on all kinds of
different places and I don't know which of these point it actually is
you're hitting with your test cases.

With your elimination of the conversion in util.h you probably have
introduced visually different results for these kind of operations
(because e.g. the addition mode now adds up in a linear fashion, while
it earlier worked in Gamma mode). Of course it is debatable how certain
layer modes are supposed to work, but we also need to maintain some
backwards compatibility, so that old XCF files in a new Gimp look the
same as always.

 But I
 will stop asking. And maybe some kind soul will send a private email
 giving an explanation that I can understand.

Please not, keep it on the list. These things are tricky and they
deserve to be pulled into the open  :)

And don't stop asking.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] News of a new image enhancement algorithm ...

[Simon Budig]

sam tygier (samtyg...@yahoo.co.uk) wrote:
 If you look at the fences under the smaller arches, they have been
 interpolated from nothing. does the algorithm somehow spot the similar
 regions at other scales, and filled in the small arches with copies of
 the big arches?

Apparently so:

Our approach is based on the observation that patches in a natural
image tend to redundantly recur many times inside the image, both within
the same scale, as well as across different scales. Recurrence of
patches within the same image scale (at subpixel misalignments) gives
rise to the classical super-resolution, whereas recurrence of patches
across different scales of the same image gives rise to example-based
super-resolution. Our approach attempts to recover at each pixel its
best possible resolution increase based on its patch redundancy within
and across scales.

Really cool.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] A letter of complaint

[Simon Budig]

Michael Henning (dra...@darkrefraction.com) wrote:
 If you can imagine, we certainly don't intend the GIMP to crash.

What? I wasted *hours* over gimp sourcecode to hide crashers in there
while maintaining plausible deniability. I can't have my work being
disregarded in such a blunt manner!!1!

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gimp UI ... hesitant about compiling a list...

[Simon Budig]

RMMjr (bob.montgomery...@gmail.com) wrote:
 I've worked with a lot of software, and delved into usability issues, and
 while I'm not a luminary like Nielsen/Norman  Co, I can recognize when a
 UI is taxing me, or in some cases, when it reduces me to babbling, schitzo
 spaz trying to learn again how to use a stupid pencil. There is something
 about neuro-motor circuitry and art-brains which just doesn't cotton to
 sitting through hours of explanatory videos to do even simple stuff. You
 might recoil and suggest I just use some simple tool like 'paint' and be
 happy. I do use stuff like Blender, which similarly has an amazingly Star-
 Trekkie-esque UI, which can be similarly daunting if your mice and tablet
 and trackpads aren't deconfilicted with your systemwide hotkeys.

Please try to state your question/suggestion in a way, that non-native
speaker have a chance of understanding. I did not get at all what you
want, and my english in general is pretty good.

Thanks,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Multiply blend mode in GIMP

[Simon Budig]

Calculemus (calculemus1...@gmail.com) wrote:
 I am reading this: docs.gimp.org/en/gimp-concepts-layer-modes.html
 
 and I wonder why is the formula for Multiply, E = (M * I) / 255?
 
 Why divide with 255, that is the part that confuses me.
 Should it not be just M * I and then clamp the result in range 0 to 255?

for 8 bit modes 255 is equivalent to the value 1.0. So the proper
formula would be

   E = (M/255 * I/255) * 255.

I guess you can see how the other formula happens then   :-)

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Simon Budig]

Cristian Secară (li...@secarica.ro) wrote:
 If I use OpenOffice/LibreOffice and export a document to something
 different than OpenDocument format, if after export I just close the
 program, the program simply closes. _This_ is normal.

This is just not true.

* open a .odt file into libreoffice
* add some letters
* use Export as PDF
* close libreoffice
* Libreoffice asks for confirmation before closing.

Which is of course the sane thing to do.

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Work for new contributors (news from 2012-05-04)

[Simon Budig]

Conley Moorhous (conleymoorh...@gmail.com) wrote:
 I would like to start contributing to GIMP. I was going to start with an
 old enhancement request on bugzilla, but I don't know my way around the
 source code yet.

A good way to get guidance is to drop by in the #gimp IRC channel on
gimpnet (irc.gimp.org) and state your question.

It might take a while until someone reacts, but there are people out
there that know their way around in the code and are willing to help.

Some advice though: We generally frown upon I have a question. Can
someone help me? or anybody here?...   :)
Make sure to ask as specific questions as specific as possible.
This increases the chances on getting a reply a lot. 

Glad you want to help!
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] High bit depth processing

[Simon Budig]

Partha Bagchi (parth...@gmail.com) wrote:
 Is there is something one should know about the interaction with gegl
 for loading tiff or everything is contained in file-tiff-load.c?

I have not yet pushed any changes to file-tiff-load.c. But if you want
to look at how to use gegl for loading files then have a look at
file-png.c. This btw. was a port that was reasonably easy, the trickiest
thing being indexed PNGs.

file-gegl.c (EXR/HDR) is interesting as well, since it uses just pure
gegl to load the files, i.e. it constructs a graph that provides the
image data passed to gimp. Unfortunately this also means that I cannot
easily fix the mismatch in the data format for some files in the plugin...

I hope this helps,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] High bit depth processing

[Simon Budig]

Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
 16bit PNG can be loaded and saved
 EXR opens as 32bit float, but is saved with 16bit precision.

Also .hdr files are handled by file-gegl as well.

 Simon already evaluated porting TIFF loader to GEGL, but I couldn't
 understand a single word through lots of swearing in German, and
 that's after having studied German since I was a lad :) The general
 idea, however (if I got it right), is that the file format is messy,
 so is the original code. In other words, it will take some time to get
 this done. As usual, patches are welcome.

Yeah, I did a stab in the general direction of the tiff plugin, but the
TIFF library is quite twisted in its ways. I'll have a look at it again,
but If someone else wants to take a shot at it please go ahead, I am not
too eager...  :)

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp 2.8 splash screen suggestion

[Simon Budig]

Martin Nordholts (ense...@gmail.com) wrote:
 I like it more, but I still think the white diagonal line is too distracting

I am not a fan of this kind of nit-picking. While we have certain
requirements for the splash (e.g. to allow for the startup texts etc.)
we should try to avoid pleasing everyone with the design, this in
general doesn't help, since it dilutes the original artwork.

In particular I prefer the original version of the splash. It has more
of an edge and I like the stronger contrast better.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list