mplementations
though, as they want to integrate it with their document model (which
is built on top of GEGL).
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
On 10 May 2012 17:31, Alexandre Prokoudine
wrote:
> On Fri, May 11, 2012 at 3:02 AM, Jon Nordby wrote:
>
>>> I've just created
>>> http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL and
>>> filled it with initial data to help us tracking progress
c for his project:
A small suggestion on work-flow: Ask Marinus to subscribe to the
mailing list and to post the question he has himself here.
This makes the interaction between the designers doing the work and
the rest of the project more direct, which I believe is the best. A
done recently, but never ended up in mainline.
https://bugzilla.gnome.org/show_bug.cgi?id=141154
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
these issues, and
keeping the amount of similar issues we introduce down, they need to
be visible for all to see. Being open is about transparency and
accountability. And it is just as important, or more, that we act in
such a way with respect to our problems.
--
Jon Nordby - www.jonnor.com
_
saves and opens fall into categories
> where xcf seriously slows you down.
Point 5. above would directly address that as well.
There are some technical challenges to implement these steps, but they
are all doable. And I believe that they have a much higher potential
to improving
> accepted in GIMP? Because my main concern is that I don't want to implement
> something which will never be used. I am not aware of current state of
> project (I mean project management, not code) and I don't know what's the
> process of submitting code to GIMP/GeGL r
rn is - are gimp developers at all interested in any
> work on improving c2g.
The maintainer (of GEGL) has here expressed an interest in getting
this optimization in - that is a pretty strong yes.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list
than sorry" is a more sensible approach. One
can in general not revive dead peop^Wdocuments.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
asing the interaction design on that foundation, the user will be
required to not only know this, but to always keep this information in
mind when interacting with the software.
Is this a burden we want to put on the user? Will he always make the
right decision? Is it responsible software engin
that does need everything that XCF has to
> offer.
The following article provides information about the workflow in 2.8+,
and suggestions how to get the old one back if you really want it:
http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
ct,
you are not just destroying someones hobby - the project will
eventually stagnate, wither and die.
I am done arguing. Lets work to make GIMP-based workflows that
currently include export/save inefficiencies better.
--
Jon Nordby - www.jonnor.com
_
ould have just said: Please
write a description of your typical workflow (as a whole) when making
an argument. Then we can find the things that can be improved
together. And hopefully someone will be motivated to pick that up.
--
Jon Nordby - www.jonnor.com
___
find a paper on an algorithm which I know
> what it does, and that is all. Where do I search? I am member at
> acm.org but usually they have very advanced papers.
>
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing lis
orrect" :)
>
> The bug is known, the fix isn't trivial, mitch didn't have the time to
> do it for 2.8.
Link to the bugreport please?
> If anyone's willing to have a go at it, please join IRC to discuss it.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
ing the implicit (and unwanted) conversions you
are seeing.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
On 30 August 2012 01:01, Elle Stone wrote:
> Regarding sRGB and rendering to the screen:
> On 8/29/12, Jon Nordby wrote:
>> On 29 August 2012 19:03, Elle Stone wrote:
>>> Why does the /babl/babl/util.h code get executed from fast-float.c,
>>> float.c, model-rg
On 30 August 2012 12:11, Jon Nordby wrote:
> On 30 August 2012 01:01, Elle Stone wrote:
>> Regarding sRGB and rendering to the screen:
>> On 8/29/12, Jon Nordby wrote:
>>> On 29 August 2012 19:03, Elle Stone wrote:
>>>> Why does the /babl/babl/util.h
On 30 August 2012 13:55, Elle Stone wrote:
> On 8/30/12, Jon Nordby wrote:
>> On 30 August 2012 01:01, Elle Stone wrote:
>>> Regarding sRGB and rendering to the screen:
>>> Could you explain more about what you mean by "rendering to the screen
>>> i
On 31 August 2012 17:37, Elle Stone wrote:
> On 8/30/12, Jon Nordby wrote:
>> This is actually one more conversion and one step earlier than we need
>> to. Ideally the pipeline should look like this:
>>
>> GeglBuffer -> | display filter stack | -> s
On 31 August 2012 17:39, Elle Stone wrote:
> What's the right way to compile a module such as display-filter-lcms.c?
The build of the in-tree modules is already set up in automake. Just
change the file after having compiled GIMP without modifications, and
run "make" (and "make install"). Only the
ason:
>
> http://gui.gimp.org/index.php/Save_%2B_export_specification
>
> It's really only about getting used to a new keyboard
> shortcut when exporting.
Libre Graphics World has an article on the subject which is also worth a read:
http://libregraphicsworld.org/blog/entry/g
ith way more than 4GB of ram. Would it make any practical
> difference to be able to use more than 2GB of ram for the tile cache
> when using Gimp? It seems odd to be limited to less than 2GB for the
> tile cache size, solely because the type is gint.
>
It is
GIMP git directory:
git diff origin/master > geglify-lcms-plugin.patch
For more info on git usage, including how to make a git-formatted
patch see for instance:
http://git-scm.com/book
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
le to GEGL with gobject introspection bindings
using JGIR: https://live.gnome.org/JGIR
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
t;babl.pc" ends up in the
expected directory ($libdir/pkgconfig) and that PKG_CONFIG_PATH is set
accordingly.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
On 22 October 2012 22:04, Dexter Filmore wrote:
> Am Monday 22 October 2012 21:17:32 schrieb Dexter Filmore:
>> Am Monday 22 October 2012 18:00:23 schrieb Jon Nordby:
>> > On 22 October 2012 16:52, Dexter Filmore
> checking for gtkdocize ...
> You must have gtk-doc
operate on the
GeglBuffer from the projection (or possibly a copy), and then pass it
to the lcms-based color conversion, and then pass that to cairo.
In the longer term, one can consider making the display filters GEGL
operations and the display filter stack a GEGL subgraph.
--
Jon Nordby - www.j
ed it in the future and decided against it.
With that being said, it is already easy to (mostly*) revert to the
old-style behaviour:
http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes
* It will still prompt you about unsaved docume
saved images.
A difference is perhaps that closing an image/application (which is when
this prompt is shown) is expected to be potentially destructive (where as
saving is not), so the prompt gets more attention.
--
Jon Nordby - www.jonnor.com
___
gimp-
y by GIMP not having a good way of
creating/exporting multiple views of a document. It is further exacerbated
by us not storing undo/redo history in the document.
Both these are things to fix on the path to less/non-destructive workflows.
--
Jon Nordby - www.jonnor.com
_
o preserve his work. He or she can focus 100% on the
task at hand (here, creating a derivate JPEG file from an original JPEG
image), without having to actively keep in mind to not make destructive
actions.
1. Tthere would of course be no prompt in this case.
Ale
ashion. You can try to register a glib timeout/idle
handler, though I am not sure if it will work.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
ix
the performance.
I think a useful GSoC project would be to define and implement some
meaningful benchmarks for GIMP. If successful, that would give
insights into what the causes of the current performance problems are.
I believe that is needed for coming up with a good solution for
current, and
tins.html
Note that not just if/case statements introduce branching,
do/while/for do as well.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
3/which-open-source-licenses-are-compatible-with-the-apples-iphone-and-its-offici
I believe the problem also exists for Google Play store. Then again Firefox
for Android is available there, but it could be Google is just to wary of
anti-trust to shut it down. /speculation
--
Jon Nordby - www.jo
king sure that the code that manipulates pixels/tiles is
clearly separated in the plugin and that they fit OK with the API model
that GeglBuffer has, to make porting when 2.10 comes out quick and easy.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-
e-use the gimp plugins, or at least make
> porting quite easy.
>
The file-loaders in GIMP may be of value, to be able to support many
different file formats.
Using libgimp to allow GIMP plugins to work without porting could also have
significant value.
Apart from those, GEGL + Qt + gegl-
.
>>
> Since many - if not most - of the replies to your query on the gimp-user
> list came from people also subscribing to the gimp-developer list, I hasten
> to suggest that you reread them --
>
For reference, this seems to be the thread:
http://www.gimpusers.com/fo
uite easily in isolation.
PS:
1) wiki pages may be out of date
2) most devs prefer IRC over email, so get on #gimp and #gegl on GimpNet
3) ask if you get stuck
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
As for preview with GEGL, gegl-gtk has a widget should work just fine for
that - and will automatically handle updates and transformations.
Long-term, I hope that we can find a way for plugins to have on-canvas
preview.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> > silently clipping data?
>
> By the time GIMP 2.10 is out, there will be no such plugins in GIMP,
> so what you are suggesting simply doesn't make much sense :)
What about all the plugins using the legacy APIs found at
registry.gimp.organd other
t
does not do any pixel manipulation of its own though.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
On 10 September 2013 17:15, Elle Stone wrote:
> On 11/12/12, Elle Stone wrote:
>> On 11/10/12, Michael Natterer wrote:
>>> On Sat, 2012-11-10 at 15:17 -0500, Elle Stone wrote:
>>>> On 11/8/12, Jon Nordby wrote:
>>>> > * Change the lcms-ba
he the "gegl_buffer_get (buffer, ... "cairo-ARGB32", ...
data ...)" that you have marked, do the lcms transform such that the
8bit ready-for-display ends up in the "data" buffer.
Also, can you please post your changes as a (git formatted) diff?
It is much
On 28 October 2013 21:18, Victor Oliveira wrote:
> It looks like the problem is that this script depends of Python 2.x and
> you're using Python 3.x. The script should be updated.. ?
If the autoconf/autotools detecs and uses Python correctly, using
PYTHON=/usr/bin/python2 ./configure .
will w
k you,
Mario
___
CREATE mailing list
cre...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/create
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:
ibute to is to get the build scripts
upstream, and set up continious integration.
TravisCI is free for open source projects and can build for Mac OSX.
http://about.travis-ci.org/docs/user/osx-ci-environment/
--
Jon Nordby - www.jonnor.com
___
gimp-developer-lis
and why?
2.8 will not be able files from 2.10 using new features (naturally).
I believe files produced with 2.10 which _does not_ make use of
2.10-only features can be opened in 2.8. Correct me if I am wrong.
2.10 will be able to open all 2.8 files, of course.
--
Jon Nordby - www.jonnor.com
___
unts, not how much has changed behind the
> public API.
This means that plugins/scripts that worked in 2.8 should work in 2.10
and if things break it is considered a bug. So please report such
issues in bugzilla!
--
Jon Nordby - www.jonnor.com
_
r GTK+2) cannot be combined with PyGI.
In practice this means, one can only use GEGL from Python in programs
which does not use GTK+2 (GTK+3 is fine). Is this a problem for GIMP
2.10 (do Python plugins run in-process)?
These are my experiences from experimenting with using GEGL in
MyPaint,
ot;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 "
GM is Wednesday 15 January.
Please don't forget to submit your proposal for a talk, workshop or
meeting here: http://libregraphicsmeeting.org/2014/submit/
If you are planning to join us at LGM this year in Leipzig, you are
welcome to sign up: http://libregraphicsmeeting.org/2014/register
--
g, nur der Demütige
>> ist fähig zu herrschen.
>>
>>
>> ___
>> gimp-developer-list mailing list
>> List address:gimp-developer-list@gnome.org
>> List membership: https://mail.gnome.org/mailman/listinfo/gi
mpiler line look like? (make V=1)
> I have glib 2.39.1 installed and the sources I build with are
> in [GIMP's osx-build branch] plus Simone's and su_v's patches
> to treat C files as Objective C files. However, this doesn't
> seem to solve the problem.
What patche
ed headerfiles.
>>
>
> Hi Martin,
>
> thank you for your hint.
>
> I get our libmypaint version from
> git://gitorious.org/mypaint/libmypaint.git
>
Use https://github.com/mypaint/libmypaint.git instead. Possibly the
floating-point branch.
--
Jon Nordby - www.jonnor.co
gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-
> developer-list
> List archives: https://mail.gnome.org/archives/gimp-developer-list
>
--
Jon Nordby - www.jonnor.com
__
propriate format?
>
The data will be transparently converted (using Babl) so, apart from
performance, there is no "wrong" pixel format when passing buffers to GEGL
ops.
Assuming that one does to mark the GeglBuffers with misleading BablFormats.
--
Jon Nordby - www.jonnor.com
___
ics stack as well. Yes, it is not right, but such is
the state of things. We will have to improve it step-by-step.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://m
On Oct 15, 2014 4:19 PM, "Elle Stone"
wrote:
>
> On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
>
>> On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote:
>
Hi, I fear you two are talking past eachother.
> I will ask again:
>
> For which specific RGB editing operations do you plan to convert the
imag
to decide this.
"There" being the goal that *eventually* in GEGL 'For RGB editing
operations, use UserRGB primaries *unless* there's a really, really good
reason why only sRGB primaries will work.'
--
Jon Nordby - www.jonnor.com
___
which is to give GIMP proper ICC
> profile color management.
>
> The only caveat is that a very few GIMP UI functions really do need to be
> labelled as "only for device sRGB images" or in some cases "only for device
> NTSC images". This article lists all such fun
On 5 November 2014 13:50, Elle Stone wrote:
> On 11/04/2014 02:31 PM, Jon Nordby wrote:
>
>> (apologies for top-posting)
>>
>> Hi Elle,
>>
>> The BABL roadmap[1], which was written in response to comments raised by
>> you (and others),
>> details
On 5 November 2014 14:50, Elle Stone wrote:
> On 11/05/2014 08:22 AM, Jon Nordby wrote:
>
>> What you just described IS side-by-side implementations of
>> operations. In an ICC profile color-managed application, sRGB is
>> just another RGB working space. Y
RGB editing operations
("CI ops", for short), by definition the same colors (as located in the XYZ
reference color space) are obtained regardless of the chromaticities that
are used to encode the data."
--
Jon Nordby - www.jonnor.com
___
g
Hi Thorsten,
thanks for reporting. This should be fixed now:
commit 51621f9fb36d37556162ad514dc1492d84270d7e
Author: Jon Nordby
Date: Tue Jan 20 18:27:42 2015 +0100
gegl-init: Fix only returning GEGL_PATH for module directories
On 20 January 2015 at 17:47, Thorsten Stettin
wrote
egl-operations.c:231
> #24 0x00489348 in sanity_check_gegl_ops () at sanity.c:570
> #25 sanity_check () at sanity.c:84
> #26 0x00487f82 in main (argc=, argv=0xbafb90)
> at main.c:447
>
>
> With respect,
> Alexander Rabtchevich
> _______
On 23 January 2015 at 22:42, Jon Nordby wrote:
> Hi Alexander,
> this is https://bugzilla.gnome.org/show_bug.cgi?id=743296
> A workaround is mentioned there.
>
> It has been hard to reproduce this issue. Let me give it another go
> tomorrow, otherwise I'll disable the js
that provides some
isolation and some ready-made recipies - like Docker, makechrootpkg (from
Arch), or similar.
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://ma
ail.gnome.org/archives/gimp-developer-list
>
--
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List arc
70 matches
Mail list logo
