示例工程教程后端【免费下载链接】aws-doc-sdk-examplesWelcome to the AWS Code Examples Repository. This repo contains code examples used in the AWS documentation, AWS SDK Developer Guides, and more. For more information, see the Readme.md file below.项目地址https://gitcode.com/gh_mirrors/aw/aws-doc-sdk-examples点击查看免费下载导读本文围绕 pixel-data-verification 示例系统讲解如何借助 AWS HealthImagingAHI即 AHLIAWS Health Imaging的 Pixel Data Verification 能力通过 JavaScript/Node.js 确认从 AHI 解码出的图像帧与原始 DICOM P10 文件内容完全一致。读完本文你将掌握「拉取 ImageSet 元数据 → 获取图像帧 → HTJ2K 解码 → 与元数据中声明的 CRC32 校验和比对」的完整链路并理解其在医疗影像数据完整性验证中的实战用法。背景为什么要做像素数据校验DICOMDigital Imaging and Communications in Medicine是医学影像数字化存储与传输的国际标准。AWS HealthImaging 在导入 DICOM 文件后会将原始 P10 文件转换为 HTJ2K 编码的中间格式image frame供高效检索与分发。由于图像帧在存储、传输与解码过程中可能发生损坏或篡改AHI 在生成每个图像帧时计算了从原始像素数据到完整分辨率base-to-full-resolution的 CRC32 校验和序列并随 ImageSet 元数据一起返回。客户端解码后自行重新计算 CRC32 并与元数据声明值比对即可端到端确认「解码结果 原始 DICOM 像素数据」。本示例即该验证流程的最小可运行实现代码位于 index.js配套的集成调用场景见 health-image-sets 工作流。依赖与环境该示例使用 JavaScript 与 Node.js 编写核心依赖如下见 package.json依赖版本/形态作用AWS SDK for JavaScript v3aws-sdk/client-medical-imaging^3.427.0调用GetImageSetMetadataCommand与GetImageFrameCommand两个 AHI APIcrc-32^1.2.2计算解码后像素缓冲区的 CRC32 校验和openjphjsHTJ2K 解码仓库内置 WASM 构建openjphjs/openjphjs.js openjphjs.wasm将 AHI 返回的 HTJ2K 编码图像帧解码为原始像素位图其中openjphjs是 openjphHTJ2K 编解码库的 JavaScript/WebAssembly 构建以本地模块形式随示例分发对应的第三方许可声明见 THIRD-PARTY-LICENSES。此外package.json的 devDependencies 中还包含vitest ^1.6.0用于对上层场景做单元测试详见下文「测试」一节。部署三步安装按照原文档步骤执行即可# 1. 检出项目克隆仓库 # 2. 切换到示例目录 cd javascriptv3/example_code/medical-imaging/scenarios/health-image-sets/pixel-data-verification # 3. 安装依赖 npm installnpm install会安装aws-sdk/client-medical-imaging与crc-32两个 npm 依赖openjphjs无需额外安装直接通过require(./openjphjs/openjphjs.js)从本地加载。使用方法完整操作步骤前提准备创建 Datastore按照 AWS HealthImagingAHLI开发者指南创建数据存储datastore并获得DATASTOREID导入 DICOM 文件按照开发者指南将示例 DICOM 文件 test/fixtures/CT1_UNC 作为 DICOM 导入作业的输入导入到上述 datastore获取 ImageSetIdDICOM 导入作业完成后从 S3 中的作业输出清单manifest文件里读取由该导入产生的IMAGESETID准备 UID记录待验证的 series 与 SOP instance UID。运行命令按顺序传入DATASTOREID、IMAGESETID、series 与 SOP instance UID$ node index.js $DATASTOREID $IMAGESETID 1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457 1.3.6.1.4.1.5962.1.1.1.1.1.20040826185059.5457 CRC32 match!示例中使用的 UID 与仓库内置测试数据CT1_UNC对应1.3.6.1.4.1.5962.1.3.1.1.20040826185059.5457为 series instance UID1.3.6.1.4.1.5962.1.1.1.1.1.20040826185059.5457为 SOP instance UID。若校验通过控制台输出CRC32 match!若不一致则输出CRC32 does NOT match!。源码级原理剖析整体数据流index.js 的执行流程可分为五步获取并解压 ImageSet 元数据调用GetImageSetMetadataCommand得到 gzip 压缩的元数据 Blob用node:zlib的gunzip解压后JSON.parse按 UID 查找图像帧 ID在元数据树Study.Series[seriesInstanceUid].Instances[sopInstanceUid].ImageFrames中取第一个图像帧的ID获取图像帧调用GetImageFrameCommand以{ datastoreId, imageSetId, imageFrameInformation: { imageFrameId } }为参数拉取 HTJ2K 编码的imageFrameBlobHTJ2K 解码把字节填入openjphjs的HTJ2KDecoder编码缓冲区并调用decode()得到解码后的原始像素缓冲区CRC32 比对用crc-32计算解码缓冲区的校验和与元数据中声明的完整分辨率校验和比较输出结论。元数据的获取与解析const getImageSetMetadataInput { datastoreId: datastoreId, imageSetId: imageSetId, }; const getImageSetMetadataCmd new GetImageSetMetadataCommand(getImageSetMetadataInput); const getImageSetMetadataRsp await miClient.send(getImageSetMetadataCmd); const imageSetMetadataBlobByteArray await getImageSetMetadataRsp.imageSetMetadataBlob.transformToByteArray(); const imageSetMetadataBuffer await gunzip(imageSetMetadataBlobByteArray); const imageSetMetadata JSON.parse(imageSetMetadataBuffer);关键点在于响应的imageSetMetadataBlob是contentEncoding: gzip、contentType: application/json的流式 Blob参见 actions/get-image-set-metadata.js 中同样的调用形态必须先transformToByteArray()再gunzip才能得到可解析的 JSON 文本。解压后的元数据顶层结构包含SchemaVersion、DatastoreID、ImageSetID、Patient、Study等字段其中Study.Series以 series instance UID 为键其下Instances以 SOP instance UID 为键该结构的 TypeScript 风格定义可参见 verify-steps.js 顶部的 JSDoctypedef。按 UID 定位图像帧与校验和声明const getImageFrameForSopInstance (metadata, seriesInstanceUid, sopInstanceUid) { try { return metadata.Study.Series[seriesInstanceUid].Instances[sopInstanceUid].ImageFrames; } catch (e) { throw Unable to get image frame ID from metadata. Check series and SOP instance UIDs.; } };每个图像帧对象含ID图像帧唯一标识与PixelDataChecksumFromBaseToFullResolution从基础分辨率到完整分辨率的逐级校验和数组元素含Checksum、Height、Width等字段。示例取数组最后一个元素作为完整分辨率full resolution的最终校验和const fullResCRC32FromMeta imageFrameMeta[0].PixelDataChecksumFromBaseToFullResolution[ imageFrameMeta[0].PixelDataChecksumFromBaseToFullResolution.length - 1 ].Checksum;HTJ2K 解码与 CRC32 计算openjphjs的 WASM 运行时在onRuntimeInitialized回调就绪后才创建解码器实例整个过程因此被包裹在该回调内openjphjs.onRuntimeInitialized async (_) { const decoder new openjphjs.HTJ2KDecoder(); // ... const encodedBuffer decoder.getEncodedBuffer(imageFrameData.length); encodedBuffer.set(imageFrameData); decoder.decode(); const decodedBuffer decoder.getDecodedBuffer(); // ... const fullResCRC32Signed CRC32.buf(decodedBuffer); const fullResCRC32 fullResCRC32Signed 0; // convert to unsigned if (fullResCRC32 fullResCRC32FromMeta) { console.log(CRC32 match!); } else { console.log(CRC32 does NOT match!); } };注意CRC32.buf()返回的是有符号32 位整数而元数据中的Checksum为无符号十进制值因此必须通过 0位运算转为无符号数后再比较这是校验能正确命中的关键细节。客户端初始化与区域配置const AHI_REGION ; const { MedicalImagingClient, GetImageSetMetadataCommand, GetImageFrameCommand } require(aws-sdk/client-medical-imaging); let imagingClientConfig; if (AHI_REGION) imagingClientConfig.endpoint AHI_REGION; const miClient new MedicalImagingClient(imagingClientConfig);从源码看AHI_REGION默认被初始化为空字符串因此imagingClientConfig保持undefined客户端将完全采用 AWS SDK 的标准配置链共享凭证文件、环境变量、IAM 角色等确定区域与凭证。若需显式指定区域/终端节点可自行设置AHI_REGION注意同时需构造imagingClientConfig对象这为本地模拟服务或非默认分区调试留出了扩展点。命令行参数约定if (process.argv.length 5) { console.log(node index.js datastoreid imagesetid seriesInstanceUid sopInstanceUid); process.exit(1); } const datastoreId process.argv[2]; const imageSetId process.argv[3]; const seriesInstanceUid process.argv[4]; const sopInstanceUid process.argv[5];位置参数即 README 使用示例中的四个值参数不足时打印用法并退出。在端到端场景中的集成方式pixel-data-verification并非孤立工具它被 health-image-sets 完整工作流作为「下载 → 解码 → 校验」环节引用。该工作流以node index.js --scenario deploy | demo | destroy驱动通过 CloudFormation 创建 datastore、输入/输出 S3 桶与 IAM 角色从公共桶拷贝 DICOM 研究、运行导入作业后调用本验证工具对每个图像帧做校验。在 verify-steps.js 中decodeAndVerifyImages以spawn(node, [./pixel-data-verification/index.js, datastoreId, imageSetId, seriesInstanceUid, sopInstanceUid], { stdio: inherit })的方式逐 SOP 实例启动本工具并监听子进程退出码——退出码为 0 视为校验通过否则抛出Verification tool exited with code ...错误。也就是说该工具同时可作为独立的 CLI 命令使用也可作为更大自动化场景中被编排的校验子进程。测试验证仓库为上层场景提供了针对性的单元测试tests/hlth-img-verify.unit.test.js。测试通过 mocknode:child_process的spawn构造含两个 image set一个含 1 个实例、一个含 2 个实例的元数据状态断言spawn被调用3次对应 3 个 SOP 实例每次调用均以./pixel-data-verification/index.js为工具路径并依次传入datastore-123、对应image-set-*、series 与 SOP UID使用{ stdio: inherit }继承标准输入输出。该测试证明了验证工具与上层场景之间的参数契约路径、四个位置参数、stdio 行为是被测试固化的也是集成其他场景时可参考的调用规范。常见问题与注意事项报错Unable to get image frame ID from metadata. Check series and SOP instance UIDs.说明传入的 series/SOP UID 与 ImageSet 元数据不匹配请回查导入作业 manifest 与元数据内容输出CRC32 does NOT match!解码结果与原始像素不一致可能源于图像帧在传输中损坏、解码参数错误或校验和取值位置错误应取PixelDataChecksumFromBaseToFullResolution的最后一个元素忘记 0转换直接比较有符号 CRC32 与无符号Checksum在最高位为 1 时会误判失败运行会产生 AWS 费用涉及 datastore、导入作业与图像帧读取建议遵循最小权限原则并注意 AHI 并非在所有区域可用可参考 health-image-sets README 中的注意事项。总结pixel-data-verification展示了 AHI 像素数据验证特性的标准实现范式以元数据中的PixelDataChecksumFromBaseToFullResolution为可信基准用 HTJ2K 解码还原像素后再以 CRC32 复算比对。它既是可独立运行的 CLI 工具也是 health-image-sets 端到端场景中数据完整性保障的关键一环为医学影像应用的数据可信校验提供了开箱即用的参考实现。赞分享示例工程教程后端【免费下载链接】aws-doc-sdk-examplesWelcome to the AWS Code Examples Repository. This repo contains code examples used in the AWS documentation, AWS SDK Developer Guides, and more. For more information, see the Readme.md file below.项目地址https://gitcode.com/gh_mirrors/aw/aws-doc-sdk-examples点击查看免费下载相关推荐使用 AWS SDK for C 导入 HealthImaging 影像集并下载校验图像帧imaging_set_and_frames_workflow 实战指南使用 AWS SDK for C 导入 HealthImaging 影像集并下载校验图像帧imaging_set_and_frames_workflow示例工程教程后端GPX Studio如何在浏览器中免费编辑GPS轨迹文件GPX Studio如何在浏览器中免费编辑GPS轨迹文件 你是否曾经遇到过这样的困扰手机或运动手表记录的GPS轨迹数据需要编辑整理却发现专业软件要么价格示例工程教程后端AWS SDK for Java v2校验和验证数据传输完整性保障AWS SDK for Java v2校验和验证数据传输完整性保障 在分布式系统和大规模数据传输场景中数据完整性Data Integrity是至关重要的后端上一篇终极指南如何一键解锁Cursor中的Claude 4.5和GPT-5高级AI模型下一篇Tailor配置文件详解打造符合团队规范的Swift代码检查方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考