[Solved] Cant export my giant image from draw

[cheeselord22]

I have been using draw as a substitute for Photoshop. It works for what I needed to do, however the image I need to create is very large. It must be 29 by 19 inches. and a reasonably high resolution. the web sight I need to update it to needs the format to be : jpg, bmp, png, gif or tiff. however exporting to these formats makes the image blurry. Iv learnt that I can simply increase the size of the image to negate this but when I make the image any bigger (because its already so big) it simply glitches and exports a 1 by 1 white 1 byte image. iv tried exporting to other file types and converting (such as pdf) but all of the converters I have tried make me pay because rather the file is to big or will only allow up to 300 dpi. Is there a trick to exporting giant images like this ? I do not care how big the file is as long as its under 300MB.(max size web sight will allow) thanks very much. Iv been at it for hrs.

[John_Ha]

I have been using draw as a substitute for Photoshop.

That is not a good idea - it is best to use Photoshop or an image viewer/editor like IrfanView for image editing.

1 File > Export. If it is a photo, choose JPG. If it is a graphic, choose PNG.

2 Save (noting the folder where it will be saved - I think "C:\Users\xxxxxx\AppData\Roaming\OpenOffice\4\user\gallery" is the default)

3 You get this pop-up window. Choose the appropriate pixel count. For reasonable quality prining, use 150 dpi, for high quality printing use 300 dpi, for excellent quality printing, use 600 dpi. The more dpi, the bigger the file.

Clipboard02.png (10.54 KiB) Viewed 2567 times

4 If your draw page contains an image and draw objects like rectangles, lines and text you will find that the draw objects never get blurred because they are vector graphic items. However, if your image is, say, only 300 x 200 pixels, you cannot make it any better - it will be burred if you magnify it. If it does blur, you need to insert a higher quality image.

See [Tutorial] Some useful hints on using images for a discussion on how best to handle images.

If this solves the problem, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[cheeselord22]

Thank you very much for the reply. Unfortunately that dose not help. If I turn up the pixels per centimeter the program automatically adjusts the size of the save image to be smaller. Like I said if I then make the image bigger to account for that the file wont export properly. it seems the file itself is just to big to export. I was simply wondering if there is a work around. if that workaround is suck it up and learn photo shop then I guess so be it . (i just find this program way faster to do what I am doing) just to give you an idea the open office file is about 124MB. is there a chance my computer just cant handle it?

[John_Ha]

It is too complex to explain. I have sent you my ID - check your messages. Send me the .odg file and I will look at it.

What web site is asking for it?

Note that the important thing is the pixel count - the physical paper size can be whatever you want and can be set manually once you have got the pixels.

[John_Ha]

Your 124 MB AOO file looks way to big - you are doing something wrong. Upload it to a file share site.

[cheeselord22]

Ok i sent the enlarged file to your email via drop box.

[John_Ha]

I downloaded the 128 MByte .odg file. When I unzip it, it has a .svm file in the \Pictures folder which is 141 MBytes, which is enormous. .svm is an OpenOffice graphics format.

What is svm file? How to open svm files?

The svm file extension is related to OpenOffice.org. A StarView metafile is a file format used internally by OpenOffice.org to store graphics.

Similar to the Windows metafile format, a Starview metafile stores vector and bitmap graphics for use within OpenOffice.org modules. This makes it easier for each module to manage graphics between them.

For example, when you insert or copy images from among the different programs, particularly the drawing and presentation applications, the images are saved in the "SVM" format so that it [they] can be easily manipulated within their respective documents.

The Draw document is as shown in this image:

It is difficult to choose between JPG and PNG for saving the file because, while the image is a graphic image, it is more like a photo than a graphic. I think this is why the .svm file is so huge.

When in Draw I go File > Export ..., and I choose JPG, 100 pixels/cm, QF = 85% ..., Draw exports the file as a 2,784 x 1,824 pixels image where the file is 964 kBytes, 146x smaller than the .svm file.

When I export it as a PNG file with 100 pixels/cm ..., Draw exports it as 2,784 x 1,824 pixels image where the file is 6,115 kBytes. I was expecting the PNG file to be significantly larger than the JPG file because the image is very "photo-like".

I have sent a link to both files to cheeselord22.

I said

Your 124 MB AOO file looks way to big - you are doing something wrong.

I think that what you are doing "wrong" is using Draw, which is effectively a vector based system, to create a pixel based image. I am sure you would be much better to use a proper graphics editor to create your image - the file will then be many, many times smaller. That being said, Draw copes with the conversion to pixel based image without any problem so who am I to tell you that you are doing it "wrong"! If you want more pixels in your final image, just increase the 100 pixels/cm to whatever number you need.

If this solves the problem, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[cheeselord22]

Thank so for all the help. Apparently this is more complicated then I thought. Haha

[John_Ha]

I would be very interested if you could throw any light on why the .svm file is so big.

I analysed your .odg file in an attempt to understand why it is so big but I have not been very successful as I cannot say "The file is big because ..."

Edit: See later post ...

In the main you have inserted graphic items (cobra, heart, bat, dice etc) which have quite small pixel counts, which is good. The "brown" background is reasonable. The green oval could be resampled to a smaller pixel count.

You could reduce the size of the .odg file by doing the following:

1 Most images could be 256 colour (8 bit) instead of 16.7 million (24 bit) - this reduces the size by 3x. Some could be 16 colour and some could be mono (1 bit) (the letter outlines)

2 The green oval is over 2,000 pixels wide - it looks no different when resampled to 500 pixels which is 16x smaller. Make it 16 colours and it is 8x smaller again.

3 All your images are "laid on top of each other" so one "picture" pixel has several "component" pixels where only the top pixel is seen. If you were to create your hexagons and export them to a PNG image and bring back the PNG image you would reduce this waste.

[John_Ha]

If you want more pixels in your final image, just increase the 100 pixels/cm to whatever number you need.

I said that before I analysed the image as I had been expecting the image to be vector based whereas it is almost entirely pixel based.

The final quality of the image will be determined by the pixel count of the component items. Your bat image is 113 pixels wide. If, when you export, you set your pixel count such that the bat ends up being 200 pixels wide in the created image, it will be blurred because Draw has had to create 200 pixels from 113 pixels, and it has to interpolate.

[John_Ha]

I would be very interested if you could throw any light on why the .svm file is so big.

I analysed your .odg file in an attempt to understand why it is so big but I have not been very successful as I cannot say "The file is big because ..."

In the main you have inserted graphic items (cobra, heart, bat, dice etc) which have quite small pixel counts, which is good. The "brown" background is reasonable. The green oval could be resampled to a smaller pixel count.

You could reduce the size of the .odg file by doing the following:

1 Most images could be 256 colour (8 bit) instead of 16.7 million (24 bit) - this reduces the size by 3x. Some could be 16 colour and some could be mono (1 bit) (the letter outlines)

2 The green oval is over 2,000 pixels wide - it looks no different when resampled to 500 pixels which is 16x smaller. Make it 16 colours and it is 8x smaller again.

3 All your images are "laid on top of each other" so one "picture" pixel has several "component" pixels where only the top pixel is seen. If you were to create your hexagons and export them to a PNG image and bring back the PNG image you would reduce this waste.

Ah! got it! Your component images are far, far too big. The bat image is actually 763 pixels wide which is far, far larger than it needs to be. Similarly, the cobra is 860 pixels wide.

What you need to do is to work out how wide the cobra, say, will be in the final submitted image. If it is going to 1/4" wide, and you need to submit at 150 dpi, the cobra needs to be 150/4 = 38 pixels wide. Your cobra is 860 pixels wide, which is 500x more Bytes than is necessary (860/38 x 860/38). If this is the same for all images, as I think it is, then the .svm file would be about 500x smaller, or only about 300 kBytes, using properly sized component images.

cobra and bat in top green hexagon on right

Clipboard01.jpg (16.31 KiB) Viewed 2464 times

Edit: A far simpler method ... Perhaps the best and simplest way to reduce the size of the SVG image file is to get rid of it and replace it with a JPG, PNG or GIF file. Export the entire Draw drawing as an image by the File > Export ..., dialogue. You can set the pixel count for the exported image and you could check whether JPG, PNG or GIF (only 256 colours) was smallest. This will automatically take care of the "large" cobra / bat files because they will be resampled to much smaller pixel counts. Also, your SVG file has images overlaying other images which is redundant. An exported image is just a single layer - if anything is covered it is not included in the image file. You now have a much smaller image file.