There is a 10,000 px dimension limit regardless of MB size

Just thought I'd put this out there, since I couldn't find this information anywhere. Even if your image file is under the 20MB limit for paid users, if the image is longer or wider than 10K pixels, Roll20 will shrink the image size so that the offending dimension(s) come down to 10K.  The upload notification really should read " Supported file types are JPG and PNG, 20MB max, 10,000px limit ", because GIFs don't seem to be supported anymore (animated or not). It converted my GIFs to JPGs, and doubled their file weight in the process! To explain: I have a pixel-large  (19,800w x 26,100h) black and white GIF map with tons of little details, weighing in at only 17MB. In R20 it appeared fuzzy, so I selected the image instance on the page grid, pressed Z to view the source, and re-downloaded my own image - only to find that the length had been truncated to 10,000, and the width had been scaled proportionately (7,586). In other words, my image was blurry because the overall dimensions had been more than halved, even though it was under the MB limit. Even weirder, Roll20 ADDED 10K to the image in the conversion! So my big, crisp 17MB PNG became a smaller, blurry 27MB PNG, which is extra weird because now it's in excess of the 20MB limit. When I tried it with a GIF, Roll20 automatically converted it JPG while shrinking the dimensions, and similarly added file weight in the conversion. (I also tried uploading a tiny, simple, static, 100x100 GIF image, which was also instantly converted to JPG) Hope this helps anyone struggling with a similar confusion. Guess my maps have to be blurry, or I have to cut them into pieces. Bummer.

Thank you. I'd never have noticed that. I'm wondering why you need that pixel size, but knowing of the limit is good.

That is interesting.  I had done some testing in the past (a few years ago) and decided that the largest size (in original image pixels) that worked safely was 7500x7500. And I was able to tile 4 of those.  Hopefully there will be a workable solution to make your maps work at the desired sharpness and scale.  I am a proponent of large gameplay areas, when possible.  From what Roll20 has already said the upcoming "Project Jumpgate" should enable more power for the map and canvas size. 

Hi Frank! In general, tiling large images will lead to more efficient display with less lag, regardless of any Roll20 resizing. If it is a map, a common trick is to place an extremely low resolution image of the entire map, stretch out to fit, behind the sliced elements. This has two benefits: It will load first, so that players will know that images are loading; they'll just see the low-res image while waiting. Being the largest image on the page, it will form the thumbnail in the Page Toolbar, rather than just one of your slices. One last item to consider: Every graphic you upload is resized to four sizes: thumb, med, max and orig . These are used at different zoom levels to speed display. You might be being served one of the smaller ones, depending on the zoom level when you preview. Check for one of those keywords in the URL of the image.

While it is easy to blame Roll20 for this, I expect this behavior is due to WebGL limitations (which renders the images in the vtt if I remember correctly).&nbsp; If you visit this site, it will give you some details on your machine and WebGL: <a href="https://webglreport.com/?v=2" rel="nofollow">https://webglreport.com/?v=2</a> Something to watch for is the "Max Texture Size".&nbsp; That is the largest dimension of any image that your hardware can render in WebGL.&nbsp; My current graphics card is an RX6800, so not the latest and most powerful, but definitely not a low end card either. It can render an image with max pixel dimensions in any direction of 16384 using WebGL.&nbsp; If I was in your game, and Roll20 used the exact image you uploaded, I wouldn't be able to render it on my hardware in WebGL, because it exceeds that max texture size.Obviously, I would have no problem opening it in an image viewer or editing program, because those aren't using WebGL. Basically, it isn't only file size that matters.&nbsp; Pixel dimensions also are important.&nbsp; I expect some people running older integrated graphics cpus will be capped at half the dimensions I am.&nbsp; I don't see this sort of thing come up often on Roll20, but it was a pretty common "bug" that people kept reporting on another popular vtt discord server when I tried it a couple years back.

Thanks Kraynic! That's valuable information. I did not know any of that.

My card is weaker but more mainstream, I think (AMD 6600), and has the same texture limit, so I wouldnt be able to render it either. Fascinating info Kraynic.

Just split the map into three side-by-side images. Or use Photoshop or Gimp to reduce the size and maintain resolution. I'm curious how many squares the dimensions you are using are.

Excellent advice! keithcurtis said: Hi Frank! In general, tiling large images will lead to more efficient display with less lag, regardless of any Roll20 resizing. If it is a map, a common trick is to place an extremely low resolution image of the entire map, stretch out to fit, behind the sliced elements. This has two benefits: It will load first, so that players will know that images are loading; they'll just see the low-res image while waiting. Being the largest image on the page, it will form the thumbnail in the Page Toolbar, rather than just one of your slices. One last item to consider: Every graphic you upload is resized to four sizes: thumb, med, max and orig . These are used at different zoom levels to speed display. You might be being served one of the smaller ones, depending on the zoom level when you preview. Check for one of those keywords in the URL of the image.

DnDPlay20 said: I'm curious how many squares the dimensions you are using are. I've been wondering that too.

If it's anything under 113 x 149 squares, there are more pixels than could be displayed at full zoom (175 pixels per cell) anyway. At 100% zoom (70 ppc), this would be 282 x 372 squares. Assuming cell width = 1. Even if this were a gridless map, I would strongly advise slicing the image anyway, for the display efficiency reasons listed above. In my home campaign, I use a 132 x 172 square map (which is not as large) with no performance issues, but it does not use dynamic lighting and is composed of 6 slices.