Opening a 72dpi .tif shows up as 96dpi in AP's Resize Doc

[meridian360]

Greetings,

Trying to avoid having that other app on a new machine, so trying to use Affinity Photo.

 

I'm opening large .tif files that are 60,000x48,000 pixels at 72ppi. Or at least they are supposed to be 72ppi. Opening these files in all other graphics apps, they show up as 72ppi.

 

But when I open them in Affinity Photo, and use the Document / Resize Document menu, that dialog box shows 96dpi. 

 

These are images for maps, so I need to make sure the ppi/dpi and scale all match. They go through a resize w/o resampling, then a change in dpi with resampling. But the start point has to be 72ppi.

 

 

Why is AP showing 96 dpi? 

 

Thanks,

.curt

[meridian360]

Bump: Anybody know how to contact Serif/Affinity directly? Doesn't seem to be anything on their website. 

 

Any Affinity staff around to answer this? 

>>> Why does Affinity Photo open a 72 dpi .tif file as 96 dpi? <<<

 

Thanks,

.curt

[MikeW]

Not Serif, obviously...

 

Likely the dpi field in the file does not contain dpi information. It may well be in the exif field, though. And if it is not explicitly in the dpi field, the OS default will be reported--unless the Affinity products simply default to 96 irrespective of the OS.

 

But either way, the dpi field is only informational. It has nothing to do with resolution. So set it explicitly if so needed.

[meridian360]

Thanks, Mike.
 
Well, the forum system wiped my first reply...let's try again...
 
If there isn't a header (and I think there is), then perhaps AP should ask us at what resolution we want it opened at? Similar to when you rip an eps in Photoshop. Why would AP think 96dpi is a good 'default' dpi to start with? 
 
And here's the problem: These images are background images for maps. They are exported from the GIS at set 72dpi x 72dpi dimension. Then we normally have to open them in Photoshop and change the image size without resampling to get our image dimension (ie print size) correct. Then usually, we have to go back and resize again, this time with resampling on, to get the dpi down to something reasonable (ie file MB size). 

So, the calculations have to be fairly precise. If my first step is to change it from 96 to 72, then it's one step too many. And of course, each image size transformation affects the 'data' in the image.

 

In the attached screenshot from Graphic Converter v10, you can see that GC reads it just fine. And rest assured, Photoshop does as well. 

And there's no EXIF information in the file, at least according to GC again.

 

And when opened in Preview (Mac OS Sierra). it shows 72 dpi, as well. (second screen shot).

 

The only 'weird' part is that it's a GeoTIFF, but that's never mattered to a graphics program before. 

 

In conclusion, if I'm to rid myself of the 'other' app, and use AP instead, it needs to open these at the correct resolution. 

 

But again, thanks Mike for the response. I appreciate it.

 

.curt

[MikeW]

Hi Curt,

 

I would still surmise that the information is not in the DPI field and is simply supplied by the application in lieu of specific dpi. It's just a two-byte field in the header of an image that really, really, means nothing.

 

As to why APh (which I do not have) on a Mac would report 96 dpi instead of a Mac "default" of 72 dpi is something for them to answer.

 

OK. When I export for specific size-purposes, all I care about is the dimensions--the number of pixels in relation to the placed size in order to achieve a specific pixel density.

 

An example. If I have a 4" wide column and desire a specific DPI of 300 for an image that will fit that column width, then I need the image width to be precisely 1200 pixels in width regardless of what that DPI field reports. The output will be precisely (as precise as the layout engine in say ID, QXP, etc, can do) 300 dpi in the PDF I am going to end up producing for print.

 

What the DPI field does allow for when truly present is for a layout application to initially size the image. That's it. In lieu of the explicit DPI declaration, layout application assume the OS default and one generally then needs to resize the image container downwards.

 

If you want to upload one such image to dropbox or the like and PM me a link, I would be happy to read the header information.

 

Mike

[Alfred]

As to why APh (which I do not have) on a Mac would report 96 dpi instead of a Mac "default" of 72 dpi is something for them to answer.

 

Maybe they want to maintain consistency with the CSS standard. Inkscape has at long last (in the new version 0.92, released at the beginning of the year) changed the default resolution from its strange old value of 90 dpi, for precisely that reason.

[MikeW]

Maybe they want to maintain consistency with the CSS standard. Inkscape has at long last (in the new version 0.92, released at the beginning of the year) changed the default resolution from its strange old value of 90 dpi, for precisely this reason.

 

But I would maintain that it is much ado about nothing. Especially where CSS is concerned with bitmap images. It means nothing. InkScape's SVG does have DPI meaning with CSS, but not bitmaps.

[MikeW]

So anyway, it would therefore seem that Serif isn't going to change this (if Alfred's assumption is accurate), that one can (should be able to) just change that field to 72 and then go about the remainder of the workflow.

[meridian360]

Mike,

 

Yup, I get resolution. Problem is, as with a lot of this stuff, any change introduces image quality issues. In my case, hillshading effects are affected. 

 

So if I know this is a 72 dpi image, and AP says it's 96....how did it make it 96? What do I base my math on? I'm not just concerned with output size (ie. screen/paper dimensions) but image quality. So I have to worry about the imagery not only looking good, but aligning 'perfectly' with other vector data like rivers. 

What "OS default"? Is 96dpi the default for AP on the Mac, because they assume that we're only building websites? They've got CMYK and Print page size defaults. But can only open things at 96? [sigh]  (Not trying to be argumentative, min[d] you.)

Oh, and the files are nearly 1 GB to start with, and reasonably proprietary. I'll have to dig around and see if anything else other than full on BBEdit can open image files to read the header. 

Alfred,

Thanks for the response. See, I'm old school, still doing large format print stuff. Is the CSS web standard set at 96dpi? Are you implying that Affinity is setting 96dpi as a default because they assume we're making web images? 

 

 

Thanks guys!

.curt

[Alfred]

Alfred,

Thanks for the response. See, I'm old school, still doing large format print stuff. Is the CSS web standard set at 96dpi? Are you implying that Affinity is setting 96dpi as a default because they assume we're making web images?

 

I've no idea why they've chosen that value, Curt, but (as Mike says) it's purely informational, or at least it should be! I don't understand why you're seeing a change in quality if you aren't resampling the image.

[MikeW]

If you change the DPI field to 72, without resampling, do the pixel dimensions change in APh?

[meridian360]

Oh, huh, AP has a built in header reader...

 

And you're right Mike, no dpi info in the header. 

 

But then, why does AP force us to use 96 as the default? Argh. :)

 

Thanks,

.curt

 

<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">

   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

      <rdf:Description rdf:about=""

            xmlns:tiff="http://ns.adobe.com/tiff/1.0/">

         <tiff:BitsPerSample>

            <rdf:Seq>

               <rdf:li>8</rdf:li>

               <rdf:li>8</rdf:li>

               <rdf:li>8</rdf:li>

            </rdf:Seq>

         </tiff:BitsPerSample>

         <tiff:Compression>5</tiff:Compression>

         <tiff:ImageLength>41855</tiff:ImageLength>

         <tiff:ImageWidth>65566</tiff:ImageWidth>

         <tiff:Orientation>1</tiff:Orientation>

         <tiff:PhotometricInterpretation>2</tiff:PhotometricInterpretation>

         <tiff:PlanarConfiguration>1</tiff:PlanarConfiguration>

         <tiff:SamplesPerPixel>3</tiff:SamplesPerPixel>

      </rdf:Description>

   </rdf:RDF>

</x:xmpmeta>

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                                                                                                    

                           

<?xpacket end="w"?>

[MikeW]

No idea why Serif uses 96 dpi on the Mac as a default. But in the image editors I use, that field can be changed without changing the image pixel dimensions and hence zero change in quality.

 

[meridian360]

Raw file: 65,566 pixels across. Roughly 683 inches across. <---math says it opened it to 96dpi

 

Then resize without resample: now nearly 911 inches <--- math says 72dpi.

 

 

So, presumably, I could redo my math routine and get the desired result, just from a starting point of 96 dpi. 

 

Hm.

[meridian360]

Did not change pixel dimensions, so in a pinch, I'm good to go. Just have to do the math.

 

Thanks guys,

.curt

 

ps. If Affinity is 'listening', please let us set the default dpi to match our needs. 

[meridian360]

Follow up: 

 

Even though putting in my target resolution works...it doesn't work. 

 

What I mean is, yes I can go straight from AP's default 96dpi to something else, like 1185 dpi... I need 1185.33 dpi to reach my print size accurately.

 

AP won't let you put in decimal dpi; just rounds to the nearest dpi. That may be for 'obvious' reasons, but in a 60" print that last .33 dpi adds up. 

 

Photoshop lets us use decimal dpi calculations. 

[meridian360]

Last one, I promise: 

 

Another thing that Photoshop allows, that AP does not, is to set the Document Size, which then adjusts the Resolution (to two decimal places) if resample is off. 

 

So, I can't use AP yet for my work. So close, yet so far...

[NilsFinken]

Just a thought: As ppi and dpi are not the same thing, could that be part of the problem? Try a Google search for "ppi versus dpi".

[meridian360]

Just a thought: As ppi and dpi are not the same thing, could that be part of the problem? Try a Google search for "ppi versus dpi".

 

Nope. I need my image at a very specific inch dimension, to THREE decimal places. Which in turn makes the dpi/ppi resolution 1185.33 dpi, which AP isn't capable of. 

 

Or if I open it in AP, and try to change the Picture dimension, and have it calculate the resolution, like Photoshop can....nope. Can't do it. AP won't let you input an image size and do the resolution for you. 

 

Try this.

Make a 65,566px by 41,855px tif file at 72dpi. 

Then try to make the image exactly 55.315" by 35.311", which results in a dpi of 1185.33 dpi.

But use the AP Resize Document dialog to input the Inch size. Can't do it. Or try to put in 1185.33 dpi. Can't do it.

 

So even if I was thrown off by the file being opened at 96dpi, which I'm admitting I was, it still can't get me to my actual target resolution. The problem has shifted from "what's with the 96?" to "Hm, AP can't do decimal resolutions". 

 

Attached are the Image Size boxes from Photoshop for the file in question.

1. Starts at 72 dpi and 65,566px wide.

2. Then set resolution to 1185.33 (which gives me a image size that exactly matches my map's scale)

3. Then if required, resample to a lower resolution for manageable file sizes, not dropping below 150ppi so it still looks good off the large format printer that's being used.

 

But again, I appreciate the response. 

Thanks,

.curt

[MikeW]

Follow up: 

 

Even though putting in my target resolution works...it doesn't work. 

 

What I mean is, yes I can go straight from AP's default 96dpi to something else, like 1185 dpi... I need 1185.33 dpi to reach my print size accurately.

 

AP won't let you put in decimal dpi; just rounds to the nearest dpi. That may be for 'obvious' reasons, but in a 60" print that last .33 dpi adds up. 

 

Photoshop lets us use decimal dpi calculations. 

 

What is your print size? How exactly are these printed? Direct to a RIP? Placed in an application? Or ???

[meridian360]

Global Mapper: Export a 75m sample to 72dpi Raster

 

Math: Convert to map scale  ((( 75m dot * 3.28084 ft/m) * 12in/ft) * 72 dpi) = raster scale

 

Ex: 1 in of export raster is 75 m wide on the ground. To find the scale of that output (so it can be scaled later to match the map scale) you need to convert it to inches. Then since it was output at 72 dots per inch, it gets multiplied by the 72.

 

Then find the ppi that will get the image to match the rest of the map. If map is 1:3,500,000 and your rater is ~1:212,000, then: (3,500,000/212,000)*72dpi = ~1185.33 ppi needed for raster to match vector map in Illustrator.

Photoshop: Take 72dpi image, resize resolution to 1185.33 w/o resample to get the 55.315" width that matches map.

Photoshop: But file size (MB) is still too big and 1185.33ppi is overkill for a large format inkjet printer, so convert with resampling to something around the 200 to 250 ppi range, which puts the file size around 400MB and still has IQ for the map.

Illustrator: New 200ppi raster placed in Illustrator. (Then when map is done, an eps is saved out to PS again, run through various color RIP to get it to the Epson printer, and printed. << This last part is not my domain, and I question the need for all the RIP stuff, but again, not my concern.)

 

So, really, it doesn't matter how they are printed. It's that they have to be a certain size to match the rest of the vector output at a very specific scale.

[MikeW]

What is the Illustrator document size?

[meridian360]

Illustrator doc size is irrelevant, in that the tiff isn't the same document size. 

 

The hills and valleys shown on the shaded relief .tif have to match the vector rivers. 

 

Screenshot 1. Tiff file vs artboard in AI

Screenshot 2. Closeup of how the raster has to align to the vectors. (Yup, it's the Grand Canyon.)

[MikeW]

Well, here is what I know. Using your previous dimensions on page one of an image needing to be exactly 55.315" by 35.311" and using the target resolution for the image of 150 dpi (which is what I nearly always use for large format printing), then as regards pixels, I need the image pixel dimensions of:

 

8270 x 5297 pixels

(8270.25 x 5296.65 rounded to the above)

 

And I would round else there will be anti-aliasing at the image edges.

 

And if I had that dimension in my image, I could care less what the DPI reports to be because that size of image will be 150 dpi at the placed size of 55.315 x 35.311 inches. I may well need to resize the image once placed simply because if I recall, AI will use the DPI field to do an initial resize. ID does anyway.

 

Now, I have not needed to place an image into AI or another software and have it match vector that has come in separately. Never have done maps myself. I have done tons of large and grand format printing though. And I wouldn't be able to demonstrate that this would indeed work exactly like all the math involved in your work-flow without an AI file and an image (which I assume are tiled together to produce a full map?).

 

But I don't believe I would need to mess with the calculations to achieve the same result, just the simple math of inches times target DPI to arrive at the requisite pixel dimensions. Without privately sent files, though, I guess all this is moot.

[meridian360]

Hi Mike,

 

Yes, 150 dpi is a standard resolution for printing. That's our minimum, as well. And sorry, I just can't send my client's files. 

 

The goal here is to get that 65,466 pixel wide, exported at 72 dpi, to fit a map that's at 1:3,500,000 scale, at a minimum of 150 dpi final resolution. 

 

Cartographers use dpi/ppi to get our stuff to a specific Scale. That might be where we're crossing wires a bit. Once we hit the minimum dpi for printing, the actual file dimension isn't so important, as long as it is big enough for the map's coverage. We aren't making a single static image fit a layout matrix. It has to fit all sorts of other line/point/area data that was exported separately from the GIS. 

 

What is important is that it's at the right Scale. If a lake is a mile wide on the ground and the map scale is 1" = 1 Mile, then the raster better show that lake to be 1" across, whether it's made up of 150 dots or 200 dots. 

 

Our recent project had a land cover raster. For a map that's at 1:3,500,000 scale (meaning 1" on map = 3,500,000" on the ground), the satellite data can be exported at a 75 meter sample size. That is, each dot of data is a generalization of a piece of ground that is 75 meters wide/across.

 

That raster is being exported from the GIS at 72 dpi. So for each inch of raster, there are 72 dots that are each 75 meters on the ground. So the scale of the raster is 1: 212,598.432. (see above for the formula.) That is, at 72 dpi, one inch of raster shows 212,598.212 inches across on the ground.

 

But to get that raster to match the vector/paper map in Illustrator, we have to get it scaled down to 1:3,500,000. So, divide 3,500,000 by 212,598, then multiply the results by 72 dpi, and you get 1185.33 dpi. 

 

1185.33 is the dpi the original 72dpi raster has be converted to in order to be at 1:3,500,000 scale. That way one inch of vector data exported separately from the GIS matches up with one inch of the raster. The file extents again doesn't matter, as long as it extends across the desired part of the map. It's not going to line up with any other file. Think of a map of the US, we use a "layer mask" to hide everything but say the land mass of the lower 48 states. The raster can be an inch bigger than the landmass's extent or it can be 30 inches wider. Doesn't matter; the mask is gonna hide the 'extra stuff'. So when I say the raster is 65,566, that never really enters the calculation, because we're not after an image size, we're after image Scale. 

 

----  

 

Now, this is where the decimal comes in. Maps at 60" across aren't too worried about a bit of anti-aliasing. But what is important is FIT. Does the raster "fit"?

 

We don't want to scale the raster in Illustrator. AT ALL. AI's scale tools are archaic, even barbaric (don't get me started). Beyond that, if there are color changes in the raster, we don't want to rescale it, each time for each new output. Even though you can re-link, sometimes there's 2-3 tiffs (shading, hypsometric tints, and land cover, etc) that are all exported at the same extents. So, we want to import the file, "Set it, and forget it". The less we scale images in AI, the better. 

 

But, can we round the scale? Nope. At the size of the maps, even that 0.33 difference in DPI makes all the difference between the raster "fitting" and not fitting. We're after the doc scale, regardless of that initial dpi. The dpi just serves as means to get to our proper scale, which in this case, results in a file that just happens to be 55.315" across. 

 

See screenshot of closeups of a US Lower 48 map for the comparison. The artboard in that file is 56" across. You can see the difference when both the 1185 and the 1185.33 files are aligned the same at the west coast. The 1185 does not align at all by the time you get to the east coast. That 0.33 difference in DPI makes for a .02" difference across only 75% of the map file. It get's bigger at the far east/right edge. That 0.02" is a noticeable difference. It's amazing how quickly stuff "sticks out" when rivers don't line up to the channels/canyons! ;)

 

----

 

If I were to use AP, right now, to make the raster, it would be rounded to the 1185 dpi. And it wouldn't fit. I'd have to try to scale it manually in AI. I'd rather dance in molten lava in bare feet than do that. :)

 

Thanks for the discussion and making me think. Hope this quick tutorial on how us map nerds get things put together. 

 

Cheers,

.curt