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.

[JayantaPoddar]

Just a comparison between JPEG and TIFF raster formats

Supported raster dataset file formats—Help | ArcGIS for Desktop

Format	Description	Extensions	Read / Write	Supported data types	Supports multiband	Supports compression	Supports color map
Joint Photographic Experts Group (JPEG) File Interchange Format (JFIF)	A standard compression technique for storing full-color and grayscale images. Support for JPEG compression is provided through the JFIF file format.	Single file—extension *.jpg, *.jpeg, *.jpc, or *.jpe	Read and write	8-bit unsigned integer	Yes	JPEG (lossy)	No
		World file—extension *.jgw			(Limited to one or three bands)
		ArcCatalog only recognizes the .jpg file extension by default. To add .jpeg or .jpe files to ArcMap without renaming them, add those file extensions to ArcCatalog or drag those files from Windows Explorer into your map.
Tagged Image File Format (TIFF) (GeoTIFF tags are supported.)	Widespread use in the desktop publishing world. It serves as an interface to several scanners and graphic arts packages. TIFF supports black-and-white, grayscale, pseudo color, and true color images, all of which can be stored in a compressed or decompressed format.	Single file—possible file extensions *.tif, *.tiff, and *.tff	Read and write	1-bit unsigned integer	No	CCITT (1D), CCITT Group 3, CCITT Group 4, Packbits, LZW, or None	Yes
				4-bit signed integer	No	Packbits, LZW, or None	Yes
	BigTIFF is supported.	World file—extension *.tfw		8-bit unsigned integer	Yes	Packbits, LZW, JPEG (lossy), or None	Yes
				8-bit signed integer	No	LZW	No
		ArcCatalog only recognizes the .tif file extension by default. To add .tiff or .tff files to ArcMap without renaming them, add those file extensions to ArcCatalog or drag those files from Windows Explorer into your map.		16-bit unsigned integer	Yes	LZW	Yes
				16-bit signed integer	No	LZW	No
				32-bit unsigned/signed integer, or floating point	No	LZW	No

[Anonymous User]

I have a similar question.

We are getting aerial 3" imagery from NearMap. They asked if we would like it cut into tiles or as a bigTIFF. Which would be faster to serve or are they the same, in terms of an ArcGIS Server service? Same question but in terms of disk space, any difference?

Also wondering whether I should put it in the SDE or FGBD. I think I read some stackexchange comments on FGBD being faster but I may contact Esri if I can not find this by researching.

Last, they claim they use compression 'throughout the process' which was surprising and I've asked for clarification. They also did specify whether compression was lossless. I'd hope so. I presume at some point the imagery is raw sensor data (akin to RAW) and I wouldn't think it'd be compressed on the fly right onboard the plane. This also got me wondering whether higher radiometric resolution impacts rendering speed but I would guess not really since at the end of the day a cell value is a cell value and a few extra digits I guess wouldn't matter.

So, next question is, does a TIFF, either bigTIFF or mosaic, serve faster without compression? I believe I read that it serves faster even thought it takes more space. We have enormous amounts of space and so if it's indeed faster than we'll request uncompressed data. 

Thank you all.

[NeilAyres]

Tiff is lossless, unless they are doing something on the front end before it becomes tiff. Compressions algorithmns like lcw are also lossless. ecw, jpeg, jp2 are not.

Just from a file handling point of view, most survey companies, provide the data in a series of "tiles", bit sized chunks. It is extremely easy to then use these as a data source for a Mosaic. No need to load these into sde or anything else. Just use a file system folder, and build the mosaic (in an fgdb) on top.

Then, if you have image server, you can publish this as a service.

If you havn't got Image server, then you need to make a tile cache, then publish that. The tile cache building can take a while though with very large raster datasets.

[Anonymous User]

Neil Ayres​

I came across some definitive resources for how to serve the data fastest, with size as a secondary consideration. (we have massive storage and size isn't a concern to minimize unless there is no CPU or other overhead cost speed-wise). 

http://blog.cleverelephant.ca/2015/02/geotiff-compression-for-dummies.html

https://blogs.esri.com/esri/arcgis/2010/12/21/rasters-get-speed-save-space/

We requested the highest quality deliverable, in tiled geoTIFFs.  But we will then create the tiles as you indicated and as Esri recommends. From Esri's link it appears tiled geoTIFFs with 75% JPG compression in YCBCR color are actually the fastest, and how we have always done it. For example... http://sagisservices.thempc.org/saint/rest/services/Imagery/Imagery_2013/MapServer

This appears to be the fastest way to serve imagery while balancing quality and size.  The note about color space from Paul in the first link I will have to research more but seems fairly straightforward and empirically demonstrated as Paul did with his tests.

Yes we have Image Server. But those are slower than tiles in my experience. That seems to be mainly for allowing people to query or work with imagery and create 'views' of rasters like slope and aspect from a DEM for example. Not relevant for simply viewing a regular three-band aerial.  Perhaps there are other advantages but as far as I know this is its main functionality. And perhaps something we'll employ with our DEM one day in the future.

[NeilAyres]

Yes, I agree. Publishing with Image Server isn't necessary for background imagery.

Probably a published tile cache is the way to go for speed purposes.

[NeilAyres]

Oh, and thanks for those links btw.