Legacy ImageMagick Discussions Archive

Channels in PerlMagick are specified like this: channel=>'rgb' or channel=>'red' or channel=>'cmyk'.

magick wrote:Channels in PerlMagick are specified like this: channel=>'rgb' or channel=>'red' or channel=>'cmyk'.

Thanks, I gather from this that my Red | Green | Blue should be 'rgb', which is not in the lists I see in the PerlMagick doc:

channel=>{All, Default, Alpha, Black, Blue, Cyan, Gray, Green, Index, Magenta, Opacity, Red, Yellow}

Out of curioisity, how should one (or should one at all) use (Red | Green) ?

Rick

Try something like channel=>'rg'. This may work as well channel=>'red,green,blue'. And even channel=>'red|green|blue'. Not sure on that one.

magick wrote:Try something like channel=>'rg'. This may work as well channel=>'red,green,blue'. And even channel=>'red|green|blue'. Not sure on that one.

Both 'rgb' and 'grb' work identically; same as 'reg,green,blue' and 'green,red,blue', so I think that 'rg', 'red,green' and such make sense. But my particular tests with 'rg' and other two-channel choices give white images, so I really don't know how to interpret that. It could be that I don't understand what I should get.

I'm actually confused by using single-color channels. I get solid colors for just 'red', for instance, as opposed to something that looks like a gradient. I expected (perhaps wrongly) that 'red' would give the equivalent of the red component of the image generated by the 'rgb' choice of channel. (I'm using the perl script posted a few panels above.)

Using 'red|green|blue' gives an intelligent 'non-numeric' error.

I think it makes sense to add the 'rgb' choice to the PerlMagick docs.


Thanks,

Rick

We added CMYK and RGB as choices to the PerlMagick docs available sometime tomorrow.

From Anthony's world of magick (http://www.imagemagick.org/Usage/canvas ... nt_distort):

However be warned that the gradient does not just 'stop' but continues to change beyond those points. Traditionally a barycentric gradient will be limited to within the enveloping triangle of points used to generate it.
For example..

convert -size 100x100 xc: \
-sparse-color Barycentric '30,0 red 0,80 blue 99,99 lime' \
\( -size 100x100 xc:black -fill white \
-draw 'polygon 30,5 5,80 95,95' \) \
+matte -compose CopyOpacity -composite \
-fill white -stroke black \
-draw 'circle 30,5 30,7 circle 5,80 5,82 circle 95,95 95,97' \
sparse_bary_triangle.png




FUTURE: when a "Triangular Mesh" method is added in the future then you will get this type of result for the 'mesh' of points given.

Regarding the last statement, does this mean that this future option will produce only the color within the triangle, as in the example?

That will be great, if so. I'm using this on a huge image with thousands of individual triangles, and it certainly adds to the cost to mask out the unwanted areas.

This is a fabulous addition to ImageMagick --- many thanks to all who developed it.

Rick

rmabry wrote:From Anthony's world of magick (http://www.imagemagick.org/Usage/canvas ... nt_distort):

However be warned that the gradient does not just 'stop' but continues to change beyond those points. Traditionally a barycentric gradient will be limited to within the enveloping triangle of points used to generate it.
For example..

convert -size 100x100 xc: \
-sparse-color Barycentric '30,0 red 0,80 blue 99,99 lime' \
\( -size 100x100 xc:black -fill white \
-draw 'polygon 30,5 5,80 95,95' \) \
+matte -compose CopyOpacity -composite \
-fill white -stroke black \
-draw 'circle 30,5 30,7 circle 5,80 5,82 circle 95,95 95,97' \
sparse_bary_triangle.png




FUTURE: when a "Triangular Mesh" method is added in the future then you will get this type of result for the 'mesh' of points given.

Regarding the last statement, does this mean that this future option will produce only the color within the triangle, as in the example?

That will be great, if so. I'm using this on a huge image with thousands of individual triangles, and it certainly adds to the cost to mask out the unwanted areas.

This is a fabulous addition to ImageMagick --- many thanks to all who developed it.

Rick

Hello Rick,

Anthony can answer this best, but as I was involved and scripted this first as a test for Anthony, I believe that for now it will need to be masked. The idea has been to eventually get to the point where there will be an option to feed a triangular mesh to IM and have the mesh interpolated from the colors set at each vertex. This is the first step. But only Anthony can give you some idea of how busy he is and probably cannot give you a clear timeframe for that eventuality. I will let Anthony get back to you further on this when he can, but I wanted to give you some background from what I know.

Fred

I am planing to do this and even picked out the triangular mesh algorithm.

My current probelm is figuring out how to input a triangular mesh
of points. You have points, and lines, and triangules, but how do you read this in and pass around the data in the library?

My current thinking is for -sparse color to do a delaney triangulaization of the input points to generate the mesh. that is well within its scope.

BUT this is NOt only for -sparse-color, but also needed for -distort
where you need to specify a mesh of control points, rather than a single points with color.

Also you may actually like to define how the triangles themselves are arranged. For example you probably would really like to have lots of long thin triangles when you are trying to 'fill in' the background in an image so as to remove some text or logo.

This is where I am stuck! I don't want to implement something that will not work very well later. Ideas and suggestions are welcome.

See my next post about the weird internals...


As for color outside the triangle mesh (a three point mesh being the smallest) the algorithms don't define what to do here, so I planned to simply use the same 'undefined' color I used in -distort for perspective 'sky'. -mattecolor.

As such if you set -mattecolor to 'none' then you should automatically get a shape mask around your single triangle mesh.
how to generate an anti-aliased edge for these triangles is another problem!

Channels and the list of floats.


When I was implementing -sparse-colors I had a real problem.

-distort only needed a list (array) of floating point values to be passed around. But -sparse-colors needed a mix of floating point values and colors.

ASIDE: +sparse-colors will only need points, with colors coming from the given image!

The problem was how to pass colors to the library in an array of floats! Not only that how to do so and allow the normal use of -channel setting to restrict modifications to specific channels.

The solution was a wrapper routine whcih converted the 'string' argument into the required list of floating point values.

As such as given previously. the string

'30,0 red 0,80 blue 99,99 lime'

would be converted to list of floating point numbers

30, 0, 1, 0, 0, 0, 80, 0, 0, 1, 99, 99, 0,1,0

with the colors showing the relationships.

The NUMBER of color values used however is also variable!!!!
As the default is RGBK (yes blacK is a default channel) but the input image is only RGB, then only three numbers is required between each coordinate.

If you change -channel to just R, then only ONE color value is needed between each coordinate.

Not only that the input string may only consist of coordinates with the color values being extracted from the input source image! (not yet implemented) The resulting floating point array however will still be calculated and come out in the same style, just with colors comming from an image rather than a color name.

The use of '%' escapes (command line only) could be used to do this NOW but in a awkward and unweildly way. You will notice I have NOT documented its use, at this point, except in this discussion.


I never meant for API's like PerlMagick to only deal in floating point values, But the interface for API's are different from command lines and I figured PerlMagick could have a different way of specifying the point/color arrangement that would make more sense to the language, and could convert to floats in a different way. Or if worse comes to worse it could call the same 'string' to 'floats' wrapper


Now this function is not classed as fully 'settled'. and I am open to ideas as to a better way to solve this, and the 'trianglur mesh' problems I am having. If I can get this solved then naturally I will be able to proceed and continue to improve this operator.


ASIDE: One idea I want to use thsi for is to specify points around the edge of some unwanted text or logo, and have Im fill-in the space using the colors from those points, thus removing that logo from the image almost as if it wasn't there.

I have see an web artical on this but I can't seem to find it in my bookmarks

CCing this into the discussion this concerns...

fmw42 wrote:You may already have thought about this, but from our discussions of implementing other functions, your response, often, has been that IM cannot handle arguments that are mixes of strings and numerical values. With -distort you have a distort name (e.g. perspective) and then a quoted string of values. I have suggested other functions that need mixes of strings and numerical values within the quotes, but you have said that currently that is not feasible.

There are two aspects to this.

1/ the number of arguments that follow a option
is fixed. -distort must be followed by two arguments. -random by 2 arguments, +random by one argument, etc...

Allowing the ability to have variable arguments depening on method needs or 'options of operation' is something that is on the proposal, and should be relatively easy to implement in a single pass system.

For example a -distort noop would not require any arguments. The distort effects desired are then controlled by the secondary distortion settings, such as viewport, scale, filters and virtual-pixels.

2/ The other aspect is the internal MagickCore Library. This library is basically a C library usually with as simple a call structure as possible, Which becomes fixed. Other API's like Perl and Ruby also follow this limitation, which is easily seen with the current sparse color implementations.

For example... the DistortImages() function takes a integer of the number of values and a pointer to an array of that many floating point values. This leaves no room for adding 'labels' or other optional controls in the MagickCore function call arguments. Thus my reluctance to add such requests.

The problem has really come to a head for the new 'sparse colors' which requires the an array of coordinates and colors!!! In many ways this is very similar to the enumerated TXT format, and it was something I considered (and am still considering) as a 'read arguments from file' type format.

However for the current 'simplier' sparse color methods, this needs to be converted into a simple array of values so that it can use the the various distort least-squares fitted functions to generate a set of color equations to map out on the given image.

Because of this it was easier to directly convert those colors into that complex array previously described. I am starting to think this was a mistake.

With I think we may need is to complicate the API calling structure, (separating sparse colors from distort) to a linked list of coordinate-color pairs.

How to fit such a call structure into the PerlMagick and RMagick API is unknown.

What are the views from the others in this discussion, especially that of rmagick?