rearrange vertical pixel row

[snibgo]

Sort programs often come with an option to randomly swap elements. The version of sort that comes with Cygwin can do this. This greatly simplifies Fred's method: write appropriate lines to a text file, random-sort them, and incorporate them in a convert command.

[snibgo]

"-spread" also interpolates between integer coordinates. This can be seen with:

Code: Select all

convert -size 100x100 xc:red xc:blue +append -virtual-pixel edge -spread 1 r.png

Many of the resulting pixels near the boundary between red and blue are not exactly red or blue.

[peterthebest]

when i use this

convert \
\( -size 1x70 gradient: -rotate -90 \) \
\( -size 1x46 gradient: -spread 46 \
-channel R -separate +channel \) \
\( -size 1x1 xc: \) \
-scale 70x46\! -combine \
\
rose: +swap \
-compose Distort -set option:compose:args 35x23 -composite \
rose_rand.png

what do i have to change to use my test image "uno.jpg" (instead of the rose) which is located on desktop?

[fmw42]

what do i have to change to use my test image "uno.jpg" (instead of the rose) which is located on desktop?

try

Code: Select all

convert \
\( -size 1x70 gradient: -rotate -90 \) \
\( -size 1x46 gradient: -spread 46 \
-channel R -separate +channel \) \
\( -size 1x1 xc: \) \
-scale 70x46\! -combine \
\
path_to_desktop/uno.jpg +swap \
-compose Distort -set option:compose:args 35x23 -composite \
uno_rand.png

[snibgo]

As I said upthread, the built-in "rose:" is 70x46 pixels. Change the numbers to your own dimensions.

[fmw42]

As I said upthread, the built-in "rose:" is 70x46 pixels. Change the numbers to your own dimensions.

Thanks for catching that.

Code: Select all

convert \
\( -size 1x70 gradient: -rotate -90 \) \
\( -size 1x46 gradient: -spread 46 \
-channel R -separate +channel \) \
\( -size 1x1 xc: \) \
-scale WxH\! -combine \
\
path_to_desktop/uno.jpg +swap \
-compose Distort -set option:compose:args 35x23 -composite \
uno_rand.png

where WxH is the dimensions of uno.jpg

[snibgo]

And the first few:

Code: Select all

\( -size 1xW gradient: -rotate -90 \) \
\( -size 1xH gradient: -spread H \

And, as I said upthread:

Code: Select all

-set option:compose:args 35x23

change this to half the new dimensions, or use:

Code: Select all

-set option:compose:args 100%x100%

[anthony]

"-spread" also interpolates between integer coordinates. This can be seen with:

Code: Select all

convert -size 100x100 xc:red xc:blue +append -virtual-pixel edge -spread 1 r.png

Many of the resulting pixels near the boundary between red and blue are not exactly red or blue.

Well to me that would be a bug! The document while very minimal, is clear that it is supposed to only swap pixels.

To me that would mean spread should....
1/ swap pixels without interpolation or other change
2/ Not involve virtual pixels
3/ not duplicate/delete a pixel (histogram color counts remain the same)

Come to think of it. Spread is one of the operators I never really had a close look at, as I always though it was simple enough that it could not possibly be wrong! Well obviously that was wrong!

[snibgo]

The inner x-loop of "-spread", in effect.c, is:

Code: Select all

    for (x=0; x < (ssize_t) spread_image->columns; x++)
    {
      (void) InterpolateMagickPixelPacket(image,image_view,
        UndefinedInterpolatePixel,(double) x+width*(GetPseudoRandomValue(
        random_info[id])-0.5),(double) y+width*(GetPseudoRandomValue(
        random_info[id])-0.5),&pixel,exception);
      SetPixelPacket(spread_image,&pixel,q,indexes+x);
      q++;
    }

InterpolateMagickPixelPacket interpolates between pixels. So each new pixel takes its value from some nearby random floating-point coordinate. It doesn't swap pixels.

[anthony]

[magick]

We can reproduce the problem you posted and have a patch in ImageMagick 6.9.2-2 Beta, available by sometime tomorrow. Thanks.

[anthony]

Looking at the update. It does seem a lot better without virtual pixels becoming involved, and without pixel mixing.

However there is a small problem. A pixel that is swapped with a pixel forward of the current processing point may be swapped again, perhaps further forward. As such there is a skew, in that pixels could be swapped further than expected in the left and downward directions.

You can see this in this 'before-after' image...

Code: Select all

magick -size 50x50 xc:red xc:blue -append \( +clone -spread 1 \) +append show:

Note that some red pixels can spread a very LONG way into the blue area. Also you see occasional blue pixels spreading upward up to 2 pixels after being swapped twice along the left to right pass of the last 'red' row of pixels. Rare but does happen.

This 'double swapping' problem is not going to be easy to solve, and may not be worth pursuing it at this point.

The solution would require keeping track of pixels that have already bee swapped, and not allowing you to select those pixels for a second swap (say using a separate channel the new destination image). If a already swapped pixel is selected, than another random pick should be made to 'try again', so as to provide a proper 'limited spread' shuffle. There should always be a unswapped pixel available, even if that means swapping the pixel with itself, so it should still complete.

Though the directional 'skew' may be solved by doing 2 passes through the spread with the image -transverse distorted.
For example

Code: Select all

magick -size 50x50 xc:red xc:blue -append \( +clone -spread 1 -transverse -spread 1 -transverse \) +append show:

Of course pixels can still spread further than intented, and twice as far as expected, BUT at least the spread is uniform.


I also see that the old interpolated/virtual pixel version of spead is also still available in library. Perhaps that can be broken out as a added feature to the shell API, say using the '+' form of the operator.

[anthony]

Hmmm because of the bias, perhaps the pixel preservation should use a '+' form. While we use the original as 'normal' mode, and adjust the documentation to reflect the actual nature of spread. IE: interpolated spread by default.

What are the thoughts of you Fred? Snibgo?

[fmw42]

Anthony,

I believe that Magick has already made -spread sensitive to -interpolate. I think it is in 6.2.0.1 beta. The default is no interpolation as you wanted. Use -interpolate bilinear -spread X to have it be bilinear interpolated. (I needed to have the bilinear option available to preserve the behavior of some of my scripts)

[anthony]

Anthony,

I believe that Magick has already made -spread sensitive to -interpolate. I think it is in 6.2.0.1 beta. The default is no interpolation as you wanted. Use -interpolate bilinear -spread X to have it be bilinear interpolated. (I needed to have the bilinear option available to preserve the behavior of some of my scripts)

The interpolate and virtual pixel effects was the issue. The documentation of spread is that it was swapping pixels, not interpolating and loosing pixel data.

The LASTEST beta, is that spread now actually swaps pixels.
When the Usage updates you will see this in
http://www.imagemagick.org/Usage/transform/#spread

I think it is important that users have some way of randomly spreading pixels without pixel data loss.