Allow to give variants a description

@drew Kirkland Sadly, it doesn’t work on mobile. :(

Thanks 370131390338 (I did try that, but it doesn't seem to work on my iPad 🥹)

369738562178,

You're welcome!

To tag people, you need to type an at sign and then when you start typing the name, you'll see this pop-up where you can select the name:

Thanks, Thomas - that’s a better fit 🙏

(Apologies - I’m new to this forum and haven’t learned how to ‘tag’ people yet)

Hi 369738562178,

See this request: Option to give variants a name that shows up in the browser.

I don’t need a full description, but an easily-accessible variant name (that could be used as an export token) would be really useful.

Hi everyone, 
Thank you for the suggestion - this is not something we are currently working on.

This does not mean this is a bad suggestion or that it will never be adressed, but in an effort of transparency we want you to know that we are not currently allocating resources to solving this issue.

We will revisit the status of this thread if and when it changes.

Hi Alexander and Jakob,

regarding this scenario, I was also looking for a token / variable, which can be used to rename the output filename, so that it includes at least the clone- / version id [n]. I didn't find anything and it would be very helpful to have this as a reference between output file and the version.

Thanks and best regards, Olaf

Jakob, this is very good news! And when the developers are diving into the code, please let them also look to a way to get the information printed alongside the image. Thank you.

Moved from the archive on 16.05.23.

Hi Alexander,

Thank you for your input and for your feature request. I have forwarded it to our developers.

Best regards,
Jakob, Capture One

Eric, I agree with this explanation!

In the C1 Print Menu there is a submenu "Caption". In thhis Submneu one may choose either "Filename" or "Description".

I suspect as elsewhere in C1 "Description" maps to the UPTC-Status/Description field, which is variant specific.

By putting some variant specific information in this field, one should be able to print it.

The unfortunate things that make this awkward to use is that Printing the Description prevents printing the filename. For reasnable flexibility should be able to create a Caption just like one creates the filename for export, with tokens.

That's right BeO, the discussion was about the browser. I added a second feature about printing because, in my opinion, it is basically the same: about the wish for information that keeps variants apart. At this moment all variants have the same name, in the browser and during printing. This is not professional. I mentioned also the nice way Capture One gives the opportunity to compose a texual watermark from file properties. Why not use the same 'engine' to compose remarks in the browser?

This request only deals with information shown in the software (browser), not information to be printed, if I understood you right the identification which variant you printed should be visible on the print, outside the image itself.

regards

Finally! Aperture is mentioned as a nice example of a flexible way for adding information to a specific variant. I really miss at least a counter in variant names.

For me, there is another reason for this feature request: when I am playing with different image settings in different variants, I would like to print a text below the printed image mentioning something that gives feedback to the variant. Strang enough this is possible in watermark printing (a variant counter) but not in text printing outside the image. PLEASE Capture One team, add this feature in one or another way!

I support this wish, probably because I am used to having it in Photo Mechanic (PM) and find it useful.

PM lets me include from 0 to 3 lines below each thumbnail image in a contact sheet. I vary those lines depending on what I need to see, I just included a line showing pixel width x height. I don't need that for raw images, but I like to see the dimensions when I browse processed images. I can (of course) get the pixel dimensions via other image info means as well.

Available space should not be a major issue as the thumbnail size can be adjusted, as can the thumbnail grid. I would not worry much about C1-programmers having to adjust the thumbnail widget, class etc to include requested information, they have probably faced worse tweaks. If it turns out to require a major rewrite of the C1 user interface, some former bad design decisions should probably be rectified anyway. 

Hi Grant,

I will never fully grasp the psychology of users, but I keep trying... :-)

Hi Eric,

Interesting catch. C1 has up to two lines, the stars+color and the image name, and maybe a full new line for metadata, as an option, would be a reasonable implementation, configurable by tokens.

regards

I started my no longer used Aperture SW, to see what they did. As many have said, Aperture had a very good DAM functionality.

Aperture allows one to chose any EXIF or IPTC field for display beneath the thumbnail, and below the image in the viewer.

If the bottom of the image is shorter than the text, too bad, the text is truncated. If you want to see more, well then increase the size of the thumbnails in the browser. Want to see more thumbnails - decrease the size of the thumbnails. Some of the text is truncated. As a user, you learn to put the key Metadata on the left, and progressively less interesting to the right. I founnd it quite functional and I've never heard of a user complaining of it.

Aperture's Metadata editor is basically the same as, but not quite as good as Capture One's Metadata editor.

The difference is in viewing the Metadata. In Capture One, a user can only see the EXIF and IPTC Metadata for one Image at time -  the selected variant.

It makes a huge operational difference as a user to be able to display selected Metadata for all the variants visible in the browser.

Example of the largest size thumbnails:

Example of the smallest thumbnails:

BeO,

I like your optimism about users.

Your observation is correct in most cases  - people eventually find things they thought worth complaint are not worth the complaints and, reasonably often, they may even come to like and appreciate something they once disliked.

It may all have been about nothing more than unwelcome change at the time. Or "fear" of change.

Within a small community of users  - say within a business - any change that actually makes it through an implementation process can quite quickly become accepted and "the new normal".

In a public commercial operations with a growing (or maybe just constantly changing) user base and a reputation that is somewhat influenced by social media the dynamics are likely a little different.

That thought makes me wonder whether the old adage about software development - that 90% of all requests are never used by the person requesting them and the other 10% are not used in the way intended by the design - is till true in the agile age for end user desk top software. For much of the special needs beyond the basic functionality It may still be true.

Perhaps the solution is to re-program the people and not the software?

;)

After all if we take your observation that (most?)  people will eventually accept whet they are given (or something like that ...) then they would save themselves a lot of angst by accepting it for what it is in the first place. Or rejecting it and looking elsewhere. But perhaps the ultimate acceptance only comes about after resistance to their opinions - whether the resistance is active or passive may not matter other than to the complainer's degree of perceived frustration.

We (Or rather, I) are (am)  probably straying much to far off topic for this thread.

Grant

Hi Grant,

my point is that even now the grid cannot show the full file name if it is long, depending on the zoom level, alignment of the grid etc. So, it is already not perfect, and adding new field cannot make it worse.

What annoys me with the grid is actually the wasted space. My prefeered thumbnail size in a horizontal browser is almost unusable, which is the only resson I have it vertically, which is a bit better. So, there is unfortunately not something like a carefully programmed perfect grid layout which works for every setting, which the new request would destroy and trigger a rewrite of the grid. I suppose it is just a standard grid with standard functionality and thats it. A new line would not destroy anything, maybe make other zoom levels more usavle and some others less usable. If the new line is an option, it would behave the same as today.

A popup is not needed if a tool can be used e.g. The metadata. A configurable tool tip could halfway  suffice.

Apparently you fear that a new optional and configurable line would cause more dissatisfaction amongst users than it would cause satisfaction based on your experience of never satisfied critical users. I know from first hand exactly what you mean but I believe the contrary is true, everybody is complaining about something in their life they bought because it has some issues, and if it becomes better the next time they buy it they eventually complain the improvements are not enough, but part of the job is to accept this human behavior. And actually they keep buying it and are happy that they have it even though it is not perfect.

Regards

BeO

P.S. You're welcome.