One of the big motivations for my (latest) return to GIMP is my recent interest in Unreal Engine 4. I've started learning how to make landscapes, textures, materials, etc. with the eventual goal of brining a game idea to life. GIMP is going to be an important part of all this as it is such a great tool for creating the necessary assets.

Right now, I'm focusing on creating the basic landscape. I've been learning how to import heightmaps into UE4 and sculpt the resulting landscapes. There is an upper limit to the size of the landscapes you can import/create, but there seems to be no limit to how many you can use in a single project. So I've started working on adding multiple landscapes and figuring out how to align them. There are complications I've yet to sort out, but that's not relevant here.

I want to know if there's a maximum canvas size in GIMP. The plan is to have one massive map of the overall landscape. Then I can use layers to represent smaller, more manageable sections. Each layer could be the size required to export into UE4. That way I could work on each section independently and not have to worry about running filters on the whole map at once. But having the overall map available would help me maintain the correct flow between sections. Does that make sense? I feel I'm just rambling. Basically, I want to cut one huge image into smaller blocks so I can paint those blocks more easily. The big "map" would probably contain nothing more than a sort of topographical map created with the path tool, so even if it was huge it wouldn't be unwieldy.

I'm also open to suggestions for other ways to keep multiple images aligned so that they can be placed together to form a cohesive larger image.

Do you need to split the large image into smaller ones? I saw this recently [ https://www.gimp-forum.net/Thread-ofn-tiles ], it may be of help, i don't know the max canvas size in GIMP, pretty big I think...

I do not know the pixel size limit for images but there is a file size limit for .xcf files of 4 GB

You might say, very large, but you can get close with a large canvas and lots of layers. Also easy to lose work when saving large files.

File size fixed with the development release Gimp 2.9.6

In here somewhere: http://www.gimpusers.com/forums/gimp-us ... 6-released

- Remove max size limitation of 4GB for XCF files.

Splitting the image will just make it easier to manage and quicker to run. I can import maps as big as 8,133x8,133 into UE4. If I want to make something truly huge I could have several blocks that size tacked together. So it's not unimaginable that the full map could be 20-30,000 pixels square, or more. I can't imagine running a filter on something that size, it would take hours to run. There's also the problem that heightmaps are limited by the 0-255 range of a white/black gradient. I'm planning to layer topographical segments like you'd layer a cake to get the elevation I want in the final product. That still requires some form of segmentation. Somehow, it doesn't surprise me that Ofnuts has a script that looks like it might be just what I need. Thanks for the link.

4GB does sound huge. The main map would just be the topographical information. A blank canvas with paths outlining the terrain at different elevations, lines created from stroking those paths, and more lines to mark off a grid to show the various sections. All on one layer, I should imagine. Or, maybe, one layer for a plain white background and then each path stroke on its own layer with a transparent background. Do it all in grayscale so it doesn't take up much space?

Guess it's time to open GIMP and see what kind of trouble I can get myself into.

Just a quick update for anybody interested.

I created a grayscale 2,017 x 2,017 image with four layers and it took up just under 8MB as an uncompressed PNG. Assuming the 4GB limit is still in effect that makes this file 1/500th the size of the limit. That means you should be able to easily make a 22 x 22 grid of images this size, so some 45,000 pixels per side? My image also had an alpha channel which probably adds to the size of the file.

GIMP will actually let you create a 45,000 x 45,000 canvas . However, it seems the information does not scale at the same rate as the image. A single layer that size occupies almost 8GB by itself. I've managed to lock GIMP up by simply trying to bucket fill that layer. That could be a hardware limitation. I have an ancient CPU and "only" 8GB of RAM.

*EDIT*
Hah! The bucket fill is working now, finally. It is literally filling at the same rate as you'd see a screen fill with text if you held down a key on your keyboard. Hilarious. There may not be a programmatical upper limit to canvas size in GIMP but there is definitely a functional limit.

PNG is a lossless format, default compression is the maximum '9', not much benefit, except quick save/load time with zero compression.

2017 x 2017 pix is not large these days you should have no problems. Exporting as a PNG will lose any layers.

An example albeit in colour,
Export as a '9' compressed png 4.5 MB
Export a zero compressed png 16 MB - but only the 'merged' image for png format

Save as a Gimp xcf, which keeps the 4 layers file size = 46MB



When it comes to editing remember the image is held in memory - the size shown in the status bar - in this case 88 MB

8 GB memory is plenty, Gimp only uses 1 cpu anyway, processing time depends on cpu speed.

Good CPUs are around 30,000 MIPS (so that's 30 giga-instructions/second). However this is per processor and since good CPUs are usually multi-core, the real CPU is closer to 4000 MIPS (and Gimp will only use one in most cases).

The 45000x45000 image is 2 Gigapixels. So one operation that only requires one instruction per pixel takes half a second. And most operations take a lot more instructions than this.

I have lots of experimenting to do. It doesn't look like I'll be able to cut a large image into chunks, so I'll have to figure out how to draw the chunks so they tile into the image I want.

Also, if you are working with height-fields, specify the image type as greyscale, no alpha up front as it will only use one byte per pixel then rather than four.

-Rob A>

Yeah, Unreal specifies grayscale. They also want 16-bit. So I'm a bit short until we finally get 16-bit in the stable version.

Yeah - you are SOL without 16 bit for heightfields anyway (usually).

-Rob A>