如果你的gdal版本是3.2.2及以上，那么只能：
from osgeo import gdal
ds = gdal.Open(data)
rows = ds.RasterYSize
cols = ds.RasterXSize
bandnum = ds.RasterCount
transform = ds.GetGeoTransform()
ds是一个对象，rows是影像的行，也是Y轴长度。对应的，cols则是影像的列，X轴的长度。bandnum代表影像的波段数。
transform是一个list，存储着栅格数据集的地理坐标信息。
#transform[0] /* top left x 左上角x坐标(经度)*/
#transform[1] /* w--e pixel resolution 东西方向上的像素分辨率*/
#transform[2] /* rotation, 0 if image is "north up" 如果北边朝上，地图的旋转角度*/
#transform[3] /* top left y 左上角y坐标（纬度）*/
#transform[4] ...
大家好，我是小白说遥感！今天我们继续聊聊遥感图像处理中的“老朋友”——裁剪影像（image clipping）。这是地理信息和遥感领域最常见、最基础的操作之一，但别看它简单，里面的“坑”和“门道”一点也不少。
随着传感器分辨率越来越高，单张影像动辄几十 GB，上百 GB 也不稀奇。很多小伙伴处理大文件时，经常出现内存爆掉、程序卡死、电脑宕机的情况（尤其是笔记本用户）。
那么裁剪这么大体量的影像，到底该怎么选工具？今天我们就从 rasterio 和 GDAL 两个角度来聊聊。
先说 rasterio：简单好用，但有“内存短板”rasterio 是一个专注于栅格数据操作的 Python 库，API 友好得像在玩积木，非常适合做快速开发和小规模数据处理。
其中最常用的裁剪函数就是：
from rasterio.mask import mask
out_image, out_transform = mask(src, [geometry], crop=False)
只要提供一个矢量 polygon，rasterio 就能帮你把影像剪得干干净净，尤其适合做：
小范围试验
批量测试
快速 d ...
大家好，我是小白说遥感，今天我们来聊聊在地理空间工作流中，YOLO 与 SAM 的对比分析。1. 数据集要求：有监督的边界框 vs 无需训练的提示
YOLO (v3 至 v9、YOLOv8、YOLO-NAS、YOLO-World)YOLO 是一种典型的数据驱动型模型。它要求提供带有标注的边界框数据集进行训练。它最适用于 COCO 风格的标注格式。在地理空间领域，YOLO 擅长处理来自大型正射影像的数百万个瓦片数据，尤其适用于数据经过清晰整理和策展的情况。
SAM (SAM、FastSAM、MobileSAM、SAM2)SAM 是一种零样本分割模型。它最大的特点是无需训练数据集。它通过使用提示（Prompt），如点、边界框或粗略的掩膜，来引导模型生成精确的分割结果。SAM 是在缺乏现有多边形标注或需要进行快速分割实验时的理想工具。
数据集总结：
YOLO 依赖大量标注数据，但运行稳定，结果可预测。
SAM 无需数据集，但分割结果依赖于用户输入的提示质量。
2. 算法与架构差异：检测优先 vs 分割优先YOLO：一步式目标检测器YOLO 是一种一步式目标检测器（One-Stage ...
大家好，我是小白说遥感，今天我们来聊聊图像处理中的一个实用技巧——直方图匹配（Histogram Matching）。
如果你是遥感、GIS、摄影或AI图像处理的从业者，肯定遇到过图像颜色不一致的问题。比如，多张卫星图像拼接时，颜色偏差会导致整体效果不佳。
这时候，直方图匹配就能派上用场，它可以让目标图像的颜色分布匹配模板图像，实现“匀色”效果。
本文基于一个Python脚本，详细教你如何实现批量处理16位、4波段TIF图像的直方图匹配。脚本使用分块处理，适合大图像，避免内存溢出。
我会一步步解释代码原理、如何运行，以及一些优化建议。无论你是新手还是老鸟，都能学到东西，以后自己复习也方便。
为什么需要直方图匹配？在图像处理中，直方图表示像素值的分布（比如亮度从0到255）。不同图像的直方图可能差异很大，导致颜色不匹配。
直方图匹配的核心是：
计算模板图像和目标图像的累积分布函数（CDF）。
通过映射，让目标图像的CDF匹配模板的CDF，从而调整像素值，实现颜色一致。
优势：
简单高效，尤其适合遥感图像（如卫星DOM）。
支持多波段（RGB+Alpha或多光谱）。
对于16位图 ...
在处理遥感影像和大型地理空间数据时，数据量动辄数十 GB 甚至 TB，传统的处理方式经常会遭遇“内存不足 (Out of Memory, OOM)”的窘境。幸运的是，GDAL（Geospatial Data Abstraction Library）提供了一个强大的解决方案——VRT (Virtual Raster)，即虚拟栅格。
VRT 并非一个真正的数据文件，它是一个 XML 格式的描述文件，它告诉 GDAL 如何将多个源文件组合起来，或者如何对一个源文件进行某种变换。它的核心价值在于其“即时计算，按需加载”的特性。
一、什么是 VRT（虚拟栅格）？想象 VRT 就像一张地图索引，它本身不包含像素数据，只记录了：
数据源在哪里（哪个 TIF、JPG、PNG 文件）。
数据源的地理位置（坐标系统、边界）。
如何组合这些数据源（比如拼接、重采样、重投影）。
当 GIS 软件或程序请求 VRT 上的某个小区域数据时，GDAL 才会去读取对应的源文件中的相应像素，大大节省了内存和处理时间。
二、VRT 的核心应用场景VRT 是处理大数据的瑞士军刀。以下是它最常用的几个场景：
大型影 ...
之前写了一篇关于wgs84影像转为cgcs2000的影像的文章：《wgs84影像直接转换为cgcs2000影像》
在里面我写道：诸如遥感数据处理的东西，其实是没有技术含量的，本质上都是调用gdal的东西，你把gdal的各个接口弄明白了就掌握这个数据处理的技能，唯手熟尔。真正有难度的是算法、加速处理速度。我其实很久不做数据数据处理的东西了，因为我有足够的代码积累，我建立了一个代码库，需要哪个模块，我直接搜索。
cscs2000坐标系的EPSG代码计算cscs2000坐标系其实和wgs84一样，分为两种：地理坐标系和投影坐标系。
用大白话来区分地理和投影，是看它们的单位。
单位若是度分秒，就是地理坐标系；单位是米，就是投影坐标系。
除此之外，我们还要获取坐标系的EPSG号码。
这个参数，我们需要填写到gdal的Warp进行重投影。
wgs84地理坐标系的EPSG号码4326，cgcs2000地理坐标系的EPSG号码4490。
如果你是想转换为cgcs2000投影坐标系，还得继续计算。
投影坐标系分为3度带，和6度带。
以3度带为例，不同的带号的计算规则如下：
例如，经度为105°E，计算过 ...
由于家里电脑的硬盘空间实在吃紧，我在清理空间时顺手就把 ArcGIS 卸载了。其实卸载的时候还是犹豫了一下——毕竟陪伴了我这么多年，用得最熟的还是它。但家里主要是做一些个人学习、测试项目，硬盘空间又寸土寸金，只能忍痛割爱。
为什么办公电脑我却一直没动呢？原因很现实：假设哪天同事突然甩给我一个 ArcGIS 的模板或者 MXD 文件让我立刻出图，如果我告诉他“我机器上没 ArcGIS”，那场面会尬到能当场原地升天。办公室毕竟要处理甲方的活儿，一点不能出差错。
那我为什么最终会卸载 ArcGIS？其实主要是因为 QGIS 在不少工作流中已经能替代 ArcGIS 了。更关键的是，我们行业的甲方大部分都跟GOV有关，而GOV单位这几年疯狂推进国产化改造。
国产 Linux 电脑里， ArcGIS软件是不让装的，审计、检测一层层卡着，根本没机会上。而 QGIS 作为开源 GIS，自然而然趁势上位，在国产系统里用得顺风顺水。
说实话，我对 ArcGIS 的熟练度远远超过 QGIS。用 ArcGIS 出图就像用右手写字，而用 QGIS 更像换成左手，总觉得别扭、不顺手。
快捷键、工具逻辑、窗口布局… ...
矢量的属性表转化为excel是不难的，在arcgis的工具有一个叫做：Table To Excel (Conversion)
在这里很快很简单地就可以把矢量文件的属性表导出，保存为excel文件。
用代码实现其实也不难，完整代码如下，我们调用geopandas库。
import geopandas as gpd
def shp2excel(shp_file, excel_file):
gdf = gpd.read_file(shp_file)
df = gdf.drop(columns='geometry')
df.to_excel(excel_file, index=False)
if __name__ == '__main__':
shp2excel("input.shp", "output.xlsx")
有时候因为是geopandas很难打包为exe，所以我们能尽量只用gdal的话，那就尽量只用gdal。
因为geopan
在半年前，我曾想过出一些关于编程、图像处理的视频教程。
在往常附上代码的以文本的形式，那如果要制作视频，那应该怎么制作呢？
我有认真思考过这个问题。
视频的本质就是多帧的图片叠加起来。
大致就是周星驰电影《苏乞儿》里那本武功秘籍，把书快速翻动，里面的小人就打一套功夫。
所以用python制作 一个类似 代码演示的视频，这是一件不难的事情。
写完了之后，我和朋友聊起这件事。
整体流程逻辑（大框架）代码主要分 4 个阶段：
① 初始化环境与加载字体
清空输出目录
找字体 → 成功用之，不成功就换 → 最后用默认
根据 Pygments 配色方案（dracula）获取各种 token 的颜色
② 按字符绘制代码，模拟打字动画核心逻辑：
代码内容 CODE_TO_ANIMATE → 清洗成干净的字符串
for char in clean_code： 每多一个字符，就重新画一张“当前代码”的截图
每生成一帧，文本要
用 PIL 绘制
按 token 上色（和 Python 语法高亮一样）
计算光标位置（像打字机一样挪动）
遇到换行 \n，会停顿一些帧（让动画更自然）
每一帧保 ...
这个现象，正是Python包管理设计中一个巧妙之处。简单来说，这主要归功于一种叫做“控制台脚本入口点”的机制。
当你 pip install xxx 的时候，实际上装了两个东西：
Python 包（库） 你在代码里 import xxx 用的就是它。
可执行脚本（命令行工具） 这类脚本会被 pip 自动丢到你的系统 PATH 里，所以你在终端能直接敲命令运行。
为什么能直接运行？比如你安装：
pip install jupyter
pip install gdal
然后你就能直接跑：
jupyter notebook
gdalinfo xxx.tif
原因是：
这些包的 setup.py / pyproject.toml 里写了 console_scripts
[project.scripts]
jupyter notebook = "jupyter:main"
意思是：安装后自动生成一个叫 jupyter notebook 的命令，执行时调用 jupyter.main()。
pip 会把这些生成的脚本放到：
Windows: Scripts/
Linux / Mac: ~/.l ...
