Jpeg vs Tiff for orthophoto deliverable

[MikeSchonlau]

We need to decide on a deliverable format for orthophoto images to be captured during an upcoming flight. I have always used geotiff or tiff. Our vendor tells us the images come off the plane in jpeg (80 compression ratio). We could have these converted to geotiff without any further compression. We could also choose to have them delivered as that raw jpeg with world files. Or we could go to jpeg 2000 to avoid world files.

In this case, the jpeg's will be about 1/10 the size of the geotiff. We plan to reference all of these images in a mosaic dataset. Mosaic dataset image loading time is not a deciding factor for us because it is only a one or two-time thing. Rendering performance is though. We will cache the images for the web and caching time is also not important to us because we only cache it once or twice.

Bottom line - how well these images display in ArcGIS Desktop/ArcGIS Pro from a local SDE geodatabase mosaic dataset is the most important variable for me. Storage space is the next most important factor. Which format would you choose and why? Thanks in advance for your feedback.

[DanPatterson_Retired]

just to check... you have seen the limited help information topic here... Mosaic dataset overviews—Help | ArcGIS for Desktop

[MikeSchonlau]

Dan

Thanks for the response. I'm very familiar with mosaic datasets and overviews - been using them for many years. My question is really about whether it makes sense to have the vendor convert these jpeg (80) images to geotiff or not. I'm looking for anyone who's built their datasets using jpeg images vs using geotiffs.

[NeilAyres]

So your vendor does this really expensive aerial survey, then immediately throws away a good chunk of the data (by using lossy compression), just to save a bit of disk space! Ridiculous.

[DanPatterson_Retired]

16 digits again?

[MikeSchonlau]

Neil

Thank you for responding. I have to imagine they are doing this due to the size of the images (3" GSD). I'm not an expert in image processing on-board the aircraft, so I'm starting with what comes off the plane. Did you have any advice on jpeg vs geotiff?

[RebeccaStrauch__GISP]

Tagging Imagery and Remote Sensing​ so you have more exposure.

i am no imagery spent, so will not attempt to answer your question, but one comment I have about the mosaic dataset....I dont think there is any advantage in creating the dataset in SDE.  I think a FGDB mosaic dataset works just as well (better?) and if you keep you path names the full path name (versus a mapped letter that may change), including the .ovr file location, it's easy to copy the mosaic dataset to other locations for distribution, if necessary. The mosaic dataset itself is pretty light weight.  My opinion only.

for caching...if you have the ArcGIS Server, Image Server extension, that allows you to cache much faster (directly from the mosaic dataset) and also provide services using functions (for simple example,hillshasde, aspect, slope, etc) on the fly, without caching.  The extension is pricy, but just in case you have it already (or are considering it).  Again, just my opinion.

[MikeSchonlau]

Thanks for your response, Rebecca. I will give some thought to FGDB vs SDE. Intriguing...

I do own the imagery extension already and use it regularly to publish. We always cache directly from the mosaic dataset.

[NeilAyres]

Yes,

Mosaic datasets are best at welding together the imagery in whatever format the imagery is supplied in.

There is no need to import them into a different format (fgdb, sde, whatever) before hand. Thus saving all those extra copies of stuff that can be quite big.

They still have to be available to the service somewhere after publishing, unless you go the route of caching, which can be bigger than the original.

[NeilAyres]

As regards jpg vs geotiff...

I have some experience publishing ecw, which, apparently, you need a license for if you publish it.

So we converted the imagery to tiff.

If jpg is what you have, use it. As long as the final result looks good, go for it.