PureBasic Forums - English

It would be nice to add functionality to the ImageDecoder/ImageEncoder() functions to add support to save as *.tiff's. You can read them with PB as it is now but can't write them. Also it would be nice to support higher resolutions too, instead of just 72dpi.

Also it would be nice to support higher resolutions too, instead of just 72dpi.

In what way does PB not support other DPIs?

Are you suggesting a mechanism to extract the dpi information in file formats like TIFF, without having to write one yourself?

Unless you have to print something, "dpi" are totally useless (or at least redundant...) and confusing.

When you load a 1024x768 (pixels) TIFF, you'll fill a 1024x768 bitmap. That's all.
The same file at 75dpi will be larger than the same file at 150dpi, but only when printed.
Show me a game at "150 dpi" (and the differences with a game at 72/75dpi) and I'll be happy
For some obscure reason, Mac people can't understand this, but it's another story..

In what way does PB not support other DPIs?

PureBasic only seems to handle image files at only 72dpi because i guess this is screen resolution. When i talk about dpi (dots per inch) i mean i would like PB to provide support for higher resolutions in order to support hi-resolution printing to devices such as laser imagesetters or thermal proofers.

Take this example, 2 files of equal filesize:

Image1 = 22k
Image2 = 22k

now both these images could contain the same image data but at different resolutions (dpi).

Image1 = 72 dpi (will print at 52.9mm square to a printer)
Image2 = 150 dpi (will print at 2.54mm square to a printer)

Both images will be have dimensions of 150 x 150 pixels.

Image2 will print with more detail and sharpness because it contains more pixles per inch (cm) then the lower resolution image (Image1). Get it?

I need this in order to write some software to manage and crop some 2400dpi tif files for a repro-graphic workflow, where these file resolutions are the norm. I have also tried using Python with the PIL libs installed but these too only seem to support 72dpi. I've no idea how to even start in C!

Even a BMP header has entries for desired mm's.

A 72 dpi for screen is nonsense.
Most are 96 and 120, iow not fixed.

DPI IS the resolution, so you want a higher (or lower) resolution..

Stretching an image (both ways) makes the DPI for the image change.

Commonly mixed up, DPI and pixels.

Once you have created an image pixel by pixel, then you can decide in what size you want to show it.

Once you have created an image pixel by pixel, then you can decide in what size you want to show it.

Yes, but this info is/should be included in the header and this is what my request is all about.

A 72 dpi for screen is nonsense.

ATM I work as a professional repro-graphic artist and 72dpi is considered screen res within this industry and is used for all low-res positional images. 72dpi is also used for every graphic used on the web! and after being a professional web dev in my later position thats all i used to use. So i think nonsense is a bit of a harsh word to use with no reason to back it up.

Commonly mixed up, DPI and pixels.

Yes it amazes me how many people don't understand this too. Please re-read though my last post.

>72dpi is considered screen res within this industry ...

I know, but that can mess up thinking of the same people having difficulty understanding DPI versus pixels.
Therefore i stressed it a little that screen DPI in Windows is (almost) never 72DPI and that 72 DPI is indeed a common value for graphic industry.
Even MSDN can show confusing theories about this.

And sorry, regarding your question, i don't have an answer

>72dpi is also used for every graphic used on the web!
Hmm, yes the world of dynamic sized pages.
Web is only indirectly involved in DPI.
It's not very common to show an image in cm's afaik.

Your 72 DPI image and info around it will show differently on different desktops.

Hmm... I can place different images of different resolutions in adobe illustrator and they display at different sizes as expected, which leads me to believe the size/resolution must be stored in a header. So my request is for native *.tiff handling and for access to the header to set such info when saving. C'mon Fred!

If you want to stop me from annoying you let me know

But i think now you are mistaken.
Different resolutions will be forced to play on the same screen resolution (96dpi for example)
UNLESS you are able, which i don't know of, to set a size.
Sizes and DPI do not depend.
The target device is molesting the pixel data to show a (garbaged) picture if a size was used.
If no size was used, the pixel data is used 1:1 on logical pixels (your screen)

So if an image is 300DPI and the same image copy was reduced to 100DPI, you may expact the sizes differ x3.
As said, unless in both images there is some entry to specify a size in mm's or so.

Afaik most BMP's lack support for recommened/fixed size:
biXPelsPerMeter
biYPelsPerMeter

Oops, my mistake now

IF tiff can handle different DPI to be saved to, this implies a size.
Sorry, then i'm wrong.

@Edwin: There is an Edit-Button in the righthand corner of each of your own posts. No need to falsify the statistics

size data must be stored within a tiff. I have written a program to crop tiffs but because i cant get around the 72dpi issue my small 2400dpi 5cm square tiffs image out at 1.6m across! 8O i need to find a way to save tiffs and set the header to support hires images.

I believe this different DPI resolucion is only to do with printers, although this information must be saved with the image, because image programs now what resolution each image has.