When to Use
Use when the main artifact is an image file or visual asset, especially when format choice, resizing, cropping, compression, metadata, transparency, color profile, responsive delivery, social specs, marketplace requirements, or print readiness matter.
If the task is destination-specific, load the matching file before deciding:
- -
web.md for responsive delivery, LCP/CLS, srcset, lazy loading, SVG, and modern web formats. - INLINECODE2 for platform dimensions, safe zones, and feed/story/banner exports.
- INLINECODE3 for marketplace product-image rules, white backgrounds, zoom, and catalog consistency.
- INLINECODE4 for RAW, ICC profiles, print export, EXIF, and non-destructive editing.
- INLINECODE5 for logos, icons, favicons, app icons, SVG consistency, and small-size legibility.
- INLINECODE6 for UI captures, documentation images, annotations, redaction, and marketing/device frames.
- INLINECODE7 for alt text, decorative vs informative images, text in images, charts, and contrast-aware image delivery.
- INLINECODE8 when the user needs concrete ImageMagick or Pillow examples.
Keep the main workflow in this file, then pull in the specialized file for the exact delivery context instead of guessing from generic image advice.
Quick Reference
| Situation | Load | Why |
|---|
| Web optimization, responsive images, lazy loading, SVG | INLINECODE9 | Avoid CLS/LCP mistakes, oversized assets, and wrong web formats |
| Color profiles, metadata, RAW, print, non-destructive workflows |
photography.md | Protect color intent, print readiness, and master-file quality |
| Social platform dimensions, safe zones, banners, previews |
social.md | Prevent unsafe crops, unreadable text, and uploader recompression surprises |
| Product photos, marketplace standards, catalog consistency |
ecommerce.md | Preserve zoom detail, white-background compliance, and catalog consistency |
| Logos, favicons, SVGs, app icons, icon sets |
branding.md | Protect small-size legibility, SVG consistency, and multi-format icon delivery |
| UI screenshots, docs captures, redaction, annotations |
screenshots.md | Avoid blurry captures, privacy leaks, and misleading before/after comparisons |
| Alt text, text-in-image risk, charts, decorative vs informative images |
accessibility.md | Keep image work usable and compliant, not only visually correct |
| ImageMagick and Pillow commands |
commands.md | Use concrete commands once the export decision is already clear |
Fast Workflow
- 1. Identify the asset type: photo, screenshot, UI capture, logo, diagram, social card, product image, or print source.
- Identify the destination: web page, social upload, marketplace gallery, print handoff, internal archive, or further editing pipeline.
- Decide whether the source should remain vector, layered, or RAW instead of being flattened too early.
- Inspect the file before editing: dimensions, aspect ratio, orientation, transparency, color profile, metadata, and current compression damage.
- Load the destination-specific file if the job is web, social, ecommerce, photography/print, branding, screenshots, accessibility, or command-heavy.
- Make the minimum safe transformation set: crop, resize, convert, compress, strip or preserve metadata, and export.
- Validate the exported result in the destination context, not only in the editor.
Asset-Type Defaults
| Asset type | Usually best starting point | Watch out for |
|---|
| Photo | WebP or AVIF for web, JPEG fallback, layered/RAW master for editing | Color profile shifts, overcompression, platform recompression |
| Product photo |
JPEG or WebP for delivery, high-res clean master | White background, edge cleanup, zoom detail, consistency |
| Screenshot or UI capture | PNG or lossless WebP | JPEG blur, privacy leaks, unreadable text |
| Logo or simple icon | SVG master, PNG fallbacks only when needed | Tiny details, unsupported SVG pipelines, dark/light contrast |
| Social/OG card | PNG or high-quality JPEG sized for preview | Unsafe crop, tiny text, double compression |
| Diagram or chart | SVG when possible, PNG when fixed raster needed | Thin lines, low contrast, missing explanatory text |
| Print image | TIFF or high-quality JPEG with correct profile | Wrong profile, wrong physical size, no bleed |
Core Rules
1. Choose the workflow by destination, not by habit
- - Web delivery, social export, ecommerce prep, print output, and archive preservation are different image jobs.
- A screenshot, product photo, logo, infographic, and print asset should not default to the same format or compression strategy.
- Image generation is a different workflow from image processing; treat generated assets as inputs that still need inspection and export discipline.
- If the destination is specialized, read the matching file before locking format, crop, quality, or metadata decisions.
- If the file will be edited again later, preserve a master-grade source before making lightweight delivery exports.
2. Pick formats by content, not by trend
- - Photos usually want AVIF or WebP for modern web delivery, with JPEG fallback when compatibility matters.
- Screenshots, UI captures, diagrams, and text-heavy graphics often need PNG or lossless WebP to avoid blurry edges.
- Logos, icons, and simple illustrations should stay vector (
.svg) when the target supports it. - Transparency changes the decision: JPEG drops alpha, while PNG, WebP, and AVIF can preserve it.
- Animated GIF is rarely the best output; animated WebP, MP4, or WebM are usually smaller and cleaner.
- TIFF, PSD, layered formats, and RAW files are working formats or masters, not normal delivery outputs.
- If a platform re-encodes uploads aggressively, optimize for how that platform recompresses rather than for ideal local viewing.
- Screenshots, diagrams, and charts with sharp edges often benefit from lossless output even when photos do not.
3. Preserve color, transparency, and detail deliberately
- - Web assets should usually end in sRGB unless the destination explicitly needs something else.
- Stripping or changing ICC profiles can shift colors even when the pixels themselves did not change.
- Transparent assets need alpha-safe formats and validation against both light and dark backgrounds.
- Repeated lossy saves compound damage, so keep a clean source and minimize recompression loops.
- Upscaling, denoising, sharpening, and background removal should be treated as visible edits, not harmless export steps.
4. Resize, crop, and compress in the right order
- - Decide aspect ratio first, crop second, resize third, and compress last.
- Do not upscale by default; extra pixels do not create missing detail.
- Retina or HiDPI exports should be intentional, not automatic overkill.
- As a starting point, 2x is the normal Retina export and 3x should be deliberate, not default.
- Social cards, ecommerce slots, and marketplace galleries often crop aggressively, so protect the real focal area and any critical text.
- A file that fits the pixel spec can still fail if the crop cuts off faces, products, labels, or UI affordances.
- If text is embedded inside the image, validate at the smallest realistic preview size, not only at full resolution.
5. Treat metadata and orientation as real delivery concerns
- - EXIF orientation can make an image look upright in one viewer and rotated in another after export.
- Public web assets usually should strip GPS and unnecessary camera metadata.
- Copyright, author, or provenance metadata may need to be preserved for editorial, legal, or archive use.
- Metadata decisions are part of the workflow, not an afterthought.
- Preserve filenames and output naming conventions when downstream systems map assets by exact names or SKU patterns.
- Do not strip metadata blindly if the workflow depends on authoring info, rights data, timestamps, or orientation.
6. Use practical budgets and delivery defaults
- - For web work, use budgets as a forcing function, not as decoration.
- A useful default starting point is: hero image under 200 KB, content image under 100 KB, thumbnail under 30 KB, raster icon under 5 KB.
- Reserve layout space with explicit dimensions or aspect ratio when the image ships on the web.
- Do not lazy-load the primary hero or likely LCP image.
- A file that "looks fine locally" is not finished if it breaks CLS, LCP, or responsive delivery in the real page.
- A small file is not automatically good if detail, text legibility, product edges, or gradients collapse.
- If a platform will recompress the image anyway, leave enough headroom that the second compression does not destroy the result.
7. Validate against the actual destination
- - Platform specs are not interchangeable: web hero, social preview, app store art, marketplace gallery, and print ad all have different constraints.
- Ecommerce images may need background consistency, edge cleanliness, square-safe crops, and zoom-friendly detail.
- Social images need safe composition because feeds crop previews differently across platforms.
- Print assets care about physical size, bleed, and color handling in ways web exports do not.
- If the asset ships on the web, remember the surrounding delivery too: width, height, alt text, and whether the image should carry text at all.
- If the asset will be uploaded to a third-party platform, check the post-upload result because many pipelines resize, strip profiles, flatten metadata, or recompress again.
- If the image carries meaning, validate its accessibility too: alt text strategy, text legibility, decorative vs informative role, and whether the meaning should have stayed in HTML or surrounding copy.
8. Batch safely and keep the original reversible
- - Work from originals or clean masters, not from already-optimized outputs.
- Batch processing should apply consistent rules, but still spot-check representative files before touching the whole set.
- One wrong crop preset, color conversion, or lossy export can damage an entire batch quickly.
- Keep per-destination exports separated from masters so the next edit does not accidentally start from a degraded derivative.
Specialized Cases Worth Loading
- - Load
branding.md when the asset is a logo, app icon, favicon, social avatar, badge, or reusable icon set. - Load
screenshots.md when the asset is a UI capture, bug report image, tutorial screenshot, release-note image, or device-framed marketing visual. - Load
accessibility.md when the image needs alt text, contains embedded text, carries chart/diagram meaning, or may be decorative instead of informative.
What Good Looks Like
- - The chosen format matches the content and the destination, not a blanket preference.
- The exported file keeps the right focal area, text legibility, transparency, and color intent.
- Metadata is preserved or stripped deliberately.
- The file size is efficient without obvious visual damage.
- The asset still works after the actual upload, embed, or platform preview step.
- The agent has not flattened a vector, layered, or RAW source earlier than necessary.
- The asset is still understandable in its real use context, not just visually attractive in isolation.
Common Traps
- - Saving transparent images as JPEG and silently losing the alpha channel.
- Using JPEG for screenshots or UI captures and turning sharp text into mush.
- Shipping a file that matches the requested dimensions but has the wrong aspect ratio or unsafe crop.
- Recompressing the same JPEG multiple times and blaming the tool instead of the workflow.
- Stripping metadata and accidentally breaking orientation, licensing context, or provenance needs.
- Forgetting sRGB and wondering why colors shift between editing tools, browsers, and marketplaces.
- Using SVG where the target platform strips it, rasterizes it badly, or blocks it entirely.
- Assuming AVIF or WebP is safe everywhere when some platforms, email clients, or upload pipelines still normalize back to JPEG or PNG.
- Embedding critical text into images where HTML or native UI text should have carried the meaning.
- Hitting the file-size budget but missing visual quality because the image was resized, cropped, or sharpened badly.
- Rasterizing a logo too early and then fighting blurry exports forever.
- Shipping a screenshot with secrets, personal data, or unstable timestamps still visible.
- Treating alt text, captions, or chart summaries as someone else's problem after the pixels look good.
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
image-edit — Masking, cleanup, inpainting, and targeted visual edits. - INLINECODE23 — AI image generation and editing across current model providers.
- INLINECODE24 — Capture, color, and print-oriented photo workflows.
- INLINECODE25 — Vector graphics workflows when raster files are the wrong output.
- INLINECODE26 — Marketplace and product-listing requirements that often constrain image delivery.
Feedback
- - If useful: INLINECODE27
- Stay updated: INLINECODE28
何时使用
当主要产出物为图像文件或视觉素材时使用,尤其在格式选择、尺寸调整、裁剪、压缩、元数据、透明度、色彩配置文件、响应式交付、社交媒体规格、市场平台要求或打印就绪性等方面需要考量时。
如果任务有特定交付场景,在做出决定前先加载对应的文件:
- - web.md:用于响应式交付、LCP/CLS、srcset、懒加载、SVG及现代网页格式
- social.md:用于平台尺寸、安全区域、信息流/故事/横幅导出
- ecommerce.md:用于电商平台产品图片规则、白底、缩放和目录一致性
- photography.md:用于RAW格式、ICC配置文件、打印导出、EXIF和非破坏性编辑
- branding.md:用于Logo、图标、网站图标、应用图标、SVG一致性和小尺寸可读性
- screenshots.md:用于UI截图、文档图片、标注、脱敏处理及营销/设备框架
- accessibility.md:用于替代文本、装饰性与信息性图片、图片中的文字、图表及对比度感知的图像交付
- commands.md:当用户需要具体的ImageMagick或Pillow示例时
将主要工作流程保留在此文件中,然后根据具体的交付场景调用对应的专业文件,而非依赖通用图片建议进行猜测。
快速参考
| 场景 | 加载文件 | 原因 |
|---|
| 网页优化、响应式图片、懒加载、SVG | web.md | 避免CLS/LCP错误、过大的资源文件和错误的网页格式 |
| 色彩配置文件、元数据、RAW、打印、非破坏性工作流 |
photography.md | 保护色彩意图、打印就绪性和母版文件质量 |
| 社交媒体平台尺寸、安全区域、横幅、预览 | social.md | 防止不安全裁剪、文字不可读及上传器重新压缩带来的意外 |
| 产品图片、电商平台标准、目录一致性 | ecommerce.md | 保持缩放细节、白底合规性和目录一致性 |
| Logo、网站图标、SVG、应用图标、图标集 | branding.md | 保护小尺寸可读性、SVG一致性和多格式图标交付 |
| UI截图、文档抓图、脱敏处理、标注 | screenshots.md | 避免模糊截图、隐私泄露和误导性的前后对比 |
| 替代文本、图片内文字风险、图表、装饰性与信息性图片 | accessibility.md | 确保图片工作的可用性和合规性,而不仅是视觉正确 |
| ImageMagick和Pillow命令 | commands.md | 在导出决策明确后使用具体命令 |
快速工作流程
- 1. 确定素材类型:照片、截图、UI抓图、Logo、图表、社交卡片、产品图片或打印源文件
- 确定交付场景:网页、社交平台上传、电商图库、打印交付、内部存档或后续编辑流程
- 判断源文件是否应保持矢量、分层或RAW格式,而非过早扁平化
- 编辑前检查文件:尺寸、宽高比、方向、透明度、色彩配置文件、元数据和当前压缩损伤
- 如果任务涉及网页、社交、电商、摄影/打印、品牌、截图、无障碍或大量命令,加载对应场景文件
- 执行最小安全变换集:裁剪、调整大小、转换、压缩、选择性保留或剥离元数据、导出
- 在交付场景中验证导出结果,而不仅是在编辑器中查看
素材类型默认设置
| 素材类型 | 通常最佳起点 | 注意事项 |
|---|
| 照片 | 网页用WebP或AVIF,JPEG作为回退,编辑用分层/RAW母版 | 色彩配置文件偏移、过度压缩、平台二次压缩 |
| 产品图片 |
交付用JPEG或WebP,高分辨率干净母版 | 白底、边缘清理、缩放细节、一致性 |
| 截图或UI抓图 | PNG或无损WebP | JPEG模糊、隐私泄露、文字不可读 |
| Logo或简单图标 | SVG母版,仅在需要时使用PNG回退 | 微小细节、不支持的SVG流程、深色/浅色对比度 |
| 社交/OG卡片 | 按预览尺寸调整的PNG或高质量JPEG | 不安全裁剪、微小文字、双重压缩 |
| 图表或流程图 | 尽可能用SVG,需要固定栅格时用PNG | 细线、低对比度、缺少说明文字 |
| 打印图片 | 带正确配置文件的TIFF或高质量JPEG | 错误配置文件、错误物理尺寸、无出血 |
核心规则
1. 按交付场景选择工作流程,而非按习惯
- - 网页交付、社交导出、电商准备、打印输出和存档保存是不同的图片任务
- 截图、产品图片、Logo、信息图和打印素材不应默认使用相同的格式或压缩策略
- 图片生成是与图片处理不同的工作流程;将生成的素材视为仍需检查和导出规范的输入
- 如果交付场景特殊,在锁定格式、裁剪、质量或元数据决策前,先阅读对应文件
- 如果文件后续还会编辑,在制作轻量级交付导出前,先保留母版级源文件
2. 按内容选择格式,而非按趋势
- - 照片通常适合现代网页交付使用AVIF或WebP,兼容性重要时用JPEG回退
- 截图、UI抓图、图表和文字密集型图形通常需要PNG或无损WebP以避免边缘模糊
- Logo、图标和简单插图在目标支持时应保持矢量格式(.svg)
- 透明度改变决策:JPEG丢弃Alpha通道,而PNG、WebP和AVIF可以保留
- 动画GIF很少是最佳输出;动画WebP、MP4或WebM通常更小更清晰
- TIFF、PSD、分层格式和RAW文件是工作格式或母版,而非常规交付输出
- 如果平台对上传内容进行激进重新编码,应针对该平台的重新压缩方式进行优化,而非追求理想的本地观看效果
- 具有清晰边缘的截图、图表和图表通常受益于无损输出,即使照片不需要
3. 有意识地保留色彩、透明度和细节
- - 网页素材通常应以sRGB为最终色彩空间,除非交付场景明确需要其他配置
- 剥离或更改ICC配置文件可能导致色彩偏移,即使像素本身未改变
- 透明素材需要支持Alpha通道的格式,并在浅色和深色背景上验证
- 重复的有损保存会累积损伤,因此保持干净的源文件并最小化重新压缩循环
- 放大、降噪、锐化和背景移除应被视为可见编辑,而非无害的导出步骤
4. 按正确顺序进行尺寸调整、裁剪和压缩
- - 先确定宽高比,再裁剪,然后调整尺寸,最后压缩
- 默认不要放大;额外像素不会创造缺失的细节
- Retina或HiDPI导出应有明确意图,而非自动过度
- 作为起点,2x是正常的Retina导出,3x应有明确目的,而非默认
- 社交卡片、电商位和电商图库经常进行激进裁剪,因此保护真正的焦点区域和任何关键文字
- 符合像素规格的文件仍可能因裁剪切掉人脸、产品、标签或UI交互元素而失败
- 如果图片内嵌文字,在最小的实际预览尺寸下验证,而非仅在全分辨率下
5. 将元数据和方向视为真正的交付关注点
- - EXIF方向可能导致图片在一个查看器中显示正常,在导出后在另一个查看器中旋转
- 公共网页素材通常应剥离GPS和不必要的相机元数据
- 版权、作者或来源元数据可能需要为编辑、法律或存档用途保留
- 元数据决策是工作流程的一部分,而非事后考虑
- 当下游系统通过精确名称或SKU模式映射素材时,保留文件名和输出命名规范
- 如果工作流程依赖作者信息、权利数据、时间戳或方向,不要盲目剥离元数据
6. 使用实用的预算和交付默认值
- - 对于网页工作,将预算作为强制约束,而非装饰
- 一个有用的默认起点是:主图低于200 KB,内容图低于100 KB,缩略图低于30 KB,栅格图标低于5 KB
- 当图片在网页上交付时,使用明确的尺寸或宽高比预留布局空间
- 不要对主要主图或可能的LCP图片进行懒加载
- 如果文件在真实页面中破坏了CLS、LCP或响应式交付,即使本地看起来很好也不算完成
- 如果细节、文字可读性、产品边缘或渐变崩溃,小文件并不自动等于好文件
- 如果平台无论如何都会重新压缩图片,留出足够的余量,使第二次压缩不会破坏结果
7. 针对实际交付场景进行验证
- - 平台规格不可互换:网页主图、社交预览、应用商店素材、电商图库和印刷广告都有不同的约束
- 电商图片可能需要背景一致性、边缘清洁度