【免费下载链接】lightcraftAn open-source, clean-room reimplementation of Adobe Lightroom in pure Rust.项目地址https://gitcode.com/gh_mirrors/li/lightcraft点击查看免费下载LightCraft一个用纯 Rust 从零实现的 Lightroom 替代品除了桌面端和 CLI还提供通过 WebAssembly 在浏览器中运行的网页版。本文基于仓库中的 packaging/web/README.md完整讲清lightcraft-web-version.zip发布包的内部构成、托管一个 WASM 站点必须满足的服务器配置MIME 类型、压缩、缓存、HTTPS、隔离头、iframe 嵌入的权限要求与 URL 选项并结合 packaging/web/package.sh、xtask/src/web.rs 与 apps/lightcraft-web/index.html 的源码说明这些部署要求背后对应的构建与运行细节。读完本文你可以把 LightCraft 网页版部署到任意静态文件服务器或 CDN并正确地在自己的页面中嵌入它。实验性提示原文档原样保留浏览器版本把图库目录和导入的照片保存在站点自身的浏览器存储中。浏览器可能会清空该存储站点数据被清除、隐私窗口、未授予持久存储配额时的存储压力。应提醒用户把原始照片保存在别处并使用File ▸ Back Up Library…做备份。更多细节见 docs/web.md。发布包的构成lightcraft-web-version.zip来自 GitHub Release或由 packaging/web/package.sh 生成内是一个自包含的静态站点目录lightcraft-web-version/文件构成如下文件说明index.html页面本体全部通过相对 URL 加载资源lightcraft_web.jswasm-bindgen 生成的胶水代码ES modulelightcraft_web_bg.wasm应用本体约 13 MBbrotli 压缩后约 3 MBworker.js启动渲染 worker 的入口每个 worker 运行同一个 wasm 模块*.gz、*.br上述文件的预压缩副本可选提供给服务器直接下发_headers、.htaccess面向 Netlify/Cloudflare Pages 与 Apache 的示例头规则整个包没有服务端代码——把目录内容上传到任何能托管静态文件的地方即可。从打包脚本 packaging/web/package.sh 可以看到这个包是如何组装的L14-L37默认先执行cargo xtask web构建可用--skip-build跳过产物位于$CARGO_TARGET_DIR/web有一项硬性校验grep -Eq (src|href)/[^/]若命中即报错退出——index.html中不允许出现根绝对路径 URL否则站点放到子路径下就会挂掉。这就是下文“任意路径可用”的保证脚本把_headers、.htaccess复制进包内并把README.md本身改名为HOSTING.md随包分发再连同copy_docs复制的文档一起zip -9压缩输出。任意路径都能跑index.html里所有 URL 都是相对的见 apps/lightcraft-web/index.html 第 25、28 行import ... from ./lightcraft_web.js与fetch(./lightcraft_web_bg.wasm)所以站点既能跑在域名根https://example.com/也能跑在前缀路径下https://example.com/tools/lightcraft/或者直接从 CDN 桶里出。这也是打包脚本要拒绝根绝对 URL 的原因。服务器必配项MIME 类型必须以application/wasm提供.wasm。浏览器在其他类型下拒绝流式编译streaming compilation应用会加载得很慢甚至完全加载不出来.js应作为text/javascript提供。大多数托管平台已经这样配置。对 nginx确认mime.types里有application/wasm wasm;。在开发服务器 xtask/src/web.rs 的mime()函数中可以印证这一映射wasm → application/wasm、js → text/javascript; charsetutf-8、html → text/html; charsetutf-8并有单元测试 L240-L245 锁定了这些值。压缩对.wasm、.js、.html开启 gzip 或 Brotli或者直接提供预压缩的.br/.gz文件并附带Content-Encodingnginx 用brotli_static/gzip_static。这能把下载量从约 13 MB 降到约 3–5 MB。这些预压缩文件由构建时生成xtask/src/web.rs 在 release 构建时对 4 个 bundle 文件生成 gzip-9与 brotliquality 11, lgwin 24副本并打印尺寸表--dev构建则跳过避免拖慢编辑循环。缓存文件名在各版本之间不变所以不要把它们标记为immutable——否则升级后浏览器会继续用旧的 wasm 模块或者拿旧胶水代码配新模块。应对index.html、.js、.wasm发送Cache-Control: no-cache配合 ETag / Last-Modified 做再验证示例_headers与.htaccess正是这么做的。Apache 示例的具体写法是packaging/web/.htaccessAddType application/wasm .wasm AddType text/javascript .js IfModule mod_deflate.c AddOutputFilterByType DEFLATE application/wasm text/javascript text/html /IfModule IfModule mod_headers.c FilesMatch \.(wasm|js|html)$ Header set Cache-Control no-cache /FilesMatch /IfModule其中mod_mime是必需的mod_deflate和mod_headers可选。Netlify / Cloudflare Pages 对应的_headers则对全站发送X-Content-Type-Options: nosniff与Cache-Control: no-cache并对/*.wasm显式声明Content-Type: application/wasm。HTTPS图库存储OPFS、模块 worker 与剪贴板都需要安全上下文https://或测试用的http://localhost。应用无法从file://打开。隔离头是可选的。当前构建不使用SharedArrayBuffer因此不需要Cross-Origin-Opener-Policy/Cross-Origin-Embedder-Policy未来的 wasm-threads 构建会需要cargo xtask web --serve开发服务器已经在发送它们。如果站点发送了COEP: require-corp那么应用文件还需要发送Cross-Origin-Resource-Policy: same-origin文件放在 CDN 上时用cross-origin。开发服务器发送的隔离头定义在 xtask/src/web.rspub const ISOLATION_HEADERS: [(str, str); 3] [ (Cross-Origin-Opener-Policy, same-origin), (Cross-Origin-Embedder-Policy, require-corp), (Cross-Origin-Resource-Policy, same-origin), ];nginx 示例配置摘自原文档可直接套用location /lightcraft/ { types { application/wasm wasm; text/javascript js; text/html html; } gzip_static on; # serves the .gz copies # brotli_static on; # with ngx_brotli: serves the .br copies add_header Cache-Control no-cache; }本地测试在解压后的目录里执行python3 -m http.server 8765然后打开http://localhost:8765/。仓库自带的开发服务器则更省事cargo xtask web --serve构建后在http://127.0.0.1:8080/提供可用--serve 9000换端口并按浏览器Accept-Encoding协商下发预压缩副本——协商逻辑见 xtask/src/web.rs 的negotiate()优先 brotli、回退 gzip并有 单元测试 覆盖各种Accept-Encoding组合。用户数据存在哪里一切数据都保存在浏览器里按站点源scheme host port隔离目录与偏好存放在library/下导入的照片在originals/下缩略图在thumbs/下使用 Origin Private File SystemOPFSOPFS 不可写时回退到 IndexedDB。没有任何东西会上传到你的服务器。把应用搬到另一个源等于在那边从零开始一个空图库用户通过File ▸ Back Up Library…和File ▸ Restore Library from Backup…携带自己的图库迁移。同一时间只能有一个标签页打开该图库第二个标签页会显示提示而不是加载副本。这一布局在源码中有直接对应apps/lightcraft-web/src/files.rs 定义了库的小文件集合LIBRARY_FILEScatalog.snap、catalog.log、presets.json、view.json、prefs.json、ui.json并保证快照按修改顺序原子替换docs/web.md 进一步说明library/里复用了与桌面端相同的崩溃安全日志lightcraft-catalogoriginals/content hash存放导入照片字节thumbs/沿用桌面端的 2 GB 缩略图预算。在页面中嵌入iframe示例嵌入代码iframe srchttps://example.com/lightcraft/ titleLightCraft image editor stylewidth: 100%; height: 720px; border: 0; allowfullscreen; clipboard-read; clipboard-write allowfullscreen /iframe注意事项应用会自动填满 iframe 并跟随其尺寸变化所以要调整的是 iframe 的大小而不是应用。像任何嵌入应用一样用户点进 iframe 之后键盘快捷键才会进入 iframe。跨源嵌入可以工作但对第三方存储做分区或封锁的浏览器可能给被嵌入应用单独或临时的存储其图库将与应用自身站点的不同或不会跨访问保留。沙箱 iframe至少需要sandboxallow-scripts allow-same-origin allow-downloads allow-popups allow-modals。缺allow-same-origin就没有存储缺allow-downloads会挡住 Export 与 Back Up Library浏览器下载缺allow-modals则确认对话框恢复、?reset无法显示会被当作“否”处理。不要发送X-Frame-Options: DENY也不要发送把嵌入页面排除在外的frame-ancestorsCSP。渲染器与 URL 选项LightCraft 用 WebGL2eframe 的glow后端绘制 UI照片渲染在 CPU 的 Web Workers 中进行。没有 WebGL2 的浏览器会看到一条提示而不是应用本体。渲染 worker 的机制值得注意apps/lightcraft-web/index.html 用WebAssembly.compileStreaming在主线程编译一次模块并挂到globalThis.lightcraftModule然后把编译好的WebAssembly.Module传给 worker.js后者对同一模块再init出一个独立实例执行worker_main。渲染任务以 JSON 形式跨越线程边界照片来源、develop 设置、请求worker 自己从存储读原始文件或缓存缩略图、渲染后把 RGBA 字节 transfer 回主线程。这个设计不需要 wasm threads 或SharedArrayBuffer因此上文那组隔离头在当前版本是可选的。若 worker 无法启动渲染会回退到主线程对应?workers0。URL 选项同样可以放在 iframe 的src上选项效果?workersN渲染 worker 数量默认核心数 − 1最多 4?workers0在主线程渲染?storeidb图库存到 IndexedDB 而不是 OPFS?storememory什么都不存一次性会话?reset删除本浏览器里存储的图库会先询问确认这些选项的解析在 apps/lightcraft-web/src/web.rs 的UrlOptions结构体中workers、storeidb/memory以及reset标志?reset触发后会弹出确认“将删除本浏览器存储的 LightCraft 图库包括所有导入照片”确认后才清空存储。?storememory下没有持久后端备份/恢复命令会直接报nothing is stored in this browser session。延伸阅读构建、运行与包体积含wasm-bindgen版本锁定、wasm-opt可选优化、webCargo profile 的 opt-level 组合、字体嵌入与 Cloudflare 25 MiB 限制docs/web.md打包脚本与开发服务器实现packaging/web/package.sh、xtask/src/web.rs页面与 worker 的 JS 侧apps/lightcraft-web/index.html、apps/lightcraft-web/worker.js需要说明的适用前提本文所有部署细节以当前仓库README 中标注为实验性功能为准lightcraft-web-version.zip中的_headers/.htaccess只是示例配置其他托管平台请自行设置等价的头隔离头COOP/COEP/CORP在“未来 wasm-threads 构建”出现前保持可选状态。赞分享【免费下载链接】lightcraftAn open-source, clean-room reimplementation of Adobe Lightroom in pure Rust.项目地址https://gitcode.com/gh_mirrors/li/lightcraft点击查看免费下载相关推荐laf静态网站性能优化缓存策略与资源压缩laf静态网站性能优化缓存策略与资源压缩 在当今互联网时代网站性能直接影响用户体验和业务转化。作为基于云原生架构的Serverless开发平台laf不仅提后端Serverless前端云原生如何部署WhirlwindTourOfPython网站Pelican静态站点生成实战如何部署WhirlwindTourOfPython网站Pelican静态站点生成实战 WhirlwindTourOfPython是一个基于Jupyter Nopretty-error让Node.js错误日志告别混乱的终极美化工具pretty error让Node.js错误日志告别混乱的终极美化工具 作为Node.js开发者你是否曾经被密密麻麻的错误堆栈信息搞得头晕脑胀 prett上一篇Cursor 免费试用重置完整指南3步解除试用请求限制下一篇Autoformer未来展望从Nature Machine Intelligence到下一代时间序列AI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LightCraft 网页版部署实战：WASM 静态站点的 MIME、压缩、缓存与嵌入配置
【免费下载链接】lightcraftAn open-source, clean-room reimplementation of Adobe Lightroom in pure Rust.项目地址https://gitcode.com/gh_mirrors/li/lightcraft点击查看免费下载LightCraft一个用纯 Rust 从零实现的 Lightroom 替代品除了桌面端和 CLI还提供通过 WebAssembly 在浏览器中运行的网页版。本文基于仓库中的 packaging/web/README.md完整讲清lightcraft-web-version.zip发布包的内部构成、托管一个 WASM 站点必须满足的服务器配置MIME 类型、压缩、缓存、HTTPS、隔离头、iframe 嵌入的权限要求与 URL 选项并结合 packaging/web/package.sh、xtask/src/web.rs 与 apps/lightcraft-web/index.html 的源码说明这些部署要求背后对应的构建与运行细节。读完本文你可以把 LightCraft 网页版部署到任意静态文件服务器或 CDN并正确地在自己的页面中嵌入它。实验性提示原文档原样保留浏览器版本把图库目录和导入的照片保存在站点自身的浏览器存储中。浏览器可能会清空该存储站点数据被清除、隐私窗口、未授予持久存储配额时的存储压力。应提醒用户把原始照片保存在别处并使用File ▸ Back Up Library…做备份。更多细节见 docs/web.md。发布包的构成lightcraft-web-version.zip来自 GitHub Release或由 packaging/web/package.sh 生成内是一个自包含的静态站点目录lightcraft-web-version/文件构成如下文件说明index.html页面本体全部通过相对 URL 加载资源lightcraft_web.jswasm-bindgen 生成的胶水代码ES modulelightcraft_web_bg.wasm应用本体约 13 MBbrotli 压缩后约 3 MBworker.js启动渲染 worker 的入口每个 worker 运行同一个 wasm 模块*.gz、*.br上述文件的预压缩副本可选提供给服务器直接下发_headers、.htaccess面向 Netlify/Cloudflare Pages 与 Apache 的示例头规则整个包没有服务端代码——把目录内容上传到任何能托管静态文件的地方即可。从打包脚本 packaging/web/package.sh 可以看到这个包是如何组装的L14-L37默认先执行cargo xtask web构建可用--skip-build跳过产物位于$CARGO_TARGET_DIR/web有一项硬性校验grep -Eq (src|href)/[^/]若命中即报错退出——index.html中不允许出现根绝对路径 URL否则站点放到子路径下就会挂掉。这就是下文“任意路径可用”的保证脚本把_headers、.htaccess复制进包内并把README.md本身改名为HOSTING.md随包分发再连同copy_docs复制的文档一起zip -9压缩输出。任意路径都能跑index.html里所有 URL 都是相对的见 apps/lightcraft-web/index.html 第 25、28 行import ... from ./lightcraft_web.js与fetch(./lightcraft_web_bg.wasm)所以站点既能跑在域名根https://example.com/也能跑在前缀路径下https://example.com/tools/lightcraft/或者直接从 CDN 桶里出。这也是打包脚本要拒绝根绝对 URL 的原因。服务器必配项MIME 类型必须以application/wasm提供.wasm。浏览器在其他类型下拒绝流式编译streaming compilation应用会加载得很慢甚至完全加载不出来.js应作为text/javascript提供。大多数托管平台已经这样配置。对 nginx确认mime.types里有application/wasm wasm;。在开发服务器 xtask/src/web.rs 的mime()函数中可以印证这一映射wasm → application/wasm、js → text/javascript; charsetutf-8、html → text/html; charsetutf-8并有单元测试 L240-L245 锁定了这些值。压缩对.wasm、.js、.html开启 gzip 或 Brotli或者直接提供预压缩的.br/.gz文件并附带Content-Encodingnginx 用brotli_static/gzip_static。这能把下载量从约 13 MB 降到约 3–5 MB。这些预压缩文件由构建时生成xtask/src/web.rs 在 release 构建时对 4 个 bundle 文件生成 gzip-9与 brotliquality 11, lgwin 24副本并打印尺寸表--dev构建则跳过避免拖慢编辑循环。缓存文件名在各版本之间不变所以不要把它们标记为immutable——否则升级后浏览器会继续用旧的 wasm 模块或者拿旧胶水代码配新模块。应对index.html、.js、.wasm发送Cache-Control: no-cache配合 ETag / Last-Modified 做再验证示例_headers与.htaccess正是这么做的。Apache 示例的具体写法是packaging/web/.htaccessAddType application/wasm .wasm AddType text/javascript .js IfModule mod_deflate.c AddOutputFilterByType DEFLATE application/wasm text/javascript text/html /IfModule IfModule mod_headers.c FilesMatch \.(wasm|js|html)$ Header set Cache-Control no-cache /FilesMatch /IfModule其中mod_mime是必需的mod_deflate和mod_headers可选。Netlify / Cloudflare Pages 对应的_headers则对全站发送X-Content-Type-Options: nosniff与Cache-Control: no-cache并对/*.wasm显式声明Content-Type: application/wasm。HTTPS图库存储OPFS、模块 worker 与剪贴板都需要安全上下文https://或测试用的http://localhost。应用无法从file://打开。隔离头是可选的。当前构建不使用SharedArrayBuffer因此不需要Cross-Origin-Opener-Policy/Cross-Origin-Embedder-Policy未来的 wasm-threads 构建会需要cargo xtask web --serve开发服务器已经在发送它们。如果站点发送了COEP: require-corp那么应用文件还需要发送Cross-Origin-Resource-Policy: same-origin文件放在 CDN 上时用cross-origin。开发服务器发送的隔离头定义在 xtask/src/web.rspub const ISOLATION_HEADERS: [(str, str); 3] [ (Cross-Origin-Opener-Policy, same-origin), (Cross-Origin-Embedder-Policy, require-corp), (Cross-Origin-Resource-Policy, same-origin), ];nginx 示例配置摘自原文档可直接套用location /lightcraft/ { types { application/wasm wasm; text/javascript js; text/html html; } gzip_static on; # serves the .gz copies # brotli_static on; # with ngx_brotli: serves the .br copies add_header Cache-Control no-cache; }本地测试在解压后的目录里执行python3 -m http.server 8765然后打开http://localhost:8765/。仓库自带的开发服务器则更省事cargo xtask web --serve构建后在http://127.0.0.1:8080/提供可用--serve 9000换端口并按浏览器Accept-Encoding协商下发预压缩副本——协商逻辑见 xtask/src/web.rs 的negotiate()优先 brotli、回退 gzip并有 单元测试 覆盖各种Accept-Encoding组合。用户数据存在哪里一切数据都保存在浏览器里按站点源scheme host port隔离目录与偏好存放在library/下导入的照片在originals/下缩略图在thumbs/下使用 Origin Private File SystemOPFSOPFS 不可写时回退到 IndexedDB。没有任何东西会上传到你的服务器。把应用搬到另一个源等于在那边从零开始一个空图库用户通过File ▸ Back Up Library…和File ▸ Restore Library from Backup…携带自己的图库迁移。同一时间只能有一个标签页打开该图库第二个标签页会显示提示而不是加载副本。这一布局在源码中有直接对应apps/lightcraft-web/src/files.rs 定义了库的小文件集合LIBRARY_FILEScatalog.snap、catalog.log、presets.json、view.json、prefs.json、ui.json并保证快照按修改顺序原子替换docs/web.md 进一步说明library/里复用了与桌面端相同的崩溃安全日志lightcraft-catalogoriginals/content hash存放导入照片字节thumbs/沿用桌面端的 2 GB 缩略图预算。在页面中嵌入iframe示例嵌入代码iframe srchttps://example.com/lightcraft/ titleLightCraft image editor stylewidth: 100%; height: 720px; border: 0; allowfullscreen; clipboard-read; clipboard-write allowfullscreen /iframe注意事项应用会自动填满 iframe 并跟随其尺寸变化所以要调整的是 iframe 的大小而不是应用。像任何嵌入应用一样用户点进 iframe 之后键盘快捷键才会进入 iframe。跨源嵌入可以工作但对第三方存储做分区或封锁的浏览器可能给被嵌入应用单独或临时的存储其图库将与应用自身站点的不同或不会跨访问保留。沙箱 iframe至少需要sandboxallow-scripts allow-same-origin allow-downloads allow-popups allow-modals。缺allow-same-origin就没有存储缺allow-downloads会挡住 Export 与 Back Up Library浏览器下载缺allow-modals则确认对话框恢复、?reset无法显示会被当作“否”处理。不要发送X-Frame-Options: DENY也不要发送把嵌入页面排除在外的frame-ancestorsCSP。渲染器与 URL 选项LightCraft 用 WebGL2eframe 的glow后端绘制 UI照片渲染在 CPU 的 Web Workers 中进行。没有 WebGL2 的浏览器会看到一条提示而不是应用本体。渲染 worker 的机制值得注意apps/lightcraft-web/index.html 用WebAssembly.compileStreaming在主线程编译一次模块并挂到globalThis.lightcraftModule然后把编译好的WebAssembly.Module传给 worker.js后者对同一模块再init出一个独立实例执行worker_main。渲染任务以 JSON 形式跨越线程边界照片来源、develop 设置、请求worker 自己从存储读原始文件或缓存缩略图、渲染后把 RGBA 字节 transfer 回主线程。这个设计不需要 wasm threads 或SharedArrayBuffer因此上文那组隔离头在当前版本是可选的。若 worker 无法启动渲染会回退到主线程对应?workers0。URL 选项同样可以放在 iframe 的src上选项效果?workersN渲染 worker 数量默认核心数 − 1最多 4?workers0在主线程渲染?storeidb图库存到 IndexedDB 而不是 OPFS?storememory什么都不存一次性会话?reset删除本浏览器里存储的图库会先询问确认这些选项的解析在 apps/lightcraft-web/src/web.rs 的UrlOptions结构体中workers、storeidb/memory以及reset标志?reset触发后会弹出确认“将删除本浏览器存储的 LightCraft 图库包括所有导入照片”确认后才清空存储。?storememory下没有持久后端备份/恢复命令会直接报nothing is stored in this browser session。延伸阅读构建、运行与包体积含wasm-bindgen版本锁定、wasm-opt可选优化、webCargo profile 的 opt-level 组合、字体嵌入与 Cloudflare 25 MiB 限制docs/web.md打包脚本与开发服务器实现packaging/web/package.sh、xtask/src/web.rs页面与 worker 的 JS 侧apps/lightcraft-web/index.html、apps/lightcraft-web/worker.js需要说明的适用前提本文所有部署细节以当前仓库README 中标注为实验性功能为准lightcraft-web-version.zip中的_headers/.htaccess只是示例配置其他托管平台请自行设置等价的头隔离头COOP/COEP/CORP在“未来 wasm-threads 构建”出现前保持可选状态。赞分享【免费下载链接】lightcraftAn open-source, clean-room reimplementation of Adobe Lightroom in pure Rust.项目地址https://gitcode.com/gh_mirrors/li/lightcraft点击查看免费下载相关推荐laf静态网站性能优化缓存策略与资源压缩laf静态网站性能优化缓存策略与资源压缩 在当今互联网时代网站性能直接影响用户体验和业务转化。作为基于云原生架构的Serverless开发平台laf不仅提后端Serverless前端云原生如何部署WhirlwindTourOfPython网站Pelican静态站点生成实战如何部署WhirlwindTourOfPython网站Pelican静态站点生成实战 WhirlwindTourOfPython是一个基于Jupyter Nopretty-error让Node.js错误日志告别混乱的终极美化工具pretty error让Node.js错误日志告别混乱的终极美化工具 作为Node.js开发者你是否曾经被密密麻麻的错误堆栈信息搞得头晕脑胀 prett上一篇Cursor 免费试用重置完整指南3步解除试用请求限制下一篇Autoformer未来展望从Nature Machine Intelligence到下一代时间序列AI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考