Hi,

Joseph Heled writes:

Perhaps this is nitpicking, but would like your comments.

(gimp 2.0.3)

After decomposing an image to HSV (in layers mode), Filters/Colors/Compose brings up the following dialog:

(*) RGB Red - image-HSV.jpg-3/value-8 Green - image-HSV.jpg-3/value-8 Blue - image-HSV.jpg-3/value-8

i.e. assumes RGB, and gives all channels the same layer.

1. If it possible to infer somehow that what I want (by default) is HSV, i.e the reverse? Even cluing on the layer names would work for the case where I make some changes in one layer and want to convert back.

Sure, the plug-in is far from perfect. There's some code in compose.c that tries to guess some useful default values for the layers it preselects. This code could certainly be improved. I am not sure though if it makes sense to attempt to guess the compose mode from the given layer names. It's probably more useful to remember the last used mode (which is what the plug-in does already).

2. Even assuming I have to check HSV manually, why not give the first 3 layers (when they exist) as the default? (for that to work, the order of the dialog has to match the order of created layers. right now it is the reverse)

As I said, IIRC there's already some code that attempts to select the layers called hue, value, saturation if you select HSV mode. It doesn't seem to work very well though. We would happily accept a patch that improves this.

Sven

Joseph Heled wrote:

Perhaps this is nitpicking, but would like your comments.

(gimp 2.0.3)

After decomposing an image to HSV (in layers mode), Filters/Colors/Compose brings up the following dialog:

(*) RGB Red - image-HSV.jpg-3/value-8 Green - image-HSV.jpg-3/value-8 Blue - image-HSV.jpg-3/value-8

i.e. assumes RGB, and gives all channels the same layer.

1. If it possible to infer somehow that what I want (by default) is HSV, i.e the reverse? Even cluing on the layer names would work for the case where I make some changes in one layer and want to convert back.

I don't see how this could be done reasonably. I guess that if you do a decompose that compose could get at the information if you attached a parasite or something...

2. Even assuming I have to check HSV manually, why not give the first 3 layers (when they exist) as the default? (for that to work, the order of the dialog has to match the order of created layers. right now it is the reverse)

That sounds sane, and shouldn't be too difficult to do. Please open a bug report for it so that it doesn't get forgotten about :)

Cheers, Dave.

Hi,

Dave Neary writes:

2. Even assuming I have to check HSV manually, why not give the first 3 layers (when they exist) as the default? (for that to work, the order of the dialog has to match the order of created layers. right now it is the reverse)

That sounds sane, and shouldn't be too difficult to do. Please open a bug report for it so that it doesn't get forgotten about :)

Nah, it sounds rather insane to use the first 3 layers since the information which layer to use is all there in the layer names.

Sven

Hi,

Sven Neumann writes:

IIRC there's already some code that attempts to select the layers called hue, value, saturation if you select HSV mode. It doesn't seem to work very well though. We would happily accept a patch that improves this.

I had a look at the plug-in source code and it seems there is no such code. It was probably part of some patch then that wasn't applied or I just imagined it. Anyway, it would be a good idea to add such code to the plug-in. Perhaps compose.c and decompose.c should even be moved to their own directory where they can share a common header file with the strings that identify the layers.

Sven

Hi,

Sven Neumann wrote:

It's probably more useful to remember the last used mode (which is what the plug-in does already).

I think it would be even more useful to set the compose mode to the last used decompose mode, rather than the last used compose mode (if you get my meaning).

As I said, IIRC there's already some code that attempts to select the layers called hue, value, saturation if you select HSV mode. It doesn't seem to work very well though. We would happily accept a patch that improves this.

What should it do? Set the layers in function of the compose mode? If the mode is RGB to start with and I choose HSV, should I then re-set the layers I'll use?

Cheers,
Dave.

Hi,

Dave Neary writes:

It's probably more useful to remember the last used mode (which is what the plug-in does already).

I think it would be even more useful to set the compose mode to the last used decompose mode, rather than the last used compose mode (if you get my meaning).

Well, this is doable but it would require closer interaction between the two plug-ins. compose could read the last-used-parameters set by decompose. A prerequisite for this would be to let the two plug-ins share a common header.

As I said, IIRC there's already some code that attempts to select the layers called hue, value, saturation if you select HSV mode. It doesn't seem to work very well though. We would happily accept a patch that improves this.

What should it do? Set the layers in function of the compose mode? If the mode is RGB to start with and I choose HSV, should I then re-set the layers I'll use?

That's what the plug-in should attempt to do for you.

Sven

Hi,

Sven Neumann wrote:

Well, this is doable but it would require closer interaction between the two plug-ins. compose could read the last-used-parameters set by decompose. A prerequisite for this would be to let the two plug-ins share a common header.

Or merge the two plug-ins into one...

Cheers, Dave.

Hi,

Dave Neary writes:

Well, this is doable but it would require closer interaction between the two plug-ins. compose could read the last-used-parameters set by decompose. A prerequisite for this would be to let the two plug-ins share a common header.

Or merge the two plug-ins into one...

That would be an option. But please not by merging the code into a single file.

Sven

Here is what I would do, and it wouldn't be very hard to code up:

1) Make decompose attach a parasite called "decompose-info" to each layer it produces, specifying the type of decomposition and listing the source layer and the layers that are created.

2) Split compose into two PDB functions, called "compose" and "recompose".

A) "Compose" would allow you to use any set of equal-sized grayscale layers to assemble into an RGB layer. (One of the annoyances of "compose" now is that it only works on layers that were produced using "decompose".)

B) "Recompose" would look for a "decompose-info" parasite in the active layer. Not finding one, it would pop an error message and exit. Finding one, it would use the information there to assemble an RGB layer, and substitute the result for the layer that was originally decomposed. This could all happen automatically, without popping a dialog.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

On Wednesday 21 July 2004 09:20 pm, you wrote:

For a start, I'm attaching a patch that makes "compose" use the layers in reverse order (if the image has more than MIN_COMPOSE_LAYERS = 3 layers, otherwise use old behavior). No attempt is currently made to guess the mode.

Sorry, should read "...has *at least* MIN_COMPOSE_LAYERS = 3 layers".

This solution is not perfect either, but arguably not worse than before, and in many cases much better.

Markus.

On 21 Jul 2004, Sven Neumann wrote:

Dave Neary writes:

I think it would be even more useful to set the compose mode to the last used decompose mode, rather than the last used compose mode (if you get my meaning).

Well, this is doable but it would require closer interaction between the two plug-ins. compose could read the last-used-parameters set by decompose. A prerequisite for this would be to let the two plug-ins share a common header.

Why not put a parasite on the images created by decompose saying what mode the image was decomposed with, and which layers (or images, depending on the options when you decomposed) corrispond to which channels? Then there would be no need for guessing, and you could work with more than one decomposed image (or layer, for that matter) at once. You would still want to allow the user to switch to some other layer for the recompose, of course, but it would be nice to default to the way it was decomposed.

Rockwalrus

Hi,

"William Skaggs" writes:

A) "Compose" would allow you to use any set of equal-sized grayscale layers to assemble into an RGB layer. (One of the annoyances of "compose" now is that it only works on layers that were produced using "decompose".)

Huh? At the moment compose doesn't know anything about decompose. Why shouldn't it work on layers not produced by decompose?

Sven

Sven Neumann wrote:

Huh? At the moment compose doesn't know anything about decompose. Why shouldn't it work on layers not produced by decompose?

Well, I'm a bit behind the times on this one. I haven't used compose much for the past 3-4 months, and as I recall this issue was there then, but it doesn't seem to be there now.

The issue that *is* there now is that compose shows a bunch of pixbuf-related libgimp-critical error messages whenever I try to run it, but of course that's a different thing.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi,

"William Skaggs" writes:

The issue that *is* there now is that compose shows a bunch of pixbuf-related libgimp-critical error messages whenever I try to run it, but of course that's a different thing.

The new code in gimppixbuf.c made a wrong assumption. Good that I had added a warning for the case that the assumption was violated. I've fixed the problem now by adding code that handles grayscale previews.

Sven