Placing images by co-ordinates given in the file name?

[Lumo]

This task is intended to to help my workflow on a desktop PC. The task is about assembling tiles into an image based on co-ordinates in the file name of each tile. I haven't been able to find anything online which does this. The only scripts I've found are for GIMP and Photoshop and they assemble tiles into squares of whole rows and columns, and they cannot handle overlapping tiles. The Mosaic function of ImageMagick seems to be the same.

The file name format of each image is X1,Y1,X2,Y2,Xp,Yp.png where each part of the file name is a variable. The first 2 numbers describe the co-ordinates of the lower left corner of the tile. The next two are for the upper right corner. The last two are the resolution of the image in X and Y. I can change the format of the file name.

Does anyone know how to do this in ImageMagick? I've asked the same question on GIMPChat.com last weekend and on Reddit today, but so far I haven't got a solution. My logic for doing this in GIMP can be seen here: http://www.reddit.com/r/GIMP/comments/2 ... ic_into_a/ but I doubt that method would translate well to ImageMagick.

[fmw42]

You would need to use the OS to extract the argument from the filenames and put them into variables. This part is OS dependent. With IM you would only need to know the upper left corner of each tile (presumably relative to some common coordinate system of the mosaic result) . Then one could write a loop over each image (also OS dependent), extract the information you need about placement and mosiac each tile using -mosiac. If the number of tiles is not too long, a loop can be used to set up the coordinates and the filenames in a list and do it all in one mosaic command. If the tiles overlap, then one needs to decide in which order to overlay them. Doing blending would be possible but harder.

What OS are you on and version of Imagemagick?

Can you upload a few example tiles to someplace like dropbox.com (public folder) and put the URL(s) here. Then depending upon your OS, someone on the forum can probably write up a script to do this.

[Lumo]

Thanks, that was a very prompt and informative reply.

I currently have the latest version of ImageMagick, 6.8.9-5 and I'm running Windows 7 x64, and I also have access to Debain (x86) - but not all the time so I'd prefer to work in Windows 7.

The upper left corner would be X1,Y2 so I've got that covered . Do you mean that a Windows Batch script is the starting point? The number of tiles will be huge, so I think it's best to use the method that isn't one single Mosaic command. I'm very interested to know how to combine an OS script with a function like Mosaic

Currently the co-ordinates aren't in pixels and need to be multiplied by 3.2 to get a 1:1 unit:pixel mapping. That part is easy - just worth noting

If anyone wants the sample tiles please PM me for a link

[Bonzo]

I am a windows user but have a localhost and use Imagemagick through php which is another option.

You could use something like glob() to read in the files and then explode the filename to get the location. Personally I would probably use convert to place the images as you have lots of other options.
One problem could be "The number of tiles will be huge" although a few years ago I resized and modified 30,000 images but I can not remember how I did it now without php timing out - I may have changed the default timeout value in php from 30 sec to something like 5hrs. I also remember changing the glob() to read all images from 1-9, a-d etc. and worked them in batches.

[snibgo]

Why is so much data given for each image? One corner would define a location; two corners define a scale and rotation. What is the third pair for?

[Bonzo]

From the OP's first post:

The first 2 numbers describe the co-ordinates of the lower left corner of the tile. The next two are for the upper right corner. The last two are the resolution of the image in X and Y

[fmw42]

Currently the co-ordinates aren't in pixels and need to be multiplied by 3.2 to get a 1:1 unit:pixel mapping. That part is easy - just worth noting

That is important. Also is your Y coordinate up or down. That is, is it an actual geographic coordinate or an image related coordinate. Also do you have negative coordinates?

You have 529 files at 256x256 size. The final image would be at least 832 MBytes. This means that the script will build up to that size and need to open and write a file of nearly this size every time it reads and image. This will slow down drastically and may not be practical. It is certainly very big and may not fit in memory considering that multiple copies will be needed in memory. One may have to use memory management that uses disk space for memory.

We can certainly create a script for you, but it probably will take an extremely long time to run and may be too long for any practical purpose.

I work on Mac OS. I could create a script for you for that environment. But perhaps one of the Windows users would be better providing a Batch script or a PHP script for Windows.

[snibgo]

The last two are the resolution of the image in X and Y

Yes, I saw that, but don't know what it means. If we know the required coordinates for two opposite corners, what extra information does the "resolution" provide? What should be done with this information?

[fmw42]

The last two are the resolution of the image in X and Y

Yes, I saw that, but don't know what it means. If we know the required coordinates for two opposite corners, what extra information does the "resolution" provide? What should be done with this information?

His resolution is in pixels, but his coordinates are not, and need a multiplication factor to convert to pixels. Still redundant. But one could provide the two corners and the conversion factor or one corner coordinate, the conversion factor and the two pixel dimensions

[fmw42]

If the tiles do not overlap, one might be better off just sorting them in row/column order. Then appending all the tiles in each row. Then appending all the rows.

If there are gaps, one could use montage to make each row using null: for the placeholders. Or create a blank tile and insert that where needed in the append process.

If there are lots of gaps, then one could mosiac the tiles into rows and then mosaic the rows into the final image.

[snibgo]

The OP has told us the coordinates have to be multiplied by 3.2. As far as I can see, the resolution is useless data that isn't required. But if the OP won't tell us, we'll never know.

It's all a bit vague.

[Lumo]

...Is your Y coordinate up or down. That is, is it an actual geographic coordinate or an image related coordinate. Also do you have negative coordinates?

My co-ordinates are Cartesian, with 0,0 at the bottom left. All the co-ordinates are positive but they start at several thousand units in both directions.

If the tiles do not overlap, one might be better off just sorting them in row/column order. Then appending all the tiles in each row. Then appending all the rows.

Yes, except that more than half the squares could be blank. Wouldn't that impact performance? I also don't have row by column references for the data tiles at the moment, although it should be possible to generate those references.

[fmw42]

My co-ordinates are Cartesian, with 0,0 at the bottom left. All the co-ordinates are positive but they start at several thousand units in both directions.

The offsets would be needed so that the mosiaced image does not contain a huge amount of empty space. The coordinates would need to be converted from your units to pixel coordinates and the y axis reversed.

Nevertheless, you file is still going to be huge. The best approach would seem to me to process it in tile rows. That would mean that the filenames would have to be separated into lists for each tile row. I do not think mosaic is going to help in this case to expand to fill. You would have to know or compute the width of each tile row as needed for the output including any space. Then a fixed size image can be created of Wx256 and the tiles can be added by -compose over -composite with -geometry to place them after the corners are converted to pixels relative to that row. This is my best guess at the moment.

I just don't think trying to mosaic all the tiles even one at a time is going to be practical unless you have a hugh amount of memory - multiply times the size of your resulting image.

[fmw42]

Addition thought. You might be able to loop over each tile and figure out what row to insert it, thus reading and writing to different row images.

On the other hand, if you can sort them into rows, you might be able to combine all the tiles in that row in one command. This would certainly be faster than reading and writing each tile one at a time to different tile rows.

In either case, -mosaic could be used to create the row image. But you would need to keep around the upper left corner position of the whole row, so that the rows could be mosaiced into the final image. Otherwise, you need to know the final row width and name the rows in order.

[snibgo]

I'm trying (and failing) to understand what problem is to be solved.

How big is the output image? I'll assume 8500x7000 pixels. At 8 bytes/pixel, this is 476 MB, doubled to have input/output is <1 GB, comfortably within memory of most recent computers.

We want to compose a load of tiles on the output. I'll assume 600 tiles, each 256x256, with no resizing or rotation, evenly spaced (but the spacing would make no difference to the time).

This is no big deal. It takes my laptop 18 seconds. True, every tile comes from a single file, and it would take longer if they were 600 different files. Adding resizing by 110% and rotation by 10 degrees increases the time by 3 seconds.

Is 21 seconds far too slow? How fast do you want it?

My Windows BAT test script is merely proof of concept. The real script would need different input filename, resize and rotation for each tile.

Code: Select all

set /A XX=0
set /A YY=0

set WW=8500
set HH=7000
set TW=256
set TH=256

set /A WWmTW=%WW%-%TW%
set /A HHmTH=%HH%-%TH%

set IM_SCR=im_make600.txt
del %IM_SCR% 2>nul

%IM%convert -size %TW%x%TH% gradient:khaki-brown tile.png

for /L %%i in (0,1,600) do (
  echo ^( tile.png -resize 105%% -rotate 10 ^) -geometry +!XX!+!YY! -composite >>%IM_SCR%
  set /A XX+=300
  if !XX! GTR %WWmTW% (
    set /A XX=0
    set /A YY+=300
  )
)

call StopWatch
%IM%convert -size %WW%x%HH% xc:None @%IM_SCR% m600.png
call StopWatch