Disappointing API

[NN636108740581938133UL]

I've written plugins for Photoshop and After Effects (among others), and I was expecting an interface like those where you can get access to the pixel data, process it, and pass back your modified version.

Can someone from Phase One comment on the plugin SDK roadmap, and when we might expect to get functionality like this? Ideally, the pixel data would be in the native internal colorspace, and we'd get APIs to manipulate all of the features that are exposed via the UI, such as exposure, curves, HDR settings, color correction, etc.

I've got a lot of ideas for C1 plugins, and I was really interested in getting started with the SDK, but they all require access to the pixel data.

[Class A]

I've got a lot of ideas for C1 plugins, and I was really interested in getting started with the SDK, but they all require access to the pixel data.

So what is the API good for, if it doesn't support access to individual pixels?
Is it just to manage/export/publish already processed images?

That would indeed by very limiting.

It would be very interesting to implement PixelShift through a plugin but then one would not only require standard access to pixels, but access to the pixels of four images packaged up in one camera-produced file.

[pope]

The Plugin API indeed is about Exporting, Editing, Opening, and Publishing.

So if you wanted the pixel data, you would create an "IEditingPlugin" and you could get the rasterized pixels of the image. It would not hook into the Capture One RAW pipeline - which I think makes sense since different parts of the RAW processing happen at different times and it could be funky to know WHERE in the pipeline to make your pixel changes. This pretty much works like "Edit With..." and opening in Photoshop or something, but here you can specify the tool to run.

As far as tools to modify parameters in the UI - it seems that Mac users can use AppleScript to control some of those properties. Not sure how deep that goes though, as I am no longer on Mac.

So in the example of doing PixelShift - you could totally do that, but with an "IOpenWithPlugin" so that you have the RAW file with unmosaic data. Then you would return a result - which would be the new file with your changes that Capture One can handle, probably DNG. I am thinking about writing a plugin with https://www.fastrawviewer.com/SonyPixelShift2DNG, once it's out of beta. At least that's the theory glancing at the API docs.

All that said, I would love more power APIs - like being able to modify Keywords (have AI/Machine Learning tag my photos), or even modify Mask data. And I certainly would welcome UI APIs like suggested so Windows users have the abilities that Mac users have with AppleScript.

[jknights]

Got to say that I am more than a bit disappointed with the feature set offered in the SDK.

First of all it uses different languages for different platform? Why?
C++ is transportable between Windows and Mac.

Second there is no ability to manipulate pixel level data. We really need to be able to interact with the internal image processing pipeline to do good stuff.
Just doing a pass out of whole image to an external app is pretty weak.
I thought that finally we could really add some cool features to missing parts of COP.

Hey ho, guess it is easier to just save the image and then open in another package then save and work again in COP.

[NNN636269374720392879]

There should be Python support, otherwise it is rubbish and not so many developers would touch it...

[ex-ratt]

I don't think an API is rubbish just because it is a C# (or Java or Swift or whatever) API. And it makes sense for the API to use the language that Capture One is written in. If one understands the concepts of Python, then learning another language like C# or Swift shouldn't be harder than learning Python from ground up. See it as a learning opportunity

On the other hand I wouldn't mind another language for API development, maybe even one that is used by both the Windows and Mac Version of Capture One, so there would not be the need to develop two identical plug-ins in different languages.

[fatihayoglu]

If there is no pixel level access, then this whole plugin thing is noting but a marketing gimmick to say "we now have plugins like Lightroom" as the whole market knows what a plugin meant for Lightroom, but CO it only does export import stuff which we already have. So not quite sure I need a plugin to do that.

[jknights]

If there is no pixel level access, then this whole plugin thing is noting but a marketing gimmick to say "we now have plugins like Lightroom" as the whole market knows what a plugin meant for Lightroom, but CO it only does export import stuff which we already have. So not quite sure I need a plugin to do that.

I agree.
Without the ability for a plugin to interact at pixel level it is fairly useless (well to me anyway).