I have many parts of an image, each named as the co-ordinates of bottom left and top right corners of the image.

The file names currently take this format: "0,0,80,80.png" The numbers are in an arbitrary unit. Each tile is square and 80 units wide, measuring 256 x 256 pixels. I believe multiplying all values in the file name by 3.2 would give a 1:1 pixel mapping (256/80=3.2), so that's something I can do.

I found a GIMP script that can move a layer to a specified position: http://registry.gimp.org/node/27806

Does anyone know how to automate the task of putting each piece in the right place?

Thanks

Yes, it takes a script... now is the question about you writing the script or about having it written by someone else?

Another question is whether your coordinate system is top down (as used in most graphical UIs or in Gimp images (so 0,0 is the top left corner) or is down up (mathematical usage, where 0,0 would be the bottom left corner).

Otherwise your script would look like:

Wow, that looks great. Thanks a lot.

The co-ordinate system is that maths kind, with the 0,0 at the bottom left. I guess I'll change (x0,y1) to (x0,y0)? :-)

At the moment I get an error that says:
Any ideas?

Thanks again

Since it"s python it should go in "plug-ins", not in "scripts" and, under OSX and Linux, you should set its "executable" flag.

But in any case the code above wasn't meant to be run as is, it won't run with your images.

It would help a lot if you could zip and attach here a small example of your stuff so that I can finish it otherwise it's going to be a very protracted debugging session.

In your inbox Thanks!

I've worked on some logic which I think will work for this script. This should work for tiles of any size and arrangement, as long as they are all the same resolution. The script is kept simple by building most of the image off-canvas and expanding the canvas to fit layers at the end.

0. The file name format is X₁,Y₁,X₂,Y₂,X_p,Y_p.png where each part of the file name is a variable. All of these variables are declared as integers, as well as the variables X_f, Y_f, X_o, Y_o. The variables "ImportFolder" and "SaveFile" are declared as a strings.

1. The script pops up a dialogue box that prompts the user for "folder to import" and "save location". It saves these strings in their corresponding variables for calling later.
2. The script opens the first file in the folder that was selected. There could be many thousand files, so I don't know if it's best to enumerate them first or not.
3. The script uses X₁ from the first image to create the variable X_o.
4. The script uses Y₁ from the first image to create the variable Y_o.
5. The script uses the formula X_p/(X₂-X₁) to create variable X_f. This is our X scale factor.
6. The script uses the formula Y_p/(Y₂-Y₁) to create variable Y_f. This is our Y scale factor.
7. The script duplicates the layer containing the first image. It sets the duplicated layer to be not visible, and re-names it with the name of the imported file.

8. The script imports the next file in the folder as a new layer above the previous layer.
9. The script offsets the new layer in X by (X₁-X_o)*X_f.
10. The script offsets the new layer in Y by (Y₁-Y_o)*Y_f*-1 (compensating for GIMP's inverted Y axis).
11. The script merges visible layers with "merge down". This will merge all layers except the duplicate from earlier, because it is not visible.
12. The script repeats from step 8 until all files are imported.

13. The script expands the canvas to fit all layers.
14. The script saves the file as .xcf in the location that the user selected earlier.

See attached zip. Menu is File>Create>From tiles, the only thing it requires is the directory containing the tiles.

Possibly a memory hog since it creates images that are over 100Mpx with your (very incomplete) test data. A version where layers are merged down one by one (instead of flattening them all together at the end) could use less RAM but is much slower.

Thanks Ofnuts, this is really good! I appreciate the help.

It does seem there are big gaps in the data. I'll have to find out why.

I couldn't quite decide if this should be a new post, because the topic is different, but I think this question belongs here for continuity

I'm using this script quite a lot - because it's amazing . I'm using it so much, in such a systematic way, that it'd be great if my input could be automated. All I do is point it at folders, but I've got more than 200 folders left to do and each takes a couple of hours to process.

I've got all my folders of tiles in a parent folder. Is it possible to point GIMP to this folder and have the script run on each child folder separately? The swap file would need to be purged between jobs. At the moment I have to restart GIMP between jobs to clear it out.

Ideally the transparent areas would be converted to a preset colour such as white, and the file would be converted to Indexed Colour with a preset scheme before it is saved. I found a function for this but I can't get it to be recognised.

I replaced the display instruction in the original script with a save function as below:

Would anyone like to help me? Thanks

Can you post a directory listing show all of the filenames in a tile set?

Partial listing, since there are typically over 1600 files.



See my script above for the gory details (your eyes will bleed reading this Python

But IMHO, if things get industrial like this, the OP should switch to ImageMagick.

Thanks for the info (though I'd prefer to have one of lumo's full, actual tile directories).

I have produced the following tarball of some example files for a 40x40 grid of 80x80 images (1600 files total). Does this look right? And would it be correct that the first file is not necessarily set at x=y=0 ?

ftp://silo.kerosenecow.net/bbox-files.tar.gz


My experience is that if one can avoid the actual loading of GIMP (when processing multiple files), it is typically about 2-4 times faster than ImageMagick for the the same operations. Lumo said GIMP spent hours processing a directory -- it should not take this long. I have played a little bit with the above set it only takes around 10 minutes (on my puny 2GHz machine with just 2GB of RAM). Either I am missing something or there is room for significant optimization of lumo's processing.

The tiles are 256x256 but the coordinates are by steps of 80 units, so you have to scale them. The set I got from lumo was very incomplete (529 tiles for a 42x41 array, given their coordinates). The set you provided loads in 1'15" with my script (32" for Lumo's incomplete set), on my 2.6GHz Core i5. But your set made of mostly transparent tiles and Lumo's incomplete test set won't use as much RAM as a full one, and Lumo could be swapping (Gimp or system).

And yes, the first tile isn't at 0,0...

Ofnuts has already answered most of the questions for me

Your sample set looks correct. Good job

The sets can have different tile sizes. Most recently I joined a set that consisted of tiles at 5000x5000, each covering 500 units in X and Y. Ofnuts' script has a nice calculation at the start "256/80" which I change to match the source tiles. So this one was "5000/500".

I've found GIMP to be very capable at stitching these tiles. It's a shame that it can't use multiple swap files on different drives because then I could do larger sets. I'm limited to the free space on my SSD currently, plus a few gig of RAM (because 64 bit GIMP always crashes).

The tiles come from OS OpenData but I batch re-name them to a different scheme (based on co-ordinates) so that I can easily build a map of any given area from the available images. The scheme is something that was used by a tool I was using previously and I've stuck with it because I've built other tools around it now. I'm happy to omit the text portions and simplify the file name to 6 numbers, separated by commas. I always re-name the finished file to the six numbers scheme: Xmin,Ymin,Xmax,Ymax,Width,Height. This is so that it can be imported into another software package.

I've put a complete set on MailBigFile, here: http://mbf.me/ibyKS7
This is under the OS OpenData Licence so I'm obligated to write: Contains Ordnance Survey data © Crown copyright and database right 2014.

Easy enough to either:

• obtain from additional parameters to the script
• compute from the available data, since the tile size is in the name, and the other dimension can be guessed from the stepping

Yeah but I don't know how to do that, so I change the text ;-)

Another way is to give the complete specifications to the developer from the start...

About your new set, this leads to a 2.5 gigapixel image. Except burning CPUs and testing your disks I don't see much purpose in generating that... I don't know of any utility that will display such an image as a whole.

#7 != #1