span8
span4
span8
span4
I have a TIFF file I am converting from 32Real to JP2 16Uint.The TIFF has NoData = -9999.I run a RasterCellValueReplacer to change -9999 to 0 and set NoData to Yes.Next is the RasterBandInterpretationCoercer to make it a 16UInt.When run,the JP2 has edge chatter with pixel values that were NoData now having values from 1 to 10.What is causing this edge chatter and how do I remove it?
Hi @john_linehan,@david_r,just did a bit of experimenting on the subject.
I generated some example tiff,fulfilling the specs,from an ECW areal image I had.It clips a rectangular piece of the raster and clips off again a triangle-shaped piece from the result.After that coerce to Real32 and put a NODATA value on the result.This is the resulting TIFF (using IrfanView for display):
For the sake of completeness,I included the workspace as GenerateTIFF.fmw.
Now I was able to reproduce the behavior using the workspace TransformRaster.fmw.The RasterBandNodataSetter seems to have no effect on the jp2 file,which seems logical since the jp2 format doesn't seem to register this property (quick facts states Not Applicable for Nodata Value).
When comparing both input and output rasters using RasterExpressionEvaluator and set expression (PRESERVE) to A[0]-B[0],after removing NODATA values from both rasters resulted in this (view from FME Universal Viewer):
It looks like a band of about 15 pixels has been added to the original raster,filled with random values (in my case varying from 0 to 4).Workspace to produce this result is CompareRaster.fmw.As indicated by John,this might be due to the fuzziness of the jp2 compression.However,there is a jp2 compression that is not fuzzy,well,not lossy or reversible using a CDF 5/3 wavelet transform (whatever that means).In FME it is implemented by setting compressionlevel for the writer to 0 (parameter Compress By Percentage,which by default is set to 75,i.e.,lossy compression).
This does not mean the resulting raster is not compressed at all.Still the uncompressed TIFF source file occupied about 10 times as much space as the "uncompressed" jp2 file (however,the 75% compressed result needs about half of that).
So,my guess is that if you specify 0 for the jp2 compression level,it does not suffer from the edge scattering.As can be seen from the picture below (again from FME Universal Viewer).
This analysis was based on this FME Version:
Hi David,
NoGo,still have the chatter.But thanks for the suggestion.
I wish I could send you one of the TIF's,but they are 250Mb each and I have 13,000 of them to let the air out of.I would still like to discover the answer.I thinks its because JPG's are "fuzzy" and the chatter is because of the blurred edge being given a pixel value instead of NoData.I may re-run the JPG's afterward to see if I can reset the pixels with values less than 10 to 0
Meanwhile,Due to time restraints,I simply went from TIF to TIF with 80% compression and they are coming down to a reasonable size.
Try using the RasterBandNodataSetter from -9999 to 0 and set Replace = Yes.You don't need the RasterCellValueReplacer then.
After coercing to 16Uint,try the RasterBandNodataSetter to 0 with Replace = No.
If that doesn't work,a small sample JPG would be helpful.
© 2019 亚搏在线Safe Software Inc |Legal