Conservative. Idaho. Software engineer. Historian. Trying to prevent Idiocracy from becoming a documentary.
Email complaints/requests about copyright infringement to clayton @ claytoncramer.com. Reminder: the last copyright troll that bothered me went bankrupt.
Subscribe to:
Post Comments (Atom)
There are 3 problems here.
ReplyDeleteFirst is that the "GIF" format *does not* carry a "DPI" field by default have a field for "page size" or "DPI". http://www.onicos.com/staff/iz/formats/gif.html It's just not a part of what GIF was designed to do.
Secod is that "DPI" is meaningless unless you're printing something on paper, or using a Postscript/PDF display engine like Solaris/NeXTSTEP/OPENSTEP used to have, or (sort of) the Quartz layer in MacOS. And even you are using a display technology like that it doesn't matter all that much.
(wait, you wrote printer drivers for HP, right?)
The other problem is that once you digitize an image it is damn near impossible to add information. You can use something like a gaussian blur then an unsharp mask to fake it, but that gets obvious.
Assume 1==yellow, 2=red, 3=blue:
112233
112233
222233
222233
333333
333333
right? Then we "double the DPI" which usually means as a linear count, really meaning a quadrupling of the dots per inch:
111122223333
111122223333
111122223333
111122223333
222222223333
222222223333
222222223333
222222223333
333333333333
333333333333
333333333333
333333333333
Or it could mean doubling the number of dots per SQUARE inch, and getting some interpolation between colors going on:
11422533
11422533
44422533
22222533
22222533
55555333
33333333
33333333
Where 4 is a color that is psychometrically between yellow and red, and 5 is between red and blue.
Now, if you ARE printing to printer, the Pixel on the screen does not translate directly to the dot on the paper, except in the rather rare case that it matches the ink 100 percent (for example if you have large area of cyan that the software thinks is EXACTLY the cyan that your printer has in it's cartridge). I forget the ratio, but if you've got a 600 DPI color printer and you're printing your image at 100 percent you are unlikely to see any quality gain above around 150 pixels per inch in your image.
This is known as "half-tone" (https://en.wikipedia.org/wiki/Halftone) although we rarely use amplitude modulation for dot size, preferring frequency modulation.
Does that explain it?
Image -> Scale Image
ReplyDeletenote the values for width and height. make sure they don't change.
adjust the values in "X resolution" and "Y resolution".
go back, make sure width and height haven't changed.
hit scale.
that'll keep the image contents/number of pixels from changing, and just tell software which renders the image to pack the pixels into a smaller space.
You can use IrfanView to open up any image file, click Image->Information and edit the DPI fields without altering the image width/height in pixels.
ReplyDeleteJay: What version of IrfanView do you have? I don't have I,mage->Scale.
ReplyDeleteBen: editing DPI fields in Image->Information does not change anything when I save vand reopen.
Save the GIF as JPG and Ben's solution works.
ReplyDeleteSorry, my instructions were for GIMP. (I was sticking with what you referenced in your post.)
ReplyDeleteI wouldn't expect there to be any visual differences if you change the DPI, these programs generally display at 1:1. As C. Petro suggests, the difference will be when you "display" the image to something with physical dimensions, like paper.
If he's right about GIFs not even having a place to store the DPI information, then you might consider resaving as PNG. There should be no loss, and similar if not superior compression. And I'm (fairly) confident PNG can store DPI.
That doesn't help. I may just have to live with pixelated images.
ReplyDeleteThanks all. Jay's solution worked.
ReplyDelete