Hello, I’ma newbie to GIMP but I’m making my way around it.
I have a problem though that I can’t find the answer to.
I scale my image and set it to 300dpi (for printing on demand). Scale, and re-check. All correct. But for some reason, when I export my image, it exports at 11.8dpi.
(For clarity, it saves my new image sizes, just not the dpi change).
I can’t find out why it does this, or how to change it. Does anyone know who can explain it in layman’s terms for me please?
FYI, if I re-open the same image and scale to 300dpi again (the 2nd time), it does then seem to export at 300dpi. So I can work around it if I have to, but I have to do everything twice. Any help, much appreciated.
It is because it is not dpi it is pixels-per-millimetre
300 pixels-per-inch (dpi) = 11.81 pixels-per-milimetre
Makes no difference, it is just the way it is reported.
3 Likes
Ah! Thank you! That was probably a really stupid newbie question, but I had no idea what was happening. Much appreciated
This setting makes absolutely no difference to the export though, I don’t understand why it’s still there. A digital image has no materiality, it’s just a certain count of pixels.
4 Likes
This indeed doesn’t make sense for photos (but they usually have no DPI settings). But:
- If you scan something, you can then reprint at exactly the same size.
- When you send the image for print it tells at what size it should be printed
And if combine the two, that banknote you scanned is printed s exactly the right size 
1 Like
Well then just store the physical size directly. I don’t know anybody who goes measuring the original of the scan, convert to inches, divide pixel count by that (not always easy to find), and inputs the value there.
Also, when you go printing, you don’t need a constant DPI because that old 330 DPI rule assumes you are looking at the picture from the punctum proximum, roughly 25 cm for someone young with good eyesight. So, at 25 cm, your field of view fits at best a A4/Letter size print. Any print larger requires the spectator to move back, in which case the resolution doesn’t need to be 330 DPI anymore for each dot to have a smaller radius than the circle of confusion of human eyes.
Plus, when you send the image for print, you choose the size in the quote before sending the file, the printer doesn’t quote you after doing the maths on the EXIF DPI.
1 Like
Old layout software (quark express and such) used to respect DPI settings on first placement of the image. Today the setting is largely unused but faffing with dpi was a big deal in print production. Partly I’m guessing to optimize for the slow computers.
DPI, pixels, and print size are the three sides of the same coin(*). So using DPI or print size isn’t too different. The thing DPI has going for it is that if you crop the image, the DPI doesn’t change.
(*) yes, I know
1 Like
I’ll add that many image file formats, including JPG and PNG and TIFF, have a metadata field for resolution (per inch, per metre, per whatever), and not image size (inches, metres, whatever).
So it makes some sense to ask for resolution when saving a file.
A file has no resolution. This only serves to confuse beginners.
1 Like
A file has no resolution.
It also has no physical size, it’s all virtual pixels.
Yeah, yeah.
So it makes some sense to ask for the image resolution when saving the image to a file.
For the most part, it seems to be a holdover from legacy print workflows - where some printing houses might actually use that metadata.
Nowadays, for the most part, that metadata doesn’t matter, since as someone pointed out, most print services will just ask you the physical output size to use and ignore the metadata field.
The only other case I can see where it makes sense is, as someone pointed out, when the source is a scanner - then the metadata field can tell you what the original size of the object was.
For cameras - DPI is useless. You need the camera’s intrinsics (focal length, sensor size, lens projection, sensor resolution in pixels) to make a reasonable mapping from the physical realm to the image. Fortunately, most cameras do record most of that, and for the things they don’t record, lensfun can usually handle the rest if the lens is in the database.
“just store the physical size” is, not surprisingly, part of the EDID standard though. DPI is calculated from physical size and resolution in pixels.
1 Like
This would assume that everything it at the same distance in the camera’s filed of view…
I never said anything about distance.
Neither does lensfun’s documentation on projections.
Also, you can reliably map a particular point in real-world space to a given pixel within an image, but you are correct, you can’t invert the mapping.
Invertability is (obviously) not going to be available without stereo or another data source. The metadata I did mention (needed to determine angle accurately) is needed for stereo or some other multi-sensor registration (such as determining the color of LiDAR points from an RGB image) to work properly. As I said, fortunately most cameras provide MOST of the metadata you need on their own. (except for distortion metadata in a documented and standard form…)
I would wish more software would respect it. Inkscape imports always at 96 dpi, which imports photos of today’s cameras at tremendous sizes. It would be much more convenient to set size (resp. dpi) in darktable or gimp and have a reasonable default size in inkscape.
I remember the old whinge about CorelDraw <> Inscape dpi and in Inkscape Extensions → Document there is still 90 to 96 / 96 to 90 dpi filters.
I do not use Inkscape much these days but looking at the latest 1.2 (released a week or so ago) there is a setting in Edit → Preferences.
2 Likes
Quark is still going and InDesign, illustrator, Scribus etc (also respects ppi (pixel per inch, dots per inch when it´s been printed)