DPI vs. PPI - What's the difference?

[RPMiller]

Excellent point! Done.

[Gamerprinter]

I just tried to export my exterior map to 1" = 5 feet at 200 dpi, and the file was over 1.8 GB in size! Note the map is currently scaled at 1" = 20 feet and its set dimensions are 54 inches by 43 inches, which means I have to rescale the map to 216 inches x 132 inches at 200 dpi to achieve proper scale.

This makes for a huge file.

The problem of course is that I need to include the idea that I'm going export at that specific scale when I create the map in the first place, so I can create manageable chunks that export easily at proper scale.

In regards to the DPI vs. PPI discussion, points to keep in mind:

1. Pixel or "picture element" is a basic element of color described on a video screen. Your screen has a set resolution that you can rescale if you have the right size monitor and proper video card. This however is measured both in pixels and dots per inch.

A pixel is square and is created using light shot through a monitor into your eyes.

A printed dot is a circle that is created from nozzles of inkjet paper or colored toner from a laser printer and is viewed by white light bouncing off the paper so your eyes can see the color (simplified explanation)

2. Most graphics software, even web graphics is not interdependant of DPI for measurement scale. Digital graphics and dpi can not be separated - not by definition of most graphics applications. They offer no "PPI" option.

I agree that a pixel and a dot are two different things, however software developers don't know the difference.

Regarding software and to help others understand how to create properly scaled map graphics for VTT use, they are treated as the same. You can't treat them as "apples and oranges" that will only confuse others.

Know then that a pixel and a dot are two different things. But if you want to 200 pixels to equal 5 feet in VTT scale, then you have to create your graphics at 1 inch equals 5 feet scale saved at 200 dpi - to get what you're looking for. That's all I'm saying.

My only question now is what is the dimensions of a standard map used for VTT use, in other words how many "feet" is shown on the monitor and how many feet are allowed off monitor that you can "scroll/move characters" within the same map?

If I knew that I could optimize my map designs for that scale and dimension in mind and create optimal VTT maps.

[RPMiller]

Please read through the article I linked to.

[kalmarjan]

Honestly,

This will only ever come up if you plan to print out your maps. The whole PPI vs DPI point is moot if you are just using your maps for a VTT.

A better thing to think of is pixel resolution. While you are dealing with a VTT, it is helpful to remember that you are basically rendering your images just like you would for a web page. There are several things to keep in mind:

1) Download/transfer times. Like it not, you are transfering your map to another client/player. While you may appreciate the 200 "DPI" image, the long downloading time on the client end will absolutely impact play. With some VTTs, this can lead to errors, especially if there is functionality built into the VTT for use with maps. (Fog of war etc.)

2) Designing any form of graphics at 200 PPI (or DPI if you prefer) is really a waste while on a monitor. You will have users with high end cards using a maximum of 92 PPI with those images, so you are wasting filesizes.

3) File format. This is a biggie. Some people swear by JPEG, others by GIF, others by PNG or BMP. In the end, it all comes down to what you are doing with the image. I prefer using JPEG with my maps, as it keeps the filesizes down. You will hear people say that this downgrades the image blah blah... which is true if you do not know what you are doing. As long as you are finished with an image, make it into a JPEG with as low as compression you can stand before the image degrades (*Imageready is a good program for this), and you now have a filesize that is 20% of what you started. For tokens, PNG is the way to go **if** there is any element of the token that needs to be transparent. If you can keep your token square, then it is better to use the JPEG format. If your token only has 256 colors, then GIF is a better option.

It is useful to look up the various file formats and see what is right. Better yet, look up tutorials on designing graphics for the web and you will set your mind straight on what needs to be done.

I hope that helps, and if there is any questions, hollar at my PM box, and I will try and help you all out.

Sandeman

[kalmarjan]

In regards to the DPI vs. PPI discussion, points to keep in mind:

1. Pixel or "picture element" is a basic element of color described on a video screen. Your screen has a set resolution that you can rescale if you have the right size monitor and proper video card. This however is measured both in pixels and dots per inch.

DPI is a measurement for printers ONLY. If you are speaking about screen resolution, it is better to refer to it is PPI.

2. Most graphics software, even web graphics is not interdependant of DPI for measurement scale. Digital graphics and dpi can not be separated - not by definition of most graphics applications. They offer no "PPI" option.

The two major ones, Photoshop, and GIMP measure these by Pixels/Inch, or PPI.

I agree that a pixel and a dot are two different things, however software developers don't know the difference.

Not true. In my experience, it is the user who does not know the difference. You will hardly ever see a setting in creating a new graphic or render that says "X number dots per Inch". The only time you will run into DPI is in print dialog boxes, where it is VERY important. This is usually based off your printer, but sometimes you can set the PPI to closely match the DPI. It is relatively based on the profiles you have set up for your printer within a program like photoshop.

Regarding software and to help others understand how to create properly scaled map graphics for VTT use, they are treated as the same. You can't treat them as "apples and oranges" that will only confuse others.

Know then that a pixel and a dot are two different things. But if you want to 200 pixels to equal 5 feet in VTT scale, then you have to create your graphics at 1 inch equals 5 feet scale saved at 200 dpi - to get what you're looking for. That's all I'm saying.

At that scale, each foot would be equivilent to 40 px. So a map size of 50 feet (or 10 5 foot squares) would be 2000 px X 2000 px.

My only question now is what is the dimensions of a standard map used for VTT use, in other words how many "feet" is shown on the monitor and how many feet are allowed off monitor that you can "scroll/move characters" within the same map?

If I knew that I could optimize my map designs for that scale and dimension in mind and create optimal VTT maps.

This would really depend. Again, I submit that it is up to you, and your players. It really helps to think of VTTs as web applications. Having a map that is 100 feet square equaling 4000 x 4000 px would be okay, if your VTT could handle that. Depending on what is on that map though, you could be looking at a significant filesize. If you are running a map that is like one of my photos (at 8.1 MP) then a 3264 x 2448 map size could run at 944 Kb unoptimized. If you were to save that out at 80%, you could be looking at a filesize of 755 Kb, which is not too bad.

I hope that helped out.

Sandeman

[RPMiller]

To add to the above, the point of doing 200 pixels = 5' is so that the user can down sample the graphic to whatever his application uses as its standard scale and most will still keep it at least double the default so that the players can zoom in and the image won't get badly pixelated. The 200 pixels = 5' is the largest scale I've seen used and is actually for Dundjinni which, interestingly enough, is geared specifically for printing out and playing on with miniatures, but the VTT community uses a lot of Dundjinni graphics for its maps and just resizes them as needed. For MapTool, which is what I use, the standard scale is 50 pixels / cell. This is different than mentioned above, but would require a bunch more of explanation so just assume 50 pixels = 5'. So it is pretty easy to just scale everything to 25% of original and call it done.

Regarding graphic formats, yes, there is quite a lot of discussion, but for my taste and most of those that I play with and talk to, PNG is the only way to go. It is a lossless format with a decent compression ratio and supports alpha channels. In fact the only thing it doesn't support is animation so I would definitely go with PNG. JPEG would be your choice for photographs though, but that is yet another discussion.

Anyway, all the information is out there and very well explained and reasons given. What has been posted so far has been a great introduction, and I want to thank Sandeman for his excellent posts as well.

[RobA]

Wow, this has been an active thread! Figured I'd chime in as well with a couple points of clarification...

I just tried to export my exterior map to 1" = 5 feet at 200 dpi, and the file was over 1.8 GB in size! Note the map is currently scaled at 1" = 20 feet and its set dimensions are 54 inches by 43 inches, which means I have to rescale the map to 216 inches x 132 inches at 200 dpi to achieve proper scale.

What kind of file was it? 1.8 GB is huge - this must be completely uncompressed!

A pixel is square and is created using light shot through a monitor into your eyes.

Not quite It all depends on the aspect ratio of your screen and the resolution you are driving it at.

2. Most graphics software, even web graphics is not interdependant of DPI for measurement scale. Digital graphics and dpi can not be separated - not by definition of most graphics applications. They offer no "PPI" option.

I think I must disagree here. Any raster graphic application (pixel based) I have seen used the terms pixels and DPI when defining the image - these two combined define a "print size". Many program, however, default the dpi, and changing it is buried somewhere within the application (if available at all).

The situation is very different for vector based applications, where the image is drawn, usually in real world measurements, and then rasterized out at a particular resolution. For example, if I have a 8"x10" image, and export it at 72dpi I end up with a 576x720px image. If I export the same image at 200dpi I get a 1600x2000 image. Now this gets even more complicated if you are drawing scaled in the application already.

Now this is clouded by Xara, as it is the only program I aware of that is actually a hybrid vector/raster application.

Know then that a pixel and a dot are two different things. But if you want to 200 pixels to equal 5 feet in VTT scale, then you have to create your graphics at 1 inch equals 5 feet scale saved at 200 dpi - to get what you're looking for. That's all I'm saying.

Yes - but only if your application is drawing in "real word units", which most "2D paint" program do NOT use.

so that the players can zoom in and the image won't get badly pixelated.

Which is why I'd like to see a pure vector (SVG?) VTT.

PNG is the only way to go. It is a lossless format with a decent compression ratio and supports alpha channels. In fact the only thing it doesn't support is animation so I would definitely go with PNG. JPEG would be your choice for photographs though, but that is yet another discussion.

OR JPEG for any photorealistic rendered map. (just watch the compression artifacts!)

-Rob A>

[RPMiller]

Excellent post RobA! Thanks for the additional information. Especially regarding Xara, and the vector information.

Yea, the vector VTT idea is routinely brought up. I think the reason there aren't any (that I know of) is because the programming is a lot more complex than just dropping in a raster image. The nice thing is that most folks typically don't zoom in more than 200%, with exceptions of course of what they are looking at at the time. That would be cool to be able to zoom in all the way to read the page of a book lying open on the table. MapTool has sort of taken care of that though in that you can now add an associated image to the object so that if a player hovers their mouse over the object a window pops up with an image.

[RobA]

I think the reason there aren't any (that I know of) is because the programming is a lot more complex

Hopefully that will change, as the next version of SVG standard will have some adaptive Level-of-Detail definitions. This web site describes the current proposal - and it looks pretty nifty.

-Rob A>

[RPMiller]

Nice! Some of those same algorithms are being used as guidelines in some of the new gigapixel images as well. Yes, I said gigapixel. If you haven't seen some of the new gigapixel images they are worth googling.