Publishing raster tile service but resulting tile cache is obscenely huge

HollyTorpey_LSA

Greetings! I am reaching a state of desperation here.

I'm trying to publish some drone imagery to Portal as a tile service (about 150 acres captured from 400 ft with a 3.2 cm cell size... the orthomosaic tiff file is 2.1 GB, or 10 GB uncompressed), but the necessary tile cache for the tiling scheme I want is estimated to be in the terabytes. I need to publish all the way to zoom level 23 because the imagery will be used to identify vegetation classes, so resolution is important.

Recently I published another orthomosaic for a somewhat larger area with even high resolution. The orthomosaic tiff file was about 20 GB (44 GB uncompressed), and this is what its tile cache looks like (somewhere between 2 & 3 GB):

I was expecting a smaller total cache size for this new image because the file is much smaller (2 GB vs. 20 GB). However, this is what the estimated tile cache looks like for this new one (these are zoom levels 16 - 23): 

Why on earth would this image require 5 million tiles for zoom level 16 when the first image required 8? Why would the tile cache for a 2GB image be over a hundred TB?

I am publishing directly from Pro using "Share as web layer" with these settings: 

 

I have also tried using the tiling scheme from the other layer, but that for some reason brings in a scheme that will only cache tiles for zoom levels 5-11, even though the service actually has tiles for zoom levels 16-23, as shown above in the first screenshot.

I've also tried creating my own tiling scheme but that didn't seem to help at all either.

I have tried saving the SD file and publishing that directly through Portal using the "new item" button and the tile layer option. That produces the same results: 

I have compared the raster information of the two images and can find no explanation for the difference. If anything, the first image should have more tiles.

First image: 

Second image:

The only thing I can think of that is different is that the first orthomosaic was producted in Pix4Dmatic and the second one was produced in Pix4Dmapper. But why would that matter?

Does anyone have any idea why Pro and Portal want to produce such a massive tile cache? Is there another way I can get this imagery published in an efficient manner?

I will be incredibly grateful to anyone who can help me resolve this issue.

HollyTorpey_LSA

Okay, I'm still not sure what was going on, but here's what ended up working for me (in case anyone else is having the same problem):

I added a new map to my project. I did not set a projection but verified that the map was in Web Mercator. Then I added my orthomosaic tiff file. After I added it, I checked the map's coordinate system again and saw that it was now set to the projected coordinate system of the image (as was the first map, which is why I don't understand what is different in this map). Then I right clicked on the image an d opened the Share as Web Layer panel, selected the ArcGIS Online / Bing Maps / Google Maps tiling scheme, set the levels to 16 - 23 (also the same as my previous attempts) and then calculated the estimated cache size, getting a much more reasonable 1.25 GB. I have no idea what was different in this new map or why it made a difference, but after several days of gnashing my teeth, simply opening a new map was the solution. Wish I had tried it sooner. 

If anyone knows why publishing the imagery from a new map made a difference, please let me know! Stumbling onto a solution and not understanding why it works is rather unsatisfying. ">😐