Layers, Masks, Blending
-
This is not something that Capture One is designed to do. It doesn't load images as layers so that you can combine elements from one image with elements from another. It's an obvious task for a pixel based editor like Photoshop or Affinity Photo. (Notably, in the range of Adobe products, you'd have to switch out of Lightroom to Photoshop to achieve this.) Agreed, ON1 can do this, but that's because it is trying to be a combined raw developer and pixel-based editor all in one.
Ian
1 -
@Ian Wilson
You wrote " It's an obvious task for a pixel based editor...".
There is no good technical distinction between "pixel-based editors" and those which are not "pixel-based". In the same vein, you could argue that the cloning and healing brushes are alien to C1 because "C1 is not a pixel-based editor and not designed to push around pixels.".
There is destructive and non-destructive editing and since even combining multiple images can be done non-destructively, there is no reason why C1 couldn't support the requested feature. In other words, C1 wouldn't have to try and make the splits between "raw developer" and "pixel-based editor" at all, the requested feature would fit well into its current paradigm.
You also wrote "[C1] doesn't load images as layers so that you can combine elements from one image with elements from another." Note that there is an overlay functionality already. It would take just a bit of expanding on that functionality to generalise it to what the OP is requesting.0 -
C1 as designed works on the basis of returning to a "source" file as the basis for recalculation and does so quite frequently.
TO do any blending work, realistically, requires an intermediate file. In the old days, applications would write changes to jpgs, etc., and ignore the concept of "non-destruction". Thus the jpgs would become the edited file.
Notable blending tools, Photoshop and Affinity for example, have "bolt-on" RAW conversion options that result in internal files specific (even if similar) to that application. They are not referring back to original RAW files.
So an intermediate file is required no matter what type of file the "source" file may be. (Tiff, jpg, whatever).
The "overlay" functionality, like the watermark functionality, has, at best, a tiny amount of shared functionality with the sort of features that people expect from a full blending function, especially for stacking purposes.
In that situation, it makes little sense to try to develop an entirely new area of functionality that already exists or can be obtained through a plug-in or external processing.
One might sub-license an existing application and embed it but none of them are likely to be able to make use of C1's "go back to the original file as part of the process" functionality.
The result would likely be something like Affinity which has a built-in RAW developer module that then passes a file in an internal proprietory format to the graphics part of the application.
Photoshop, as I understand it, does much the same thing.
To undertake that level of development or even purchase and integrate an existing application would likely come with significant costs. Management would need to balance that cost, inter alia, with the simpler approach of using plug-ins and round-tripping. Basically, the choice would still be plug-ins and round-tripping BUT they might be masked by appearing to be handled in a single application with a consistent UI look and feel.
I imagine the decisions about such a development, if they are discussed, will be based partly on the size of the market (probably shrinking currently?) share and an anticipated market share that might be obtainable.
And, of course, in the modern era the challenge of a number of other developers emerging from low cost-base operations seeking to disrupt the available market for their own benefit.
It could all become very interesting.
0 -
@SFA
You wrote: "C1 ... works on the basis of returning to a "source" file as the basis for recalculation ...".
Support for compositing would just require the consultation of multiple source files (as happening already in the case of the overlay tool). What is the big deal?
You wrote: "TO do any blending work, realistically, requires an intermediate file."
That is not true. An intermediate file could be used, but an intermediate representation held in memory would be feasible as well (and faster).
Are you under the impression that C1 does not already use intermediate representations for working through its image pipeline? If so, you'd be wrong.
I don't know what the relevance of talking about some tools is which may or may not do what you are claiming they are doing. From a technical perspective, there are no hurdles and certainly no necessity to resort to external files or fall back to destructive editing.
You wrote: "In that situation, it makes little sense to try to develop an entirely new area of functionality that already exists or can be obtained through a plug-in or external processing."
C1's plugin architecture does not allow for plugins that could support compositing within C1.
External processing is always possible, but you'd need the external software to do it and then have to deal with intermediate files (e.g., .psd, or .tif files). In the same vein, one could argue that "C1 is a RAW developer and not Photoshop. Therefore, if you want to clone/heal part of your image, use external software". It obviously is much better to have functionality like cloning, healing, or compositing directly supported by C1.You wrote: "To undertake that level of development or even purchase and integrate an existing application would likely come with significant costs."
I don't think you have anything to base such a claim on.Much of what is already needed, multiple representations of the same image, masking etc. is already part of the internals of C1. How do you think cloning and healing are realised?
0 -
I just read a post that said PhaseOne/CaptureOnePro sent out a survey and, apparently, one of the questions was about this same thing... asked if we use blending/stacking/stitching features in other programs.
So, why not? I would definitely use layer stacking.
You have a section for 'feature requests' and then put down people that make a request. SMH
0
Post is closed for comments.
Comments
5 comments