Feature request: Plugin API and External Filter support
功能建议：插件 API 与外部滤镜支持
中文
首先，非常感谢你开发 Compositor，并将它作为开源项目发布。
作为一名长期使用 Photoshop 的设计师，我觉得 Compositor 未来有一个功能可能会越来越重要：
插件 / 外部滤镜扩展架构。
这里并不是希望 Compositor 现在就直接兼容 Photoshop 的 .8bf、CEP 或 UXP 插件。
这些体系都比较复杂，而且与 Adobe 自身的平台高度绑定，未必适合直接移植到 Compositor。
我更关注的是一个更基础的问题：
Compositor 是否可以提供一种开放、稳定的方式，让第三方图像处理工具参与到编辑工作流中？
为什么这个功能很重要
对于很多长期使用 Photoshop 的专业用户来说，迁移到另一个图像编辑器，并不仅仅取决于软件本身是否拥有：
很多人的实际工作流还依赖大量第三方工具，例如：
- 图像增强与锐化工具
- 降噪工具
- 人像修饰工具
- 调色滤镜
- AI 放大工具
- AI 图像生成 / 修复工具
- 专业导入导出工具
- 自定义生产流程工具
即使未来 Compositor 已经覆盖 Photoshop 大部分核心功能，只要某些重要的第三方工具无法进入工作流，部分用户仍然可能不得不保留 Photoshop。
因此，一个开放的扩展系统可能会显著降低迁移成本。
可以考虑分阶段实现
我认为不一定需要一开始就开发完整的 Photoshop 插件兼容层。
也许可以从一个更轻量的方案开始。
1. External Filter / 外部滤镜
例如增加：
Filter
└── External Filter...
可能的工作流程：
当前图层 / 当前选区
↓
临时 PNG / TIFF
↓
外部应用程序
↓
外部程序处理
↓
返回 Compositor
↓
生成新的图层
用户可以指定一个外部应用，Compositor 自动负责临时文件交换。
仅仅这一功能，就可以让很多已经拥有独立版的第三方工具与 Compositor 配合，而不需要马上设计完整的插件 SDK。
2. Native Compositor Plugin API / 原生插件 API
之后可以进一步开放一个较小而稳定的扩展接口，例如：
Compositor Plugin API
├── Filter Plugin
├── Adjustment Plugin
├── Import / Export Plugin
├── Tool Plugin
├── Automation Plugin
└── AI Provider
插件可以获得例如：
- 当前图层像素
- 当前选区
- 蒙版
- 文档尺寸
- 色彩信息
- 图层元数据
然后返回：
- 修改后的像素
- 新图层
- 新蒙版
- 调整结果
- 或结构化编辑操作
AI Provider 也可以属于同一套扩展架构
Compositor 已经开始探索 AI 辅助设计和自动化工作流。
未来如果有统一的扩展接口，也许可以让 AI 图像处理和生成模型使用同样的机制：
Compositor
↓
Provider / Plugin
↓
本地模型 / ComfyUI / 外部服务
↓
生成或处理结果
↓
作为新图层返回 Compositor
这样 Compositor 就不需要绑定某一个特定的 AI 模型或服务商。
用户可以自行选择：
- 本地模型
- ComfyUI
- 云端 API
- 第三方 AI 工具
- 自定义服务
Photoshop 插件兼容可以作为独立的长期课题
直接兼容 Photoshop 的：
可能技术复杂度很高，而且不一定适合作为 Compositor 核心功能。
我认为这可以以后作为一个独立的研究方向，而不是这个建议的主要目标。
更重要的是先建立：
一个属于 Compositor 自己的开放扩展机制。
可能带来的好处
- 降低 Photoshop 用户迁移成本
- 建立 Compositor 自己的第三方生态
- 避免所有功能都必须加入核心程序
- 保持 Compositor 本体轻量
- 允许开源插件和商业插件共存
- 让 AI 集成保持模型和服务商中立
- 支持专业用户建立自己的工作流程
- 让专业滤镜、AI 工具和自动化工具更容易接入
我理解 Compositor 目前仍处于非常快速的发展阶段，插件架构可能并不是近期优先事项。
我主要是希望在项目架构还在快速演进的时候提前提出这个想法。
随着越来越多专业用户开始认真考虑把 Compositor 用在日常工作中，扩展能力可能会逐渐成为一个非常重要的问题。
English
First of all, thank you for building Compositor and releasing it as an open-source project.
As a long-time Photoshop user and professional designer, I think one feature that may become increasingly important for Compositor is some form of:
Plugin / External Filter architecture.
This is not necessarily a request for Compositor to immediately support Photoshop .8bf, CEP, or UXP plugins directly.
Those ecosystems are complex and heavily tied to Adobe's own platform, so direct compatibility may not be the best foundation for Compositor.
The broader question I would like to raise is:
Could Compositor provide an open and stable way for third-party image-processing tools to participate in the editing workflow?
Why this could matter
For many professional Photoshop users, migrating to another image editor is not only about whether the application has:
- Layers
- Masks
- Selections
- Curves
- Text
- Filters
- Adjustment layers
Many real-world workflows also depend on third-party tools such as:
- Image enhancement and sharpening tools
- Denoise applications
- Portrait retouching tools
- Color-grading filters
- AI upscalers
- AI generation / restoration tools
- Specialized import/export tools
- Custom production utilities
Even if Compositor eventually covers most of Photoshop's core functionality, some users may still need to keep Photoshop installed if important third-party tools cannot participate in the workflow.
An open extension system could significantly reduce this migration friction.
Possible incremental approach
I don't think this necessarily needs to begin with a complete Photoshop-compatible plugin system.
A smaller staged approach might be more practical.
1. External Filter
For example:
Filter
└── External Filter...
Possible workflow:
Selected layer / selection
↓
Temporary PNG / TIFF
↓
External application
↓
Processed image
↓
Returned to Compositor
↓
New layer
The user could configure an external application, while Compositor handles temporary file exchange automatically.
This alone could already integrate many standalone professional tools without requiring a large plugin SDK.
2. Native Compositor Plugin API
Later, Compositor could expose a small and stable extension API for things such as:
Compositor Plugin API
├── Filter Plugin
├── Adjustment Plugin
├── Import / Export Plugin
├── Tool Plugin
├── Automation Plugin
└── AI Provider
A plugin might receive information such as:
- Current layer pixels
- Current selection
- Mask
- Document dimensions
- Color information
- Layer metadata
and return:
- Modified pixels
- A new layer
- A new mask
- An adjustment result
- Or structured editing operations
AI Providers could use the same architecture
Compositor is already beginning to explore AI-assisted design and automation workflows.
A general extension architecture could potentially allow image-generation and image-processing providers to use the same mechanism:
Compositor
↓
Provider / Plugin
↓
Local model / ComfyUI / external service
↓
Generated or processed result
↓
New layer in Compositor
This would allow Compositor to remain independent from any single AI model or vendor.
Users could choose between:
- Local models
- ComfyUI
- Cloud APIs
- Third-party AI applications
- Custom services
Photoshop plugin compatibility could be a separate long-term discussion
Direct compatibility with:
may be technically difficult and may not be desirable as a core dependency.
I would see that as a separate long-term investigation rather than the primary goal of this request.
The more important foundation would be:
A native, open extension mechanism designed specifically for Compositor.
Possible benefits
- Reduce migration friction for Photoshop users
- Encourage a third-party ecosystem around Compositor
- Avoid putting every possible feature into the core application
- Keep Compositor lightweight
- Allow open-source and commercial extensions to coexist
- Keep AI integrations model/provider-independent
- Allow professional users to build custom workflows
- Make specialized filters, AI tools, and automation easier to integrate
I understand that Compositor is still developing extremely quickly, and a plugin architecture may not be an immediate priority.
I mainly wanted to raise the idea early while the architecture is still evolving.
As more professional users begin seriously considering Compositor as part of their daily workflow, extensibility may become an increasingly important part of the ecosystem.
Feature request: Plugin API and External Filter support
功能建议：插件 API 与外部滤镜支持
中文
首先，非常感谢你开发 Compositor，并将它作为开源项目发布。
作为一名长期使用 Photoshop 的设计师，我觉得 Compositor 未来有一个功能可能会越来越重要：
插件 / 外部滤镜扩展架构。
这里并不是希望 Compositor 现在就直接兼容 Photoshop 的
.8bf、CEP 或 UXP 插件。这些体系都比较复杂，而且与 Adobe 自身的平台高度绑定，未必适合直接移植到 Compositor。
我更关注的是一个更基础的问题：
为什么这个功能很重要
对于很多长期使用 Photoshop 的专业用户来说，迁移到另一个图像编辑器，并不仅仅取决于软件本身是否拥有：
很多人的实际工作流还依赖大量第三方工具，例如：
即使未来 Compositor 已经覆盖 Photoshop 大部分核心功能，只要某些重要的第三方工具无法进入工作流，部分用户仍然可能不得不保留 Photoshop。
因此，一个开放的扩展系统可能会显著降低迁移成本。
可以考虑分阶段实现
我认为不一定需要一开始就开发完整的 Photoshop 插件兼容层。
也许可以从一个更轻量的方案开始。
1. External Filter / 外部滤镜
例如增加：
可能的工作流程：
用户可以指定一个外部应用，Compositor 自动负责临时文件交换。
仅仅这一功能，就可以让很多已经拥有独立版的第三方工具与 Compositor 配合，而不需要马上设计完整的插件 SDK。
2. Native Compositor Plugin API / 原生插件 API
之后可以进一步开放一个较小而稳定的扩展接口，例如：
插件可以获得例如：
然后返回：
AI Provider 也可以属于同一套扩展架构
Compositor 已经开始探索 AI 辅助设计和自动化工作流。
未来如果有统一的扩展接口，也许可以让 AI 图像处理和生成模型使用同样的机制：
这样 Compositor 就不需要绑定某一个特定的 AI 模型或服务商。
用户可以自行选择：
Photoshop 插件兼容可以作为独立的长期课题
直接兼容 Photoshop 的：
.8bf可能技术复杂度很高，而且不一定适合作为 Compositor 核心功能。
我认为这可以以后作为一个独立的研究方向，而不是这个建议的主要目标。
更重要的是先建立：
可能带来的好处
我理解 Compositor 目前仍处于非常快速的发展阶段，插件架构可能并不是近期优先事项。
我主要是希望在项目架构还在快速演进的时候提前提出这个想法。
随着越来越多专业用户开始认真考虑把 Compositor 用在日常工作中，扩展能力可能会逐渐成为一个非常重要的问题。
English
First of all, thank you for building Compositor and releasing it as an open-source project.
As a long-time Photoshop user and professional designer, I think one feature that may become increasingly important for Compositor is some form of:
Plugin / External Filter architecture.
This is not necessarily a request for Compositor to immediately support Photoshop
.8bf, CEP, or UXP plugins directly.Those ecosystems are complex and heavily tied to Adobe's own platform, so direct compatibility may not be the best foundation for Compositor.
The broader question I would like to raise is:
Why this could matter
For many professional Photoshop users, migrating to another image editor is not only about whether the application has:
Many real-world workflows also depend on third-party tools such as:
Even if Compositor eventually covers most of Photoshop's core functionality, some users may still need to keep Photoshop installed if important third-party tools cannot participate in the workflow.
An open extension system could significantly reduce this migration friction.
Possible incremental approach
I don't think this necessarily needs to begin with a complete Photoshop-compatible plugin system.
A smaller staged approach might be more practical.
1. External Filter
For example:
Possible workflow:
The user could configure an external application, while Compositor handles temporary file exchange automatically.
This alone could already integrate many standalone professional tools without requiring a large plugin SDK.
2. Native Compositor Plugin API
Later, Compositor could expose a small and stable extension API for things such as:
A plugin might receive information such as:
and return:
AI Providers could use the same architecture
Compositor is already beginning to explore AI-assisted design and automation workflows.
A general extension architecture could potentially allow image-generation and image-processing providers to use the same mechanism:
This would allow Compositor to remain independent from any single AI model or vendor.
Users could choose between:
Photoshop plugin compatibility could be a separate long-term discussion
Direct compatibility with:
.8bfmay be technically difficult and may not be desirable as a core dependency.
I would see that as a separate long-term investigation rather than the primary goal of this request.
The more important foundation would be:
Possible benefits
I understand that Compositor is still developing extremely quickly, and a plugin architecture may not be an immediate priority.
I mainly wanted to raise the idea early while the architecture is still evolving.
As more professional users begin seriously considering Compositor as part of their daily workflow, extensibility may become an increasingly important part of the ecosystem.