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?
Page 1 / 1
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.
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.
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.
Hi@john_linehan, @david_r, just did a bit of experimenting on the subject.
I generatedsome example tiff, fulfilling the specs, from an ECW areal image I had. Itclips a rectangular piece of the raster and clips off again a triangle-shapedpiece from the result. After that coerce to Real32 and put a NODATA value onthe result. This is the resulting TIFF (using IrfanView for display):
For thesake of completeness, I included the workspace as generatetiff.fmw.
Now I wasable to reproduce the behavior using the workspace transformraster.fmw. TheRasterBandNodataSetter seems to have no effect on the jp2 file, which seemslogical since the jp2 format doesn’t seem to register this property (quickfacts states Not Applicable for Nodata Value).
Whencomparing both input and output rasters using RasterExpressionEvaluator and setexpression (PRESERVE) to A 0]-B-0], after removing NODATA values from bothrasters resulted in this (view from FME Universal Viewer):
It lookslike a band of about 15 pixels has been added to the original raster, filledwith random values (in my case varying from 0 to 4). Workspace to produce thisresult is compareraster.fmw. As indicated by John, this might be due to thefuzziness of the jp2 compression. However, there is a jp2 compression that isnot fuzzy, well, not lossy or reversible using a CDF 5/3 wavelet transform(whatever that means). In FME it is implemented by setting compressionlevel forthe writer to 0 (parameter Compress By Percentage, which by default is set to75, i.e., lossy compression).
This doesnot mean the resulting raster is not compressed at all. Still the uncompressedTIFF 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, myguess is that if you specify 0 for the jp2 compression level, it does not sufferfrom the edge scattering. As can be seen from the picture below (again from FMEUniversal Viewer).
Thisanalysis was based on this FME Version:
