Can't I load images that are signed 16 bit?

4051
9
04-18-2016 11:04 AM
PaulHuffman
Occasional Contributor III

I have a set of old black and white airphotos that we scanned in house more than 16 years ago.  They are signed 16 bit Tiffs.  When I loaded them into SDE 9.3.1 to publish as an images service,  I had to convert them to 8 bit unsigned or they would just appear as all grey with one value in all the cells.  Well, now I am trying to load them into a raster dataset  on a SQL Server based 10.3.1 Enterprise Geodatabase, and I'm getting the same results.  But it seems like with 10.3.1 I am offered many more options on the kinds of images I can load.  Is it possible, if I find the correct options, to load this data, or will I have to convert them again to 8 bit unsigned?

A sample image is too big to attach here, but should show up here ftp://yakimagis:PomonaPasture-2@ykfp.org/BadTif  in a few minutes.

0 Kudos
9 Replies
PaulHuffman
Occasional Contributor III

Although I was able to load them into an SDE raster dataset as 16 bit unsigned,  the image service from this raster dataset was all one value gray.  I just went ahead and Copy Rastered them to 8 bit unsigned in order to make an acceptable image service,  same as I had to in 9.3.1.  Maybe this python script will be useful to someone faced with the same issue.

# -*- coding: utf-8 -*-

# ---------------------------------------------------------------------------

# Copyto8bit.py

# Created on: 2016-04-21 10:25:28.00000

#   (generated by ArcGIS/ModelBuilder)

#  Edited by PH

# Description: Copies WIP photos to another folder, converting to 8 bit unsigned, and building pyramids with bilateral

# ---------------------------------------------------------------------------

# Import arcpy module

import arcpy

import os

from arcpy import env

# Local variables:

InputFolder = "G:\\DOQ_photos\\wip\\FullSetTifs"

Outputfolder = "G:\\DOQ_photos\\wip\\FullSetTifs\\8Bit"

#workspace 

env.workspace = "G:\\DOQ_photos\\wip\\FullSetTifs" 

    

#List all features in  gp.workspace 

rasters = arcpy.ListRasters("*", "TIF") 

#raster = rasters.Next()

#print "\n".join(rasters)

for raster in rasters:

    # Process: Copy Raster

    Copyname = os.path.splitext(raster)[0] + "-8bit.tif"

    arcpy.CopyRaster_management(raster, (os.path.join(Outputfolder,Copyname)), "", "0", "0", "NONE", "NONE", "8_BIT_UNSIGNED", "NONE", "NONE")

    print Copyname + " is copied."

    arcpy.BuildPyramids_management((os.path.join(Outputfolder,Copyname)),-1,"NONE","BILINEAR", "DEFAULT", "75", "")

    print Copyname + " pyramids built."

0 Kudos
curtvprice
MVP Esteemed Contributor

Paul, what does this do the the value ranges? Seems to me it would be wise to either use the Copy Raster tool keyword "SCALEPIXELVALUE" or use the Slice tool to convert the data to an 8 bit range so you can preserve as much detail as possible.

PaulHuffman
Occasional Contributor III

My output looks good but I see the concern.  I'll have to try ScalePixelValue to see if I lost some data the way I did it.

0 Kudos
PaulHuffman
Occasional Contributor III

The old black and white photos look fine when I copied them to a new version, 8-bit and scaled pixels, but when I loaded them into a new SDE raster dataset,  it previews like this:    Clip8bitscaled.jpg

Very strange.

0 Kudos
curtvprice
MVP Esteemed Contributor

That is really strange. I'd double check all the data types and properties involved, both the input (8 bit image) and SDE raster dataset you are loading to. I don't know why but SDE rasters seem to always have all these gotchas related to bit depth, more than file rasters.

0 Kudos
PaulHuffman
Occasional Contributor III

This is getting stranger.  I started up Desktop 10.3.1 to take a look at these images services again,  but both looked like random color value pixels.  I investigated back to the source raster datasets in SDE.  Same thing.  I went back to the source individual tifs in standard disk storage.  Same scrambled mess.  Same when added to ArcMap as in ArcCatalog previews.  Same on my ArcServer machine. 

capWIP78.jpg

What changed since April 25?  Wasn't I still running Desktop 10.3.1?  I hooked up a laptop that is still running Desktop 10.2.2 to my network, navigated my network, and AC previews of the raster datasets, image services, and source images look fine,  grayscale black and white air photos as before.

0 Kudos
PaulHuffman
Occasional Contributor III

Stranger still.  I previewed the raster datasets and image services with ArcCatalog on my 10.3.1 client machine in early afternoon, and they looked like random color pixels as above.  I looked at them with ArcCatalog 10.2.2 on my laptop, and they looked fine.  I went back to my 10.3.1 client again in late afternoon, and they previewed just fine.  Something is unstable, intermittent here. 

0 Kudos
curtvprice
MVP Esteemed Contributor

I suggest clearing your raster cache, and viewing zoomed in.

This will ensure you are looking at the data, not a stale cache or pyramids.

Have you contacted Esri support on this? Seems to me you could use some expert help from them.

0 Kudos
PaulHuffman
Occasional Contributor III

Well, I talked to ESRI Support, and did a screen sharing session.  We didn't actually solve the original problem of having these 16 bit raster datasets displaying poorly in database connections or Image Services.  ESRI suggested that I copy the individual 16 bit tiffs to local storage, then create a moasic dataset and load in the tiffs, build overviews and analyze, and share as an image service.  So far, the database connection and the image service have been performing just fine.  

0 Kudos