Improve Capture One
Request a new feature, or support for a camera/lens that you would like to use in Capture One.
Request a new feature, or support for a camera/lens that you would like to use in Capture One.
What problem do you see this solving?
I use colour tags to quickly filter photos. It would be useful to be able to specify my own labels for each colour tag, such as 'First pick', 'Maybe', 'No', 'HDR' and 'Pano'.These custom labels need to display in the Adjustments, Color tag menu.
When was the last time you were affected by this lack of functionality, or specific tool?
Currently while I am reviewing large numbers of images from a 3 week trip
|
Current workaround
Are you using any workarounds or other solutions to achieve your goals in Capture One? Red, yellow and Green tags are easy mapped to the key pad. I do find that I have to stop and think when I am looking at HDR or panos. I need a postit note stuck to the side of the monitor to remind me! |
+1, I really need this feature. This was great to have in Lightroom and it would make switching to CaptureOne Pro even better.
My use case is that I like to separate my crops so I know exactly which ones I should export for Facebook, Instagram square, Instagram Vertical, Instagram Landscape, Print, etc.
My desire is for quick and simple visualisation on screen
I would suggest that the display label for each colour tag is held in the catalog or session database to allow meaning of colour tags to be changed depending on project requirements. A default set could be configured at the application level or stored in catalog/session templates.
As for moving the metadata between different applications, I assume that the colour tag is currently simply exported as is and I would not change this behaviour. This allows other applications to be configured as needed (and where possible)
The current non-standardised usage of colour codes is potentially manageable in so far as there are not so many different "standards" and that offers at least some possibilities to write "conversion" tables for sharing tagged images between applications.
As soon as the option to create personalise "names" for the "colours" is introduced one can forget any such conversion ability. That might even apply to a single user where their use of certain colours (for quick and simple visualisation on screen) may change over time - or even project to project.
Surely a better solution would be to use a different field and make it available to users on screen - be it an existing field slightly re-purposed or a new field or fields for users to use as they wish.
The downside of using a text field rather that a colour spot is that it requires more screen real estate to display and text is less readily helpful than a simple colour based visual indicator for many purposes.
Maybe the chosen text field, existing or new, could have a small icon associated with it and the icon be colour codable. That way users would have a specific field for use with a descriptive text AND a coloured icon for display for visual grouping and where screen or print space is limited.
If users choose to change the meaning of such a an icon/colour code combination they might need to consider how they deal with that over time. I would suggest that the text field and icon are both saved in the edit details, thus allowing historic meanings to be fully understood as they are or easily selected for some future adjustment is a user's use of the feature changes over time.
My view on such matters has long been that it is usually better to offer new functionality rather than try to hack some existing "industry Standard" approach to make it fit (badly) - no matter how poorly the "standard" has been deployed up to now.
The color labels differ between apps for sure. They differ between Adobe and Capture One. macOS uses even different color labels to values mapping. Color Label sets and their values are not standardized.
Thew colour codes are not that kind of hard, well thought standard... apps like Lyn can't show colour codes in another language than English, meaning, in German or French only "orange" slips through form one app to Lyn. They corrected it, but basically it's just a name. Bridge and a lot of other apps already have a look-up-table, showing the colour (which doesn't have to be limited to 5 or 8 but within the app can't be increased) and a "translation" into their meaning.
I do use colour tags for more than only one task and do the selection by rating. So, to me the "colour meaning" sometimes has a short life. For lens comparisons I use colour labels as very basic manufacturer code. The "exported icon" is to tiny to be seen in an overview, therefore I colour tag sometimes also the exports.
In the browser I only can see the filename, ratings and colour tags. And I don't want to mess around with filenames.
I support the idea as no one has to use it but some will find it helpful.
> SFA: ... colour codes between different software applications?
Label differences is a well known trouble issue.
https://community.adobe.com/t5/lightroom-classic-discussions/export-lightroom-color-labels-to-jpeg-metadata/td-p/8835954
How would this work with the "standardisation" of colour codes between different software applications?
Being able to give meaning/interpretation would finally make them useful for me - right now I have no idea what I could use them for, colours are just colours.
This needs to be pinned and seen by more of the community to hopefully get this implemented.
Excellent suggestion...C1, it can be easily implemented... Please do it :)
YEEEEEEEEEES PLEASE. And could that custom name be a token for export filename or (better) for folder naming too.