hongfaqiu / TIFFImageryProvider

Load GeoTIFF/COG(Cloud optimized GeoTIFF) on Cesium
https://tiff-imagery-provider.opendde.com/?panel=layer
MIT License
52 stars 10 forks source link

v2.3.0版本及之前多个版本,在加载单通道数据时,当栅格金字塔层数较多时,会出现显示分辨率过低问题 #9

Closed xmsuperman closed 1 year ago

xmsuperman commented 1 year ago

error2

error4 pic1为显示效果

Pic3为影像原数据信息

hongfaqiu commented 1 year ago

可以通过配置minimumLevel控制最小显示层级,提高分辨率,默认为0 参考 https://github.com/hongfaqiu/TIFFImageryProvider/issues/2#issuecomment-1517608158

xmsuperman commented 1 year ago

感觉改过了不是很有效啊

xmsuperman commented 1 year ago

试了一下,初始化时候的确提高分辨率了,但是放大以后的没有跟着提升,看起来还是虚的...

hongfaqiu commented 1 year ago

如果是cesium本身的瓦片调度问题,那这个很难解决,瓦片请求层级是通过camera和tilingScheme的rectangle范围共同判断的,cesium没有提供手动更改的接口。 实际上加载全球范围的cogtiff,按照你截图上的相机高度来说,它请求的已经不是第0层级了,可能是第3层级,即使这样,还是清晰度不够的话,可能是切片的瓦片大小过小了? 可以尝试修改tileSize参数,默认从cog瓦片信息中获取,可以手动设置为512、1024等值,在解码瓦片时会做超分辨率处理。

xmsuperman commented 1 year ago

这个读取瓦片每层的分辨率,应该是根据瓦片层级固定的,而tif金字塔的层级是不固定的,尤其是在生成的时候,默认是每层大4倍,但是从gdal的接口上来看,这个采样率是可以变化的,如果从tif的meta头里去取层级,就会导致出现这种因为金字塔层级过高而导致读取了不合适的采样率图层,使用minimumLevel来控制,只能控制第一层显示的效果,一但放大还是根据原有的分辨率来加载。 建议考虑跟据cesium的层级,固定每层的采样率,一但层级超过tif最高层级的采样率,再固定为tif本身最高层的采样率。

hongfaqiu commented 1 year ago

我没有理解您的意思。 COGTiff瓦片的大小是固定的,它由生成COG的参数控制,一般来说是512512。而由cesium x,y,z参数决定的、获取到的COG原始数据是根据瓦片的地理范围计算获取。但是cesium瓦片的渲染大小可以进行更改,默认和COG瓦片的大小一致,以获取最佳效果,自定义为10241024的情况下,将进行超分辨率处理,将原本512512的瓦片数据超分辨率,显示效果上只会变得更光滑,而不是更清晰。 至于请求层级,现在的调度规则是,假设COG瓦片有N层,则在cesium瓦片参数为z时,请求第N-z层COG瓦片。这样的请求策略应当是最合理的,每次可以以最小的请求量(最小为tileWidthtileHeight,最大为tileHeightImageWidth + tileWidthtileHeight)完成获取对应空间范围tiff数据的请求。

xmsuperman commented 1 year ago

COG的金字塔,并不匹配cesium的z轴; COG的金字塔,如您所见的图,是以1,2,4,8,16,32由高到底,他的意义是: 以1为基本分辨率,取样放大一倍,而对应像素是X轴2,Y轴2,他的级别是由最低层的的分辨率决定的;

而Cesium的金字塔,默认每级的分辨率是固定的,假设第1层是512分辨率的1张图,每一层放1大倍,则是4个512*512,由低向高

COG的层数和Cesium的层数本质上是没有关联的,也就是说,TIF原始分辨率有可能是cesium的第5级,第10级,或是第15级,这是由图像的分辨率决定的。

你用N-z的COG层去推断当前分辨率,那当然会取错当前层数的分辨率....

hongfaqiu commented 1 year ago

假设cesium的z为0,但如果我需要使用第2小的COG瓦片层,而不是最小的瓦片层,就会造成4倍请求大小,这对浏览器来说会是很大的压力。 理论上COG的金字塔构建上应当是完善的,会自动根据原始影像的分辨率大小以及tileWidth参数切分合适的层数,它会在对应层级显示清晰的瓦片,这和cesium的层级策略是一致的,我认为并不会取错当前层数的分辨率。 另外不知道ol上的效果如何?

hongfaqiu commented 1 year ago

此处cesium的z值是由tilingScheme决定的,比如z=0时,会有1 1张瓦片,因此请求COG最大的第N级瓦片,也只有11张,z=1时,会有2 * 2张,由此类推,每次z值对应的COG瓦片层级应当是N-z,N为COG的层级数量,z为当前视窗下的tiff图层瓦片层级。

xmsuperman commented 1 year ago

COG的金字塔构建当然是完善的,但是COG的金字塔和Cesium的金字塔并不是n-z的关系,因为COG的金字塔的起始层N对比于Cesium的层数是不固定的,是由分辨率决定的,COG的第一层,有可能对应Cesium上第5层,第10层,或者第15层,这由栅格数据的分辨率是1度,0.1度,或者0.05度而定,COG是由下向上,Cesium是由上向下(EPSG:4326),但如果是EPSG:3857就是由下向上。另外,COG的金字塔,有可能是每4个像素取1为一级,也可以是3个像素取1为一级,这是可以配置的。 总而言之,不能用简单的N-z来决定COG和Cesium的层级关系。

另外,我的那张示例如,在OL下是可以正常工作的,我正在寻找ol源码中的相关信息,给您提供相关的提示。

hongfaqiu commented 1 year ago

感谢帮助!但我仍旧不能理解COG的第一层,为什么有可能对应Cesium上第5层,第10层,或者第15层,这里的z值您可以在控制台输出一下看看。cesium中某个相机高度下,每张tiff影像的请求层级z都是不同的,这和它的空间范围有关,由此去请求对应的cog瓦片应该没什么问题。 我最开始也是参考ol代码写的,如果您能提供更多信息,感激不尽!如有可能,也希望您能发起PR,共同完善这个仓库

xmsuperman commented 1 year ago

请发送邮件:6431063@qq.com 给我告知您的wechat帐号名,希望能通过微信与您建立联系。