"I want to change DPI with Imagemagick without changing the actual byte-size of the image data."
This is completely impossible!
more "Dots per Inch"
<==> more pixels per area
<==> more total pixels per image
<==> more total bytes per image
Also you don't seem to understand what DPI in reality is:
- It's a completely abstract value that gets practical value only in the context of knowing also the absolute size of the printout or rendering on screen or monitor:
- You can 'print' the very same 72x72 pixels image on a 1 inch wide square: the printout will have a resolution of
- You can 'print' it on a 1/4 inch wide square too: then the printout will have a resolution of
- (Note: If you 'print' it at
288dpi on a 1 inch square, it's no longer the same image: it will have undergone some extrapolation through the printer driver or some other filtering mechanism, and it will have become a 288x288 pixels image instead of a 72x72 pixels image...)
- Both printouts will have the very same image information -- the 288dpi image will not suddenly have more.
If you want to print the original 72x72 pixels image as a 1 inch wide square, but at
288dpi, then you'll have to rescale the image (in this case scaling it up). For every 1 pixel in the original you'll need 4 pixels of the new, upscaled image. Now there are different algorithms which can be used to compute what color values these 4 pixels (3 of them new pixels) should have:
- you could give them the same as the original pixel (which is a very "raw" algorithm,
- or you could do some averaging of the original pixel's color value with the color values of the neighboring pixels.
In any case you are creating a bigger image consisting of 288 rows of pixels which are each 288 pixels high (288x288 pixels).
What Gimp does for you when you go through "Picture -> Printing Size": it simplifies the process of re-calculating the required changes in absolute pixel sizes, making it more user-friendly. For this purpose...
- ...it first asks you about the DPI because a given printer can not change its printing resolution arbitrarily (some can offer not just one, but maybe even 2 or 3 different resolutions). So it asks you at which resolution you want to print. That is the first info.
- ...then it also asks for the second piece of info: at which size (in
inch) the printout should appear on paper.
According to these two pieces of info Gimp then calculates the total number of pixels it has to use (extrapolate from the original number of pixels) to fill the requested space at the requested resolution.
However, scaling up a raster image by making it contain more pixels does not add real info to it, and it does only add 'quality' to it which is fictitious. It may look nicer to the human eye if your scale up algorithm is a 'good' one. And it will look ugly, if you just double, treble or quadruple existing pixels, like some simple algorithms do.
For raster images,
the DPI setting is only relevant in the context of printing or displaying it. Because printers or monitors have given, fixed resolutions. Therefor it is info that only...
- ...a printer driver or
- ...an image processing application that supports printing
need to know.
And ImageMagick's documentation is in full agreement with me:
Set the horizontal and vertical resolution of an image for rendering to devices.
For vector images or file formats
(such as PDF or PostScript) the DPI setting however is extremely important in the context of rasterizing them. A higher DPI will transfer more picture information into the raster format and hence preserve more details from the real original quality. When converting a vector image of a given size in
inch into raster with a higher DPI will directly translate into a higher number of total pixels in the image.
Also, ImageMagick does not support 'printing' as such. Instead, ImageMagick only...
- ...converts files from a given raster format to other raster formats;
- ...or it scales down or scales up raster images;
- ...or it changes color values according to a specific algorithm;
- ...or it crops images, overlays them, inverts them, mirrors them;
- ...and what-not....
...but to print the manipulated images, you need to use a different program.
Some image formats (TIFF, PNG,...) do support storing a DPI setting internally in their meta data.
But this is no more than a 'hint' attribute that does not alter the underlying raster image. That's the reason why you made this discovery:
"When I check the file it stays the same."
This 'hint' can possibly be automatically evaluated by printer drivers or by page creation programs such as LaTeX. In the absence of such DPI 'hints' (or if they somehow don't present themselves in the way LaTeX expects them to do), LaTeX should still be able to be commanded to render any given image on a page the way one expects it to -- it needs just some more explicit LaTeX code around the image!
Some other image formats (JPEG(?), BMP,...) do not even support storing a DPI hint at their internal meta data.
So Gimp only does support what you see it's doing with "Picture -> Printing Size" because it wants to print an image. With ImageMagick you cannot print.
Keep doing what you want to do with Gimp when you print. It doesn't make sense with ImageMagick.
See also this additional IM documentation snippet, which explains the very same topic in different words.
So what remains is this:
- If you 'manipulate' your image with Gimp, and then embed the result in LaTeX, the page looks like you expect it.
- If you 'manipulate' your image with ImageMagick, and then embed the result in LaTeX, the page looks not like you expect.
Please provide the following to resolve the above issue:
- the exact version of your ImageMagick installation (complete output of
convert -version and
convert -list configure);
- (a link to an) original sample image;
- (a link to the) same image manipulated by Gimp;
- (a link to the) same image manipulated by ImageMagick.
This way we can help to solve the problem.
But note: this is a different problem from what your current subject/headline asks: "I want to change DPI with Imagemagick without changing the actual byte-size of the image data"