关于“在JPG格式从TIF转换中没有数据边缘聊天”的评论和答案

答案由helmoet

helmoet — 格林威治时间2017年7月26日星期三11:17:30

< id = " 9638 " href = " /存储/附件/ 9638 - examplerasters.zip”> examplerasters。zip < / > < id = " 9637 " href = " /存储/附件/ 9637 - transformraster.fmw”> transformraster。逐步< / > < id = " 9636 " href = " /存储/附件/ 9636 - generatetiff.fmw”> generatetiff。逐步< / > < id = " 9635 " href = " /存储/附件/ 9635 - compareraster.fmw”> compareraster.fmw < / >

答案由helmoet

helmoet — 格林尼治时间2017年7月26日星期三11:13:29

@john_linehan， @david_r，刚刚在这个主题上做了一些实验。我生成了一些示例tiff，满足规格，从一个ECW区域图像，我有。它剪辑了一个矩形的栅格片，再从结果剪辑了一个三角形的片。之后强制Real32并在结果上放一个NODATA值。这是生成的TIFF文件(使用IrfanView进行显示):

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:

david_r评论david_r的回答

david_r — 2017年7月25日星期二16:50:43 GMT

我同意，可能是jpeg压缩工件造成了这个问题。很高兴听到你找到了解决办法。

答案由john_linehan

john_linehan — 星期二，2017年7月25日16:37:48 GMT

你好，大卫。

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.

答案由david_r

david_r — 2017年7月25日星期二15:41:35 GMT

尝试使用RasterBandNodataSetter从-9999到0，并设置Replace = Yes。这时就不需要RasterCellValueReplacer了。

After coercing to 16Uint, try the RasterBandNodataSetter to 0 with Replace = No.

If that doesn't work, a small sample JPG would be helpful.