Montage Query

[icosahedron]

I'm trying to create a large map by fitting together 90 A4 map-sections. I'm hoping to be able to save as a jpg and view the whole map in XnView and/or perhaps ViewingDale with significant zoom and pan facilities.

The 90 jpgs have a total size of around 250MB, so I imagine the finished map will be a similar size, covering an area of some 30k x 20k pixels.

However, software such as MSPaint, MTPaint, and GIMP want to do the assembling as a bitmap, with a filesize of over 5GB!

Firstly, I think GIMP is the only application I have that will handle files that big, (I'm not sure it can handle it) and secondly, I can't configure GIMP to build a map that size because my HDD isn't that big.

I literally don't have the space to create a 5GB image even if the software can handle it.

A 250MB image might be doable - if I could find a way to assemble it in jpg format rather than assembling as a bitmap then saving as a jpg.

Can anyone think of a way around this, short of buying a bigger HDD for a one-off job?

Thanks in advance.

[Midgardsormr]

You should be able to just put it together in Viewingdale without having to actually sew it together. That's what the program was made for, after all. I'm sure RR will be along shortly to give some input on that topic.

[ravells]

Not sure, but maybe Hugin will do it for you?

[Redrobes]

Need a little more info about the 90 A4 map sections. Are these physical and real and then scanned images that you need to fit up ? Or is it a pre-existing collection of JPG's or PNG's etc that you need to make into a view. I'm guessing the latter since you know the file size of the collection.

Are they all exactly the same size images and what pixel size is each. ViewingDale has a maximum image resolution of 2048x2048 pixels but there is an app called the ImageSplitter which is shipped with it that will take larger images and turn them into a patchwork of smaller tiled images and it creates all the icons necessary so that when you view it, its all in one space joined back up.

There is another app shipped with it which is the batch image to VMI image format converter which will take a directory of images and create ViewingDale formatted versions of them in one go. So all 90 can be converted together. It does not however create all the icons for them tho.

As you know I do MeDem and we have a tiled array of 40x40 images to make 1600 tiles and each are 1024x1024 tiles making up our 40K square map. We have three layers of that so in total it has 4800 tiles for a 40,000 pixel square map so the app can cope with it so long as your graphics card can handle the large amount of data going through it.

The missing bit you need is to get icon files for all the VMI images that you need to make up the map. We do this with Perl since the icons are only small text files containing the position, scale, image to use and some sundries like flips and rotations. Since I have some code lying about to our maps I think it should be easy for me to modify one of them to create your tile set.

So what you need to do is the following:

a) Get all of your images together into one directory.
b) Run the batch image converter and get them all into VMI format somewhere within the ViewingDale images directory.
c) Tell me the original aspect ratio of the images before conversion. I.e. if A4 then width is 1.414 x height in portrait mode. So give me the original width and heights of the images. If you want it to exact scale then I need to know that too. What physical distance is one pixel on the image.
d) Tell me where in the ViewingDale/Images directory you put the VMI images and what prefix you used. I.e. C:\ViewingDale\Images\Montage\Img_X2_Y3.vmi
e) Tell me where you would like your Icons. I.e. C:\ViewingDale\Icons\Montage

and then ill write a script to put them all together.

To be honest it is quite a demanding task that your asking for. You may find that in several areas of the processing or viewing you will run up quite a lot of RAM or HDD space. ViewingDales VMI format is compressed but like PNG's it is lossless and so offers a factor of maybe 4:1 drop in size unlike JPG where it could be 10:1 or 20:1. I.e. if your originals were in JPG format as opposed to BMP then you could find the VMI's being quite a lot larger than the originals. If they were in BMP then they would become smaller. The compression ratio depends a lot on what the picture on the images looked like. If line drawing then it could be very small but if hand drawn or satellite photo then much less so.

If you have the capability of uploading the originals to some web site or FTP then I could grab them and do the processing for you and give you back the VMI's and icons.

I dont think anybody can view one image as 20Kx30K. Even with my 64bit machine and with a 64bit image viewer it tops out at about 20K. To be honest, any app viewing images over about 10K is pushing it. I know photoshop have large image formats but like ViewingDale these are working with tiled sections and paging in smaller areas of the image at a time. Also, no app can deal with JPG images as compressed files whilst editing them. They all would uncompress them into RAM before dealing with them. The data in compressed form bears no resemblance to pixels and cannot be worked upon. You would not be able to assemble JPGs and do it within a RAM limit of the sum of the JPG file sizes. You would have to multiply the X x Y x number x 4 bytes which would be something like 5Gb.

[icosahedron]

Hi Redrobes,
Thanks for the offer. I wouldn't want to put you to any trouble, I was just fishing for info - which you've supplied plenty of.

I can make icons by hand if that's what I have to do.

However, here's the info - I'll let you decide how big a job the scripting is. If it's a bear, just let me know and I'll do the job manually - I'm used to substituting patience for tech.


The map sections are scanned from A4/foolscap real historical maps. The resulting jpgs are a little over 2MB each, with a total file size of 210MB. I need a single large jpg (or similar) that I can view electronically.

The maps as scanned were all exactly the same size at 2550x3905 px each, but I've had to crop them down by hand to remove borders, etc, so they're no longer all the same size. The files for assembly average around 2150x3000 px, which is still a ratio of about 1: 1.376. I realise that the different sizes means there will be gaps or overlaps at high mag, but I can live with that - it's for personal game use, and even then, largely GM reference - I'm not planning to sell it.

The scale is 3 pixels = 1ft.

Of course, the 'edge' sections are bigger, as they include labels, title blocks, etc.

When I get Viewingdale reloaded following my HDD crash...

...I'll put them in C:\Program Files\ViewingDale\Images\Ogilby

and the files will be A2Z0002.vmi to A2Z0081.vmi.

The icons will be in c:\Program Files\Viewingdale\Icons\Ogilby.

That is, if my RAM and HDD space is up to it. This is the first project that's ever hit the buffers! If vmis are bigger than jpgs, I could be looking at the best part of a gig for the one map.

It's useful to know that no app can assemble jpgs - even knowing what I can't do, and why, is an increase of knowledge. Thanks for the info.

[Redrobes]

Oh I missed your reply - board notifications seem to be running icky recently...

Ok, so you have the scans done and cropped the edges. Of course VDale cant auto crop or stitch so its important that you have edges that would butt together ok or well enough for your needs.

I would suggest that we use the max size for each scan as 2048x2048 which is 2/3 the original in X but its easier than breaking each scan up into smaller tiles and trying to do that. So you can use the BatchImage converter shipped with it to do that job. Hmm actually just looking it does it on PNG files - ViewingDalePNGtoVMI.exe. I have a command line version which is not a batch one which does work on JPGs so ill send you that one and write the script to use it as well. In which case you put the script and this app in the same dir as the JPGs and it will make another set of VMI files in your correct VMI folder.

A2Z0002.vmi to A2Z0081.vmi - yup got it. But what is the X numbering and Y numbering. I.e. how many per row ? I.e. say its 0002 to 0012 going right and then down from the top left corner then 0013 to 0023 on the next row etc ?

I have all the other info I think. In the mean time you would need to reinstall the app and get the C:\ VDale \ Icons & Images dirs set up so that they have someplace to go.

Are you still on your 152 hotmail address, if not then PM me your email.

[RobA]

Not sure, but maybe Hugin will do it for you?

Hugin can definitely do it if there is enough overlap between the scans to stitch it together. I've put together panoramas with 30+ photos each 12Mpix without the software breaking a sweat.

I've posted to a tutorial for an older version of Hugin before: http://hugin.sourceforge.net/tutorials/scans/en.shtml

-Rob A>

[icosahedron]

No worries, Redrobes, I haven't had time to read this board since the weekend anyway.

Isn't 2048 x 2048 going to distort the map sections, making them square? I know it won't, cos you'll have that all figured out, but I'm just curious about how it works.

I could convert the images from jpg to png using Gimp if that helps...

Agh! you've brought up a potential problem there with the XY numbering. Right now they run alternate numbers, so 2,4,6...20 form the ten top row images and 3,5,7...21 form the next row, etc. That probably means I'd have to re-number the files before importing them, yes?

Yes, still on the old address.

[icosahedron]

Hugin can definitely do it if there is enough overlap between the scans to stitch it together. I've put together panoramas with 30+ photos each 12Mpix without the software breaking a sweat.

I've posted to a tutorial for an older version of Hugin before: http://hugin.sourceforge.net/tutorials/scans/en.shtml

-Rob A>

Hugin is a new one on me, and I'm not sure what you mean by 'overlap'. I've cropped the images to butt together, but I've saved the originals so I could re-crop if necessary.

However, I suspect Gimp could put them together - the problem I raised in my OP was that my dinosaur of a computer probably couldn't handle the file size even if the software could. I'm still unsure whether Viewingdale will freeze partway through.

Maybe as Redrobes suggested, the task is simply too demanding. Maybe the way to go is just to halve the scale - perhaps I wouldn't lose too much detail, and I could probably stitch it together in generic paint software then, that I could view on any machine rather than only my VD machine.
...And Redrobes is suggesting a reduction to 2/3 scale even for Viewingdale...

Thinking as I type... Yes, I'll give a half-scale assembly a try first and see if it provides sufficient detail before I put anyone to further trouble. I'll let you know how I go on.

Thanks for helping me get my brain around this...

[RobA]

Hugin is a new one on me, and I'm not sure what you mean by 'overlap'. I've cropped the images to butt together...

Hugin requires overlap - that is how it stitches images together, using a variety of automatic (or manual) point identification in the images to then adjust (optionally any one or all of) translation, rotation, pitch, yaw and barrel correction. For scanned images you would only need to adjust translation and rotation...

No overlap, no stitchy

-Rob A>