Re: [Gimp-developer] Hard edged Ink tool?

2006-09-04 Thread Henning Makholm
Scripsit Sven Neumann [EMAIL PROTECTED]
 On Thu, 2006-08-31 at 12:34 +0200, Henning Makholm wrote:

 Could you describe what you find missing in the explanation of my
 workflow on real-world examples that I have already posted?

 We need a document explaining this which is not hidden in a mailing-list
 thread.

I'm afraid I am not able to post documents in less hidden places than
mailing list threads.

-- 
Henning MakholmNej, hvor er vi altså heldige! Længe
  leve vor Buxgører Sansibar Bastelvel!
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-09-04 Thread Alexandre Prokoudine

On 9/4/06, Henning Makholm wrote:


 We need a document explaining this which is not hidden in a mailing-list
 thread.

I'm afraid I am not able to post documents in less hidden places than
mailing list threads.


Is wiki.gimp.org a less hidden place than mailing threads? :)

Alexandre
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-09-04 Thread Sven Neumann
Hi,

On Mon, 2006-09-04 at 12:22 +0200, Henning Makholm wrote:

 I'm afraid I am not able to post documents in less hidden places than
 mailing list threads.

The point is not where the document is posted. The mailing-list is fine
for this, probably even the best place since it should be discussed. The
point is that at the end of this discussion, there should be a
self-contained document.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-09-04 Thread Sven Neumann
Hi,

On Mon, 2006-09-04 at 14:25 +0400, Alexandre Prokoudine wrote:

 Is wiki.gimp.org a less hidden place than mailing threads? :)

Definitely. Putting something up on wiki.gimp.org is pretty much
equivalent to writing it on a piece of paper and flushing it down the
toilet. Noone notices when something is added to the wiki and it is very
unlikely that a developer or user interface designer is ever going to
read it.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-09-04 Thread Alexandre Prokoudine

On 9/4/06, Sven Neumann wrote:

On Mon, 2006-09-04 at 14:25 +0400, Alexandre Prokoudine wrote:

 Is wiki.gimp.org a less hidden place than mailing threads? :)

Definitely. Putting something up on wiki.gimp.org is pretty much
equivalent to writing it on a piece of paper and flushing it down the
toilet. Noone notices when something is added to the wiki and it is very
unlikely that a developer or user interface designer is ever going to
read it.


What would it take one to finally add link to the wiki to the sidebar
at gimp.org?

Alexandre
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-09-04 Thread Michael Schumacher
Alexandre Prokoudine wrote:
 On 9/4/06, Sven Neumann wrote:

 Definitely. Putting something up on wiki.gimp.org is pretty much
 equivalent to writing it on a piece of paper and flushing it down the
 toilet. Noone notices when something is added to the wiki and it is very
 unlikely that a developer or user interface designer is ever going to
 read it.
 
 What would it take one to finally add link to the wiki to the sidebar
 at gimp.org?

A nice default theme for the wiki and someone who is willing to clean up
obsolete stuff and has the permissions to do so.


That's just my opinion, of course :)

HTH,
Michael

-- 
GIMP  http://www.gimp.org  | IRC: irc://irc.gimp.org/gimp
Wiki  http://wiki.gimp.org | .de: http://gimpforum.de
Plug-ins  http://registry.gimp.org |
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-09-04 Thread Sven Neumann
Hi,

On Mon, 2006-09-04 at 22:42 +0400, Alexandre Prokoudine wrote:

 What would it take one to finally add link to the wiki to the sidebar
 at gimp.org?

Not much. That's why it was done some months ago. That doesn't change
anything about the fact that wiki.gimp.org is ugly, hopelessly
unstructured and pretty much unmaintained.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-31 Thread Henning Makholm
Scripsit David Gowers [EMAIL PROTECTED]

 Henning has already described what he does, and it seems clear to me that
 alpha-thresholding all paint application would work well for his purposes.
 I'm sure he'll say if that is not the case.

It sounds like a good direction, but I'm not sure that it would also
be effective against an accidental application of, say, the smudge
tool, or ordinary paint tools that accidentally get used in
color-changing (rather than paint-applying) drawing modes.

-- 
Henning Makholm  They discussed old Tommy Somebody and Jerry Someone Else.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-31 Thread Henning Makholm
Scripsit Sven Neumann [EMAIL PROTECTED]
 On Tue, 2006-08-29 at 15:14 +0200, Henning Makholm wrote:

 Your idea of real work is obviously very different from mine.
 I do lots of real work on indexed images.

 Perhaps you should write up a summary then that explains your workflow
 on real world examples.

Could you describe what you find missing in the explanation of my
workflow on real-world examples that I have already posted?

 But what exactly is it that you need?

As I have already explained, I need to be sure that I don't
accidentally stray from a small predetermined number of colors.

 Is it working with a limited palette of colors? Is it the current
 behaviour of paint tools on indexed images?

Yes and yes.

 I would really like to know what's important about indexed images

The important things about indexed images is that they prevent me from
accidentally creating pixel content that does not fit the colormap.

-- 
Henning MakholmI have seen men with a *fraction* of
 your trauma pray to their deity for death's
 release. And when death doesn't arrive immediately,
   they reject their deity and begin to beg to another.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-31 Thread Henning Makholm
Scripsit David Gowers [EMAIL PROTECTED]
 On 8/30/06, Henning Makholm [EMAIL PROTECTED] wrote:

   I'm not sure I can see what you're getting at, but are you suggesting
   that I use a seperate layer for each color? That would make any kind
   of editing extremely painful.

 When I saw it, I thought so too.
 However, remember this is GEGL being discussed here. *GIMP* might well
 provide a way to back-propagate the result of an Op in the graph, which
 should take care of this okay.

If it's just an implementation detail, I don't care, of course. But I
have difficulty imagining how this setup would be easier to code than
a single actual layer whose pixel colors are simply constrained to
those of the colormap.

-- 
Henning Makholm Science, by its nature, is an uncertain undertaking, and
  offers plenty of opportunity for failure no matter how you
 approach it. Yet among the myriad ways to get nowhere, the only
 fully reliable one is doing and thinking the same as everyone else.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-31 Thread Sven Neumann
Hi,

On Thu, 2006-08-31 at 12:34 +0200, Henning Makholm wrote:

 Could you describe what you find missing in the explanation of my
 workflow on real-world examples that I have already posted?

We need a document explaining this which is not hidden in a mailing-list
thread. A document that we can show to a user interface designer and
that he/she is able. And we before we do this, we need to discuss here
if we actually want such a feature, if it is at all part of our vision
for GIMP.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-30 Thread Sven Neumann
Hi,

On Tue, 2006-08-29 at 15:14 +0200, Henning Makholm wrote:

 Your idea of real work is obviously very different from mine.
 I do lots of real work on indexed images.

Perhaps you should write up a summary then that explains your workflow
on real world examples. At the moment we are talking about indexed
images and probably mean how indexed images are currently treated in
GIMP. But what exactly is it that you need? Is it working with a
limited palette of colors? Is it the current behaviour of paint tools on
indexed images? Is it the alpha-thresholding that is done for no good
reason? I would really like to know what's important about indexed
images so that we can see if there are ways to preserve or even improve
that functionality.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-30 Thread David Gowers
On 8/30/06, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,On Tue, 2006-08-29 at 15:14 +0200, Henning Makholm wrote: Your idea of real work is obviously very different from mine. I do lots of real work on indexed images.Perhaps you should write up a summary then that explains your workflow
on real world examples. At the moment we are talking about indexedimages and probably mean how indexed images are currently treated inGIMP. But what exactly is it that you need? Is it working with a
limited palette of colors? Is it the current behaviour of paint tools onindexed images? Is it the alpha-thresholding that is done for no goodreason? I would really like to know what's important about indexed
images so that we can see if there are ways to preserve or even improvethat functionality.Henning has already described what he does, and it seems clear to me that alpha-thresholding all paint application would work well for his purposes. I'm sure he'll say if that is not the case.
As for the good of alpha-thresholding, it prevents 'junk' colored pixels that often occur when quantizing quickly to a small palette (solid part of applied paint is colored okay, semitransparent part is colored strangely.. like a bright orange with a medium green) -- cloning a multicolored pattern onto such an image may give you an idea of what I'm talking about.
Junk colors are harmful both for mapping (as Henning described) and sprites (where the total amount of pixels is small enough that a single discolored pixel is a significant glitch, and makes it look even worse when palette-swapped)

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-30 Thread Sven Neumann
Hi,

On Wed, 2006-08-30 at 18:49 +0930, David Gowers wrote:

 Henning has already described what he does, and it seems clear to me
 that alpha-thresholding all paint application would work well for his
 purposes. I'm sure he'll say if that is not the case. 

We still need a summary of all this for the design of GIMP 3.0. Unless
we can agree on a document that describes what kind of indexed image
support is needed for our target users, there isn't going to be any.


Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Sven Neumann
Hi,

On Sat, 2006-08-26 at 01:57 +0930, David Gowers wrote:

 It's good to know that. I previously got the impression that you were
 indifferent to GIMP's usefulness for editing INDEXED images. I
 certainly hope that I can substantially improve indexed drawing
 specifically, when GEGL is in use and I understand it. I think it
 would be relatively simple to bring INDEXED drawing to the level of
 usefulness demonstrated by professional pixeling tools (ProMotion, or
 the older DeluxePaint and it's clones) with a sound architecture like
 that. 

Gegl doesn't support images with indexed colors and I very much doubt
that it ever will support it. It is rather likely that indexed mode will
be completely handled by load and save plug-ins in a gegl-based GIMP. If
there's a need for editing indexed mode, this need will likey have to be
fulfilled by a different application then.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Sven Neumann
Hi,

On Sat, 2006-08-26 at 02:28 +0930, David Gowers wrote:

 Ah, the #define SUBSAMPLE 8 line. Changing it to 1 does indeed
 do what I wanted.
 
 Actually, I take that back.

Well, of course changing the define is not what you want because then
you can't get the old behaviour back.

 I'm looking for normal supersampling which is subsequently
 alpha-thresholded (exactly the way the ink and airbrush tools work in
 INDEXED mode.) 
 The behaviour of the Ink tool without supersampling is unacceptably
 chunky.
 
 So it looks like this may not be possible :(

What keeps you from thresholding the alpha values (which is essentially
what the combine_regions code is doing, even though there is actually no
goood reason for this behaviour)?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread David Gowers
On 8/29/06, Sven Neumann [EMAIL PROTECTED] wrote:
Gegl doesn't support images with indexed colors and I very much doubtthat it ever will support it. It is rather likely that indexed mode willbe completely handled by load and save plug-ins in a gegl-based GIMP. If
there's a need for editing indexed mode, this need will likey have to befulfilled by a different application then.Ah. It's not so much a need, as the tools would be much faster in indexed mode (eg 'shade' mode -- painting that cause pixels to change to the next brighter or darker color in the palette). Naturally palette searching would be needed for that in RGB mode, as opposed to running the indice through a 256-entry lookup table.
However, I suspect that simply having a 'indexize'* op just before the display op in the graph would probably work well enough (possibly better, even).*or 'quantize' -- whatever it would be called, where it receives RGB data and outputs quantized RGB data. 

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Henning Makholm
Scripsit Sven Neumann [EMAIL PROTECTED]

 Gegl doesn't support images with indexed colors and I very much doubt
 that it ever will support it. It is rather likely that indexed mode will
 be completely handled by load and save plug-ins in a gegl-based GIMP. If
 there's a need for editing indexed mode, this need will likey have to be
 fulfilled by a different application then.

Or rather, we who need indexed imaged would have to fork Gimp from the
last sane version.

-- 
Henning Makholm   It was intended to compile from some approximation to
 the M-notation, but the M-notation was never fully defined,
because representing LISP functions by LISP lists became the
 dominant programming language when the interpreter later became available.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Øyvind Kolås

On 8/29/06, Henning Makholm [EMAIL PROTECTED] wrote:

Scripsit Sven Neumann [EMAIL PROTECTED]

 Gegl doesn't support images with indexed colors and I very much doubt
 that it ever will support it. It is rather likely that indexed mode will
 be completely handled by load and save plug-ins in a gegl-based GIMP. If
 there's a need for editing indexed mode, this need will likey have to be
 fulfilled by a different application then.

Or rather, we who need indexed imaged would have to fork Gimp from the
last sane version.


I wonder which version of GIMP that is, my version of GIMP is already
crippled when it comes to supporting indexed images. I'm not allowed
to create new images in indexed mode, I cannot set the opacity for a
layer, I cannot use the smudge or blur|sharpen tool, gaussian blur
doesn't work neither does unsharp mask, layer masks seems to work but
get their alpha thresholded. To do any real work on an indexed image I
already have to go by RGB.

Duplicating this behavior in GEGL would not be appropriate in my
opinion, if an indexed image is loaded, the lookup table of the
palette is interpreted and it is treated as a color image. Thus GEGL
will have the same stance towards GIF/PCX as JPG, RAW and SVG, they
might be included as source material verbatim, but expecting palette
preserved, DCT level compositing, non-demosaiced bayer-data or vectors
in the output,. after compositing and image processing, is quite
simply outside the reasonable scope for a image processing/compositing
library.

Adding capabilities outside GEGL that special cases editing of indexed
drawables is of course an option, (in the same manner that the path
tool or inkscape would be possible to invoke for operation on SVG
based vector data.

/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread David Gowers
On 8/29/06, Øyvind Kolås [EMAIL PROTECTED] wrote:
get their alpha thresholded. To do any real work on an indexed image Ialready have to go by RGB.Duplicating this behavior in GEGL would not be appropriate in myopinion, if an indexed image is loaded, the lookup table of the
palette is interpreted and it is treated as a color image. Thus GEGLwill have the same stance towards GIF/PCX as JPG, RAW and SVG, theyI assume you meant GIF/PCX/PNG 
might be included as source material verbatim, but expecting palettepreserved, DCT level compositing, non-demosaiced bayer-data or vectorsin the output,. after compositing and image processing, is quitesimply outside the reasonable scope for a image processing/compositing
library.I want it DURING compositing. I was assuming that, until an indexed image had to be composited with a non-indexed image, its data could remain indexed. However, if the palette could be separately recovered from the original file (as another input to the compositing Op), so it could be used to govern blending behaviour, that would be equally practical.
Here's a little python docstring sketch of one of the the functions I was considering:Shade -- Grafx2 style shading facility. Colors are considered as indices by SHADE, even on a RGB source.
 lut[NCOLORS] A Numpy array, the result of applying one step of shading to COLOR. Should be precalculated to have the appropriate output format (RGB or RGBA or GRAY)
  shadeable Dictionary color:index  Basic process: pixel = srcpixels[x,y] color = hash(pixel[:3]) # ignore alpha try: index = shadeable[color]
 destpixels[x,y] = lut[index] except: destpixels[x,y] = pixelI'm sure you can see how it would be simplified and significantly sped up if I could just read indices, look their 'next color' up, and write the resultant indice.
Simply being able to get image data into an indexed form with some chosen palette(doesn't have to be the exact original) just before passing it through an Op like SHADE above, would work well for that. Is that kind of thing possible or likely to be supported?
Adding capabilities outside GEGL that special cases editing of indexeddrawables is of course an option, (in the same manner that the path
tool or inkscape would be possible to invoke for operation on SVGbased vector data.That would address using SHADE above as a paint mode, maybe. With the Op-based paint application model that has been discussed here and on Bugzilla, 

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Henning Makholm
Scripsit Øyvind Kolås [EMAIL PROTECTED]
 On 8/29/06, Henning Makholm [EMAIL PROTECTED] wrote:

 Or rather, we who need indexed imaged would have to fork Gimp from the
 last sane version.

 I wonder which version of GIMP that is, my version of GIMP is already
 crippled when it comes to supporting indexed images. I'm not allowed
 to create new images in indexed mode,

A minor nuisance, easily worked around. Equally easy coded around in a
fork.

 I cannot set the opacity for a layer,

A major nuisance.

 I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't
 work neither does unsharp mask, layer masks seems to work but get
 their alpha thresholded.

Neither of which are something one usually needs in a situation where
one wants to stick to a colormap while editing.

 To do any real work on an indexed image I already have to go by RGB.

Your idea of real work is obviously very different from mine.
I do lots of real work on indexed images.

 Duplicating this behavior in GEGL would not be appropriate in my
 opinion,

I don't really care whether it is duplicated in GEGL or outside it, as
long as the net effect of don't let my editing result in pixel colors
outside this small predeterined palette is still attainable with the
sum of GEGL + futureGimp.

-- 
Henning Makholm This imposes the restriction on any
  procedure statement that the kind and type
 of each actual parameter be compatible with the
   kind and type of the corresponding formal parameter.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread David Gowers
On 8/29/06, Henning Makholm [EMAIL PROTECTED] wrote:
 I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't work neither does unsharp mask, layer masks seems to work but get their alpha thresholded.Neither of which are something one usually needs in a situation where
one wants to stick to a colormap while editing.Smudge and layer masks are two things that I would appreciate for indexed images. I already have workarounds which let me return the results to the appropriate palette quickly, that is how I found that out.
 To do any real work on an indexed image I already have to go by RGB.
Your idea of real work is obviously very different from mine.I do lots of real work on indexed images.Yes. 
 Duplicating this behavior in GEGL would not be appropriate in my opinion,I don't really care whether it is duplicated in GEGL or outside it, aslong as the net effect of don't let my editing result in pixel colors
outside this small predeterined palette is still attainable with thesum of GEGL + futureGimp.That is essentially what I want, too. 
Henning Makholm This imposes the restriction on anyprocedure statement that the kind and type of each actual parameter be compatible with the
 kind and type of the corresponding formal parameter.Is that quote meant to be hard to understand? Or just to demonstrate how awkward english can be?

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Simon Budig
Henning Makholm ([EMAIL PROTECTED]) wrote:
 Scripsit Øyvind Kolås [EMAIL PROTECTED]
  I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't
  work neither does unsharp mask, layer masks seems to work but get
  their alpha thresholded.
 
 Neither of which are something one usually needs in a situation where
 one wants to stick to a colormap while editing.
 
  To do any real work on an indexed image I already have to go by RGB.
 
 Your idea of real work is obviously very different from mine.
 I do lots of real work on indexed images.
 
  Duplicating this behavior in GEGL would not be appropriate in my
  opinion,
 
 I don't really care whether it is duplicated in GEGL or outside it, as
 long as the net effect of don't let my editing result in pixel colors
 outside this small predeterined palette is still attainable with the
 sum of GEGL + futureGimp.

I wonder if a quantize to palette Gegl Op would solve these problems.
In most of the cases when people are asking for an indexed palette, the
palette is already determined somehow, either by importing from the
image or by editing for a specific hardware or certain texture
conventions.

In that case you really could have a quantize op, that maps all colors
in the images to the appropriate colors in the palette. You'd have all
the power of semitransparent layers, all tools would work as expected
for a given definition of expected  :), blurring would work etc.

I am pretty positive that these problems could be sorted out when we
know what people working with palette-based images want to have. I am
just guessing on the needs here...

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Øyvind Kolås

On 8/29/06, Simon Budig [EMAIL PROTECTED] wrote:

Henning Makholm ([EMAIL PROTECTED]) wrote:
 Scripsit Øyvind Kolås [EMAIL PROTECTED]
  I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't
  work neither does unsharp mask, layer masks seems to work but get
  their alpha thresholded.
I wonder if a quantize to palette Gegl Op would solve these problems.
In most of the cases when people are asking for an indexed palette, the
palette is already determined somehow, either by importing from the
image or by editing for a specific hardware or certain texture
conventions.

In that case you really could have a quantize op, that maps all colors
in the images to the appropriate colors in the palette. You'd have all
the power of semitransparent layers, all tools would work as expected
for a given definition of expected  :), blurring would work etc.

I am pretty positive that these problems could be sorted out when we
know what people working with palette-based images want to have. I am
just guessing on the needs here...


Having an implied conversion to RGB on input of indexed drawables is
the way GEGL will currently deal with such images.
Adding an op that converts this to 8bit/16bit/32bit integer grayscale
with a predefined, or optimally computed R,G,B palette is the natural
progression. That op could be used before saving/as a step towards
displaying data.

This allows implementations of all other processing and compositing
operations to be ignorant of indexed drawables, but is not an indexed
workflow, it will not work when multiple of the
original colors mapped to the same RGB triplet, but has a different
interpretation.

/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread David Gowers
On 8/29/06, Øyvind Kolås [EMAIL PROTECTED] wrote:
 I am pretty positive that these problems could be sorted out when we know what people working with palette-based images want to have. I am just guessing on the needs here...Having an implied conversion to RGB on input of indexed drawables is
the way GEGL will currently deal with such images.Adding an op that converts this to 8bit/16bit/32bit integer grayscalewith a predefined, or optimally computed R,G,B palette is the naturalprogression. That op could be used before saving/as a step towards
displaying data.This allows implementations of all other processing and compositingoperations to be ignorant of indexed drawables, but is not an indexedworkflow, it will not work when multiple of the
original colors mapped to the same RGB triplet, but has a differentinterpretation.I believe that last thing is a minor issue that should be addressable by an output op; Certainly, actually editing with identical colors that have different indices is unhelpful and confusing. Some kind of custom remapping for a certain set of colors would probably be the way to go.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Henning Makholm
Scripsit Simon Budig [EMAIL PROTECTED]
 Henning Makholm ([EMAIL PROTECTED]) wrote:

 I don't really care whether it is duplicated in GEGL or outside it, as
 long as the net effect of don't let my editing result in pixel colors
 outside this small predeterined palette is still attainable with the
 sum of GEGL + futureGimp.

 I wonder if a quantize to palette Gegl Op would solve these problems.

It would work for me, if the surrounding application allowed me to set
as a layer or image property that I want that operation to be applied
_immediately_ for each drawing operation I do.

 I am pretty positive that these problems could be sorted out when we
 know what people working with palette-based images want to have. I am
 just guessing on the needs here...

My concrete need is that I edit bitmaps with a specific color
convention - they can be seen e.g. at http://dk.trackmap.net/a.  I
use a system of ad-hoc software to convert the bitmap source to the
vector versions linked to below the image; this software depends on
the exact colormap in the picture, because different colors should be
vectorized in different ways.

[Before someone asks: yes, I have considered using a vector tool as
the master editing format, but I have not found one whose user
interface fits my way of working as well as Gimp does].

Now, when I edit in indexed mode I am sure that I don't accidentally
give a pixel a color that is off the expected one by a delta that is
too small for me to see. For example I sometimes accidentally select
the airbrush or pen tool and draw something. I may not notice this
until later, when it is too late to undo automatically, but at least
with the implicit quantization it is immediately clear to me which
pixels I need to repair manually. If I had worked in RGB mode I would
need to wonder whether I had accidentally airbrushed something from
255/255/255 to 252/252/252, which is impossible to see by eye.

Essentially, indexed mode helps me by making sure that what I see is
all I get. And does it *while* I edit: doing a separate quantization
step at the end of my work and then going over all of the image in
zoomed mode to look for glitches would be seriously bothersome.

-- 
Henning Makholm*Vi vil ha wienerbrød!*
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Øyvind Kolås

On 8/29/06, Henning Makholm [EMAIL PROTECTED] wrote:

Scripsit Simon Budig [EMAIL PROTECTED]
 Henning Makholm ([EMAIL PROTECTED]) wrote:
Now, when I edit in indexed mode I am sure that I don't accidentally
give a pixel a color that is off the expected one by a delta that is
too small for me to see. For example I sometimes accidentally select
the airbrush or pen tool and draw something. I may not notice this
until later, when it is too late to undo automatically, but at least
with the implicit quantization it is immediately clear to me which
pixels I need to repair manually. If I had worked in RGB
snip


Within the current gimp architecture you are asking for the job that
op would be performing to be done in a display filter, with a fixed
pallete (whilst working in RGB mode). This would cause all work being
done on the image to be displayed with the reduced palette. Thus allow
you to work non-indexed but see a reduced pallete result in
realtime.

/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Henning Makholm
Scripsit Øyvind Kolås

 Within the current gimp architecture you are asking for the job that
 op would be performing to be done in a display filter, with a fixed
 pallete (whilst working in RGB mode). This would cause all work being
 done on the image to be displayed with the reduced palette. Thus allow
 you to work non-indexed but see a reduced pallete result in
 realtime.

No - I don't only want to _see_ a reduced-palette result; I want to
actually _get_ a reduced-palette result. With an action purely on the
display level, I cannot see or correct inaccuracies on the underlying
pixel data; I cannot be sure that when I use the colorpicker tool it
is the standard color that I see that gets picked up, etc.

Additionally, it _would_ be rather cool to have the pixel data in each
layer be quantized but still be able to select partial layer opacities
while editing.

-- 
Henning Makholm The practical reason for continuing our
  system is the same as the practical reason
  for continuing anything: It works satisfactorily.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Øyvind Kolås

On 8/29/06, Henning Makholm

My concrete need is that I edit bitmaps with a specific color
convention - they can be seen e.g. at http://dk.trackmap.net/a.  I
use a system of ad-hoc software to convert the bitmap source to the
vector versions linked to below the image; this software depends on
the exact colormap in the picture, because different colors should be
vectorized in different ways.


This need could be solved using layer-masks and threshold. Or to
attack the problem with an unstable dialect of xml:

image width='751' height='650'
layers

layer name='brown'
 layer mode='apply_mask'
 filter mode='threshold'
 grayscalelayer/
 /layer
 layer color='rgb(0.5,0.5,0.2)'/

layer name='blue'
 layer mode='apply_mask'
 filter mode='threshold'
 grayscalelayer/
 /layer
 layer color='rgb(0.0,0.0,1.0)'/

layer name='violet'
 layer mode='apply_mask'
 filter mode='threshold'
 grayscalelayer/
 /layer
 layer color='rgb(0.0,1.0,1.0)'/

layer name='black'
 layer mode='apply_mask'
 filter mode='threshold'
 grayscalelayer/
 /layer
 layer color='rgb(0.0,0.0,0.0)'/

layer name='green'
 layer mode='apply_mask'
 filter mode='threshold'
 grayscalelayer/
 /layer
 layer color='rgb(0.0,1.0,0.0)'/

layer name='red'
 layer mode='apply_mask'
 filter mode='threshold'
 grayscalelayer/
 /layer
 layer color='rgb(1.0,0.0,0.0)'/
/layer
layer color='rgb(1.0,1.0,1.0)'/
/layer
/image

/Øyvind K.

--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Henning Makholm
Scripsit Øyvind Kolås [EMAIL PROTECTED]
 On 8/29/06, Henning Makholm

 My concrete need is that I edit bitmaps with a specific color
 convention - they can be seen e.g. at http://dk.trackmap.net/a.  I
 use a system of ad-hoc software to convert the bitmap source to the
 vector versions linked to below the image; this software depends on
 the exact colormap in the picture, because different colors should be
 vectorized in different ways.

 This need could be solved using layer-masks and threshold. Or to
 attack the problem with an unstable dialect of xml:

I'm not sure I can see what you're getting at, but are you suggesting
that I use a seperate layer for each color? That would make any kind
of editing extremely painful.

-- 
Henning MakholmDe kan rejse hid og did i verden nok så flot
 Og er helt fortrolig med alverdens militær
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread David Gowers
On 8/30/06, Henning Makholm [EMAIL PROTECTED] wrote:
Scripsit Øyvind Kolås [EMAIL PROTECTED] On 8/29/06, Henning Makholm My concrete need is that I edit bitmaps with a specific color convention - they can be seen 
e.g. at http://dk.trackmap.net/a.I use a system of ad-hoc software to convert the bitmap source to the vector versions linked to below the image; this software depends on
 the exact colormap in the picture, because different colors should be vectorized in different ways. This need could be solved using layer-masks and threshold. Or to attack the problem with an unstable dialect of xml:
I'm not sure I can see what you're getting at, but are you suggestingthat I use a seperate layer for each color? That would make any kindof editing extremely painful.When I saw it, I thought so too.
However, remember this is GEGL being discussed here. *GIMP* might well provide a way to back-propagate the result of an Op in the graph, which should take care of this okay.By back-propagate i mean, you draw on a layer, it get quantized before display -- and you can propagate that change back to the original layer.
It seems a highly desireable option to me, even for non-quantized images.(nor is GEGL in any way suited to implement back-propagation of the sort you described. It goes against its data model; Whereas this is suitable for GIMP to implement.)

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-25 Thread Sven Neumann
Hi,

On Fri, 2006-08-25 at 20:01 +0930, David Gowers wrote:
 Is there some simple way to achieve hard-edged rendering for the Ink
 tool? 

Should be a simple change, just turn off supersampling in the ink code.

 I find the hard edged rendering used in INDEXED mode best for drawing
 lineart, but dislike the other constraints (no drawing
 modes/opacity/layer modes) imposed by working in INDEXED mode.

Eeek, the way it acts in INDEXED mode is so ugly. Why would you want to
do this? 

 So far, I've tried to find the part of the code that handles indexed
 images without success.

Why would you look for it? That's completely unrelated here. The ugly
behaviour in indexed mode is just a shortcoming of the code that
combines regions.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-25 Thread David Gowers
On 8/26/06, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,On Fri, 2006-08-25 at 20:01 +0930, David Gowers wrote: Is there some simple way to achieve hard-edged rendering for the Ink tool?Should be a simple change, just turn off supersampling in the ink code.
Ah, the #define SUBSAMPLE 8 line. Changing it to 1 does indeed do what I wanted.
 I find the hard edged rendering used in INDEXED mode best for drawing lineart, but dislike the other constraints (no drawing modes/opacity/layer modes) imposed by working in INDEXED mode.Eeek, the way it acts in INDEXED mode is so ugly. Why would you want to
do this?Because it's easier to edit. If edges aren't defined in a binary way, it makes selecting portions of lineart and moving or removing them hard -- I have to set the threshold of whatever tool I'm using to a high value, but that high value will be not what I want for most of what I'm doing. I'm trying to avoid tedious fiddling.
Is there some specific part of the INDEXED behaviour that you are eeking about? I'm just looking for the hard edges.
 So far, I've tried to find the part of the code that handles indexed images without success.Why would you look for it? That's completely unrelated here. The uglybehaviour in indexed mode is just a shortcoming of the code that
combines regions.It's good to know that. I previously got the impression that you were indifferent to GIMP's usefulness for editing INDEXED images. I certainly hope that I can substantially improve indexed drawing specifically, when GEGL is in use and I understand it. I think it would be relatively simple to bring INDEXED drawing to the level of usefulness demonstrated by professional pixeling tools (ProMotion, or the older DeluxePaint and it's clones) with a sound architecture like that.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-25 Thread David Gowers
On 8/26/06, David Gowers [EMAIL PROTECTED] wrote:
On 8/26/06, Sven Neumann 
[EMAIL PROTECTED] wrote:
Hi,On Fri, 2006-08-25 at 20:01 +0930, David Gowers wrote: Is there some simple way to achieve hard-edged rendering for the Ink tool?Should be a simple change, just turn off supersampling in the ink code.
Ah, the #define SUBSAMPLE 8 line. Changing it to 1 does indeed do what I wanted.Actually, I take that back. I'm looking for normal supersampling  which is subsequently alpha-thresholded (exactly the way the ink and airbrush tools work in INDEXED mode.)
The behaviour of the Ink tool without supersampling is unacceptably chunky.So it looks like this may not be possible :(
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer