splice (adding tile gridding gaps)

[anthony]

convert $infile -crop ${xspace}x${yspace} +repage \
-background $vcolor -gravity west -splice ${thickness}x0 \
-background $hcolor -gravity north -splice 0x${thickness} \
miff:- | montage - -geometry +0+0 -tile ${nx}x${ny} ${inname}_grid_expand.jpg

No need for the montage, and default gravity will be fine...
In fact you do not even need to know number of tiles it will create

Code: Select all

convert $infile \
       -crop ${xspace}x0 +repage -background $vcolor -splice ${thickness}x0 +append \
       -crop 0x${yspace} +repage -background $hcolor -splice 0x${thickness} -append \
       ${inname}_grid_expand.jpg

The problem however is that this can do a LOT of image creation, copying and processing. The smaller the tile, the more extra 'house-keeping' processing it needs.

The -splice operator gets around that by creating one destination image, and then copying source pixels with appropriate gaps to that image. Though that is best done at pixel level. FX could do it that way, but it would be complex and slow.

Added to IM Examples, Transforms, Spacing out Tiles (when image above appears)
http://www.imagemagick.org/Usage/transf ... cing_tiles

[fmw42]

convert $infile -crop ${xspace}x${yspace} +repage \
-background $vcolor -gravity west -splice ${thickness}x0 \
-background $hcolor -gravity north -splice 0x${thickness} \
miff:- | montage - -geometry +0+0 -tile ${nx}x${ny} ${inname}_grid_expand.jpg

No need for the montage, and default gravity will be fine...
In fact you do not even need to know number of tiles it will create

Code: Select all

convert $infile \
       -crop ${xspace}x0 +repage -background $vcolor -splice ${thickness}x0 +append \
       -crop 0x${yspace} +repage -background $hcolor -splice 0x${thickness} -append \
       ${inname}_grid_expand.jpg

The problem however is that this can do a LOT of image creation, copying and processing. The smaller the tile, the more extra 'house-keeping' processing it needs.

The -splice operator gets around that by creating one destination image, and then copying source pixels with appropriate gaps to that image. Though that is best done at pixel level. FX could do it that way, but it would be complex and slow.

Neat! Thanks. I had been trying to skip the pipe and montage by simply using -layers merge, but the result had a gap in it that I could not explain.

[anthony]

How were you positioning the tiles using -layers merge?
That would be a interesting alternative.

If you were using some calculations, such a method could add a little 'random jitter' to the placements, so things are not quite so 'regular'

[fmw42]

This what I tried. Skip the +repage and simply tried to use the virtual canvas info to put them back together.


infile="lena.jpg"
hcolor="white"
vcolor="black"
thickness=3
xspace=24
yspace=24
inname=`convert $infile -format "%t" info:`
convert $infile -crop ${xspace}x${yspace} \
-background $vcolor -gravity west -splice ${thickness}x0 \
-background $hcolor -gravity north -splice 0x${thickness} \
+gravity -background none -layers merge ${inname}_grid_expand2.png

But it puts a gap near the left side and near the bottom.

[anthony]

I am amazed that even worked!!!

I think it depends on just how splice actually effects the offsets in the images. I am not certain that has even been looked at closely. Hmmm yes the offsets after the splice seem to go weird. -- added to my to-do list

Hmmm using FX to calculate correct offsets (no outside border)....

Code: Select all

convert rose: -crop 10x10 \
        -set page '+%[fx:page.x+3*page.x/10]+%[fx:page.y+3*page.y/10]' \
         -background skyblue -layers merge +repage  grid_tile_fx.png

Where '3' is the gap and '10' is the tile size. Add a border if you want to finish the job!

Added to the previous 'spacing out images' example area. (it has appeared when the above image appears)
http://www.imagemagick.org/Usage/transf ... cing_tiles

[VanGog]

It's OK, I will paste it to .sh

[fmw42]

It's OK, I will paste it to .sh

Your problem may be with line endings (and "gremlins" -- unprintable characters) between copying from unix and pasting to windows. You may need to paste into a text editor and change line endings and remove gremlins. Then paste that into your terminal window.

[fmw42]

I think it depends on just how splice actually effects the offsets in the images. I am not certain that has even been looked at closely. Hmmm yes the offsets after the splice seem to go weird. -- added to my to-do list

Are you saying that there is a bug in the virtual canvas (page geometry and offsets) in the crop results? If not, it is odd that most of the image got created correctly without gaps.

[anthony]

I think it depends on just how splice actually effects the offsets in the images. I am not certain that has even been looked at closely. Hmmm yes the offsets after the splice seem to go weird. -- added to my to-do list

Are you saying that there is a bug in the virtual canvas (page geometry and offsets) in the crop results? If not, it is odd that most of the image got created correctly without gaps.

No I'm saying that virtual offsets with splice has not been looked into, and seems to producing unusual results.

In any case even if it was working, it would not help. As each tile would probably be in the same location as before (just as it is for -border, which I know does update the virtual canvas size, while preserving the offset).

In summary, tiles are larger due to the splice, but the tile location would not have changed to 'fit' the larger tiles together.

In any case when using layers merge (or even mosaic!), there is no need for the splice. Just let the 'layer background canvas' show though. That is what I did in the alternative solution.

The only problem with using 'merge' is that it will not add outside borders, as final image size from a 'merge' will always 'touch' some 'layer image'. Even the actual offset does not matter is you do a +repage afterward. Only the placement of the tiles relative to each other.

The solution to that, is use 'mosaic', which will let you add a top-left gap, by adding a extra offset to the offset calculations.

To add a bottom-right edge gap, you'd have to calculate the actual final canvas size and use 'mosaic' or 'flatten', and that means you will then need to know the number of tiles across and down (more calculation).

I think it is just simplier to use 'merge' and then splice or add borders of the appropriate size as a separate step.

Of course this would work better in IMv7 where you can use preset 'user settings'...
As soon as I enable the use of percent escapes within %[fx:....] expressions
I plan to do that after I fix percent escape usage in 'setting options'.
Then perhaps back to "magick" scripting argument handling options.
With that done. You will be able to write a pure "Magick" script to do this job! - No Shell (or DOS) required!

[VanGog]

As soon as I enable the use of percent escapes within %[fx:....] expressions
I plan to do that after I fix percent escape usage in 'setting options'.
Then perhaps back to "magick" scripting argument handling options.
With that done. You will be able to write a pure "Magick" script to do this job! - No Shell (or DOS) required!

Do you speak about ability of IM7 to do scripting? So some instructions would be included from file? Do you speak about ability to do a bit of own "programming" (or scripting) around IM?

Edit:
Need no answer, as I read back this post:
viewtopic.php?f=1&t=21061&start=15#p85657

[anthony]

This what I tried. Skip the +repage and simply tried to use the virtual canvas info to put them back together.

Code: Select all

infile="lena.jpg"
hcolor="white"
vcolor="black"
thickness=3
xspace=24
yspace=24
inname=`convert $infile -format "%t" info:`
convert $infile -crop ${xspace}x${yspace} \
-background $vcolor -gravity west -splice ${thickness}x0 \
-background $hcolor -gravity north -splice 0x${thickness} \
+gravity -background none -layers merge ${inname}_grid_expand2.png

But it puts a gap near the left side and near the bottom.

After thinking about this further...

I am still amazed that it works as you have it. Splice must be doing some maths on the size and offset of each image that is being spliced. It must also be assuming that 'image with an offset' was from a tile crop of a larger image.

Looks like it only happens on the left and bottom tiles only, and that explains what is going wrong.

The left and bottom tiles are smaller, thus the splice when given just the 'one image with an offset', assumes that the smaller image was part of a tile cropping using that image's size. This means its calculation of the new offset for a spliced file goes wrong, as the image size is a reminder, and not the real tile crop size that was used. The result is that tile is given an extra offset position.

EG: smaller tile size => more tiles between this position and the top left edges,
multiply the calculated number of tiles, by inserted splice amount => larger offset.

That is why your method --tile crop, splice, mosaic -- actually worked, and also why it is failing! It has no other information about the tile crop, but to assume the image size is the tile crop size! So reminder tiles go wrong.

Really it is a assumption about why an image has an offset, and not a particularly good assumption, either!



I still think adding a special geometry flag option to -splice to "insert a grid into an image" is the better overall solution. One that would be much faster than any tile crop, method, as it will only generate one new image, rather mutliple image tiles. In the extreme case of 'single pixel tiles' that is a LOT of images!

That was why I developed the "scale, and overlay a grid" method of generating grids of pixels.

A splice grid option would work well for both. Scaled pixel grids, and for a grid of image tiles.