Thanks for testing out those steps in QGIS and sharing your findings. I looked into this some more and I have a couple more questions for you that may help us get to the bottom of this.
Are there any other files in the directory in which you keep the JPG and JGW files? Maybe an
.tab, or anything else? If you run gdalinfo on the JPG, what is the output? I’m wondering if it is detecting an additional file that specifies the coordinate reference system.
I ask because in this documentation on JPEG files in gdal (which is used by QGIS and by Cesium), it says:
There is currently no support for georeferencing information or metadata for JPEG files. But if an ESRI world file exists with the .jgw, .jpgw/.jpegw or .wld suffixes, it will be read and used to establish the geotransform for the image. If available a MapInfo .tab file will also be used for georeferencing.
So, it looks like a JGW file can provide the transform but not the coordinate reference system. The CRS (e.g., an EPSG code) would need to be provided separately for the imagery to be projected onto the globe. I’m wondering if there’s another file on your machine that might be supplying the EPSG for your tests in ArcMap and QGIS.
My other guess is that an CRS is indeed not specified by the files, but ArcMap and QGIS are falling back to a default CRS, which is why everything works on your end but not in Cesium. They are being aligned in the same arbitrary space, even though they don’t have the projection information necessary to be projected onto the globe. When you follow the QGIS steps in the tutorial I shared earlier, do you see this text once you do Step 6?
Either way, knowing this will help me understand what’s going on.
Second, do you know the CRS of the data (e.g., an EPSG code)? It may be possible to generate the necessary metadata file for Cesium to be able to project the JPG, but we would need to know the CRS.
I’m not positive that we’ll be able to make the JPG work in the end, but solving the projection issue would take us a step closer.