PDA

View Full Version : Montage Query



icosahedron
08-12-2011, 03:23 PM
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
08-12-2011, 08:41 PM
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
08-13-2011, 05:16 AM
Not sure, but maybe Hugin will do it for you?

Redrobes
08-13-2011, 07:21 AM
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
08-13-2011, 10:56 AM
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
08-15-2011, 05:19 AM
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
08-15-2011, 09:38 AM
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
08-16-2011, 09:12 PM
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
08-16-2011, 09:39 PM
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
08-17-2011, 12:23 AM
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>

Redrobes
08-17-2011, 05:22 AM
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.

The images will be square but as you know when it prints out the icons in the app the size of them are independent of the image used. So they will be stretched back to the right aspect - in fact stretched such that the pixel size is real scale. Yes it will be 2/3 res in X. I don't think you will notice much difference. The app could do them full res but it would need each tile breaking into 4 and then assembling all the sub tiles as well. Its a bit tricky.

The numbering order is no problem - I just need to know what it is tho. So its like this:

2 4 6 8 10 12 14 16 18 20
3 5 7 9 11 13 15 17 19 21
22 24 26 28 30 32 34 36 38 40
23 25 27 29 31 33 35 37 39 41
42 44................................

You have said there are 90 tiles from "A2Z0002.vmi to A2Z0081.vmi" which is of course 80 of them. So is the last line of the grid would be...

................................ 59 61
62 64 66 68 70 72 74 76 78 80
63 65 67 69 71 73 75 77 79 81

And ill give you an app which will convert them from JPG so no worries about the conversion in Gimp.

If you can OK the numbering then I think I have enough to do it.

Redrobes
08-17-2011, 09:46 PM
Ok, written - ill send you the file. Let me know how it goes - post some screenies if it works out ok. If I were you, I would make a back up of the JPG files before you start all of this. A writable DVD would be enough or a flash pen drive or something.

You should see the batch file running executing commands until its finished. Just run up VDale, load Ogilby.txt and then WAIT for a while as it makes 90 large temp files. It could take a few mins and it will look like its crashed but it will get there. You only get this kind of thing when you have a large tiled array to make up. Once you have all the tiles in there and you can zoom about as usual, you can use the screen save option and it should work out ok. For a certain level of res it should cope but it does use a lot of RAM if going high res. There was a lot of care gone into that area to keep the RAM down but there is a limit for large files that cant be worked around. See how high you can take it.