Hi,
William Skaggs [EMAIL PROTECTED] writes:
Sven:
What is akward about it?
Passing, say, an ExifData struct to a plug-in is awkward. Calling a
function and giving it a pointer is simpler, and much faster too.
And then there's all the extra baggage of registering a plug-in etc.
I agree
Hi,
Robert L Krawitz [EMAIL PROTECTED] writes:
I know I've been making a nuisance of myself about this, but PLEASE
at least provide a way to turn this query off.
Robert, we are at the very beginning of the development cycle and are
discussing the basics. The query is off-topic right now.
Hello,
I subscribed today to gimp-developers, and I need at least the archives
for January 2005 in mbox format (b- or gziped).
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer has got
only the archives until 2003.
Thank you
Kind regards
Gerhard Gaußling
Sven:
I agree that for a C plug-in a library is easier to use but we will
also have to care about plug-ins written in other languages. Making
the functionality available in the PDB solves this nicely. What we
usually do is to provide wrappers that let the procedure call appear
as a simple
Gerhard Gau�ling wrote:
I subscribed today to gimp-developers, and I need at least the archives
for January 2005 in mbox format (b- or gziped).
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer has got
only the archives until 2003.
It's broken. See
Am Samstag 15 Januar 2005 18:07 schrieb William Skaggs:
It's broken. See
http://www.gimp.org/mail_lists.html
for other archives.
Hello Bill,
Thank you for the hint, but unfortunately there is nothing to find for
downloading in mbox format :-(
regards
Gerhard
Sven Neumann wrote:
If we don't convert the image at load time, all plug-ins that change
colors would have to be aware of the color-space the image is in.
Since this is not the case for the time being, it would probably be a
bad idea to not convert the image. As soon as we go further down the
Hi,
William Skaggs [EMAIL PROTECTED] writes:
I agree that for a C plug-in a library is easier to use but we will
also have to care about plug-ins written in other languages. Making
the functionality available in the PDB solves this nicely. What we
usually do is to provide wrappers that let
Hi Gerhard,
Gerhard Gaußling wrote:
I'm not a Programmer, but isn't it possible to make a plug-in which load's
the icc information at a first step, to offer the user the ability to
decide in which way he wants to handle the file regarding it's color space?
It would be possible to do the
Hi,
Gerhard Gauling [EMAIL PROTECTED] writes:
I think that the suggestions made by Hal V. Engel and Jan-Peter
Homann (a well known color management consultant in Germany, afair
also a member of the eci.org maillist, a very good resource for cms
knowledge) are very important for a
Hi,
David Neary [EMAIL PROTECTED] writes:
...Sven has expressed a desire that color management be kept out of
the core in the past.
You misunderstood me then. Managing colors does of course belong into
the core but I would like to keep the implementation out of the core.
The idea is to be
Hello David,
BTW: Using the gmane.org newsserver and a news client seems to be a good
alternative to the mbox archive ;-).
David Neary wrote:
[...]
Gerhard Gaußling wrote:
I'm not a Programmer, but isn't it possible to make a plug-in which
load's the icc information at a first step, to
On Saturday 15 January 2005 13:21, David Neary wrote:
Hi Gerhard,
Gerhard Gaußling wrote:
I'm not a Programmer, but isn't it possible to make a plug-in which
load's
the icc information at a first step, to offer the user the ability
to
decide in which way he wants to handle the file
Hi,
Gerhard Gauling [EMAIL PROTECTED] writes:
Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to
wait for the release after GEGL? For a new rendering-engine further to
GEGL? GIMP 3.0?
Why? Almost everything you listed can already be done in GIMP. It's
just a bit
Sven Neumann wrote:
You misunderstood me then. Managing colors does of course belong into
the core but I would like to keep the implementation out of the core.
The idea is to be able to use different color management systems and
not to restrict ourselves to lcms. GEGL seems to offer just the
On Saturday 15 January 2005 14:42, Gerhard Gaußling wrote:
snip
For example, if you convert from adobeRGB into sRGB and viceversa
several
times, you wouldn't receive the original color impression never more,
it's
lost, and there for in poor quality (comparable with the jpeg lossy
Hello Sven,
thank you for your reply!
Sven Neumann wrote:
Gerhard Gaußling [EMAIL PROTECTED] writes:
Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have
to wait for the release after GEGL? For a new rendering-engine further to
GEGL? GIMP 3.0?
Why? Almost everything
Hi Gerhard,
Gerhard Gaußling wrote:
What kind of softproof is available? Hmm.. I can nothing similar find here.
It took me a while to find it too - it's under the View - Display Filters.
In the resulting dialog you can choose from a number of filters,
including Colour Proof.
When we were
Hal V. Engel wrote:
snip
For those that are new to color management and would like to understand
this better from a CM users perspective I would like to recommend that
a good starting point is
http://www.normankoren.com/color_management_2.html#Implementation%3C/A%3EHere,
Hi,
Gerhard Gauling [EMAIL PROTECTED] writes:
What kind of softproof is available? Hmm.. I can nothing similar find here.
Go to View-Display Filters and enable the Display Proof filter.
Please, I'm sorry for my sad english, and I hope this all doesn't
sounds to rude. I wanted only spend
Sven Neumann wrote:
Go to View-Display Filters and enable the Display Proof filter.
Thanks to you and Alastair to pointing that out, I'm quite impressed! Even
the rendering intends are there! So I'm pleased that there is some work
going on in this direction. In the GEGL TODO there is shown 0%
Hi,
Alastair M. Robinson [EMAIL PROTECTED] writes:
When we were discussing colour management a few months back, I
hacked the Colour Proof filter to do a normal working-profile -
monitor-profile transform, and it worked pretty well.
Yes, it's a shame that you never submitted this for
Am Samstag 15 Januar 2005 23:42 schrieb Gerhard Gaußling:
Photoshop lets pop up a dialog where the user can decide the kind of
conversion he will do for the pasted/dragged image
Of course only if the source color space of the imported
(pasted/dragged) image is different from the working color
Hello Sven,
Sven Neumann wrote:
- display profile
should be adjusted _once_ systemwide (every time changeable by systemwide
color preferences independant from the GIMP, as used by (e.g.)scribus [1],
inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by
commercial apps available for
Sven Neumann wrote:
Stefan Döhla sent me a patch last year that implements this
and I will probably base the changes on that. The settings he
suggested are:
- use CM or not
- display profile
- default workspace profile
- default rendering intent for color conversion
+ from workspace to
Gerhard Gaußling wrote:
+ from workspace to printer (should default to
us: webcoatedSWOP for ads (coated paper) and europe: isocoated.icc (also
coated paper)
Only as a suggestion, please keep it flexible!
* perceptual for pictures
* relative colorimetric for most other work)
agreed,
On Saturday 15 January 2005 17:37, Sven Neumann wrote:
snip
Let's try to implement this in small steps then. As a first step I
would like to add a couple of options to the preferences to allow
users to define default locations for color profiles, to
enable/disable color management and to set a
27 matches
Mail list logo
