Allow to give variants a description
Logged
When I create a variant, it usually is for a purpose. It would be helpful to be able to attach a note of that purpose to a variant, so that the note is visible in the browser.
Examples:
I often have one variant that contains the basic edit of an image. In addition I have variants that contain adjustments targeted at different output media like fineart print - book - web. In contrast to say a B&W edit, the differences are not easily discernible in the browser and a textual description in addition to the sequential number would make life easier.
-
Official comment
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 -
Good idea.
0 -
This is something which I habe been since the beginning...
0 -
As a temporary "Available Now" solution you could consider using a suitable IPTC metadata field to help the identification. Also very useful for searching.
1 -
"As a temporary "Available Now" solution you could consider using a suitable IPTC metadata field to help the identification. Also very useful for searching."
That wouldn't show up in the browser would it?
0 -
No, it would not show up in the browser.
The browser, in any case, has limited space so I would doubt that simply making a text field available to add to teh existing image information would be practical. So a totally new solution would be required.
Meanwhile a floating Metadata tool could be set to display the relevant field(s) related to the selected image and so provide the information that way when it was important to know it.
IPTC metadata for each Variant can be unique.
1 -
I didn't think of IPTC data, but had the same idea with keywords. I think keywords are also per variant, but haven't tested it, is my assumption right?
0 -
One of the main advantage of variant descriptions would be to have such descriptions displayed in the browser.
2 -
Alexander,
Yes, keywords are per variant.
Keyword(s) are a great option in many ways but potentially lead to Keyword clutter, depending on how one uses them and how a description you might want to use could perhaps clash with a valid keyword and so complicate the usage.
The IPTC fields, unless you need to follow the guidelines for the archival or media industries, are mostly free format text fields (some industry fields are intended to contain only approved codes or words that are classifications) and offer extended content capability - effectively quite a large character capacity per field.
Personally I think the IPTC fields are a better option than Keywords although there may be no harm in using both.
If you have relatively few descriptions you might want to use for the variants I thing an IPTC field would work well since adding an existing field value to a new variant would likely be easier than a keyword selection - and you can use phrases more readily. There may even be a pre-named field that seems ideal for the purposes you may have.
0 -
Thomas,
"One of the main advantage of variant descriptions would be to have such descriptions displayed in the browser."
Yes, but there is limited width available if the browser's purpose is to display Thumbnails. Which is probably why the existing options about what can be displayed are restricted.
However, if one has been able to register somewhere the purpose of the variant and other information of use - perhaps which Output Recipe one intended it for - the filter system can be used to restrict the browser to only show those variants. That might make the need to display the descriptive information somewhat less important.
I could envisage having a "Cursor Hover" option (or a Keyboard Shortcut for those who much prefer that approach) that provides a popup window of additional information about the current image under the cursor. If the content of the popup was user definable that might be an even more flexible option - although with the size of some of the fields in the IPTC section of the metadata the popup might need to be quite a large window (dynamically adjusted) to satisfy everyone.
0 -
" there is limited width available if the browser's purpose is to display Thumbnails. Which is probably why the existing options about what can be displayed are restricted"
If the description is too wide to be displayed on one line, it could either be cut off or broken across two or more lines. That wouldn't be a problem. It would still serve the purpose.
1 -
Popup on hover would be much more flexible.
Also it would save having to rewrite the UI. Again.
But the final decision would be for the developers
1 -
Grant,
hover is something different. And popup windows are awful, tooltip would be acceptable.
I fully support the idea to be able to see a custom text in the browser. It could be optional. It is a good idea anyway to let the user decide which information he wants to see in the browser.
Do not forget, you can even resize the thumbnails, and real estate / monitor size is different for different people. And if the viewer is off then there is plenty of space. And users can choose to abbreviate, even 1 or 2 letters might be sufficient for some purpose and for some people.
I have submitted this as a feature request too. The hover idea is only good if the tool tips do not get in the way as the small icon tool tips in the tools do. I am glad they fixed the issue that ALT click on the reset icon displayed the tool tip which reached into the viewer area.
There is no need to rewrite the UI unless they use a 3rd party component which does not allow this functionality.
Regards
2 -
"users can choose to abbreviate, even 1 or 2 letters might be sufficient for some purpose and for some people"
Exactly.
1 -
"
"users can choose to abbreviate, even 1 or 2 letters might be sufficient for some purpose and for some people"
Exactly."
Some will.
Many will not understand why they cannot write War and Peace in a field somewhere and have it displayed in all of its glory.
It is in the nature of users.
As for re-writing the UI -- all of the sizing and scaling and considerations for height and width constraints( for all sort of screens and their screen handling) would need to be addressed to allow for wider and or multi-row extensions of the descriptions below the limited width thumbnails. The effect, whether the Browser is displayed Horizontally or Vertically, is unlikely to be pretty.
Many will not understand ... etc., etc.
Make it something for the viewer to display and the problems would likely be less ... but people will demand it as a Browser feature.
Make it some for of temporary display (or floating tool for which the fields to be displayed can be user defined - a variation of the existing Metadata display for example) and it would offer much greater flexibility of use.
Grant
-1 -
Grant,
I think that usually your arguments are stronger.
"Many will not understand why they cannot write
War and Peace in a field somewhere and have it displayed
in all of its glory.
It is in the nature of users."Well, people do understand that if their strings are too long that they cannot be shown in its full glory in a limited space. Here, my long image names do not show completely if the browser thumbnails are small. This "issue" that "many users do not understand" exists already today:
Make the thumbnails bigger and hey, all glory is back again:
"Many will not understand...."
And even if that were true, that is a reason for you not to enhance software in the way other user do understand and want it to be?
What you also can see in the second screenshot above that there is already the perfect space for new information, probably the product management or developers have reserved this for our request. :-)
The problem with your counter proposal is that you do not explain what greater flexibilty this should be, it is at least not flexible enough to present the user all the requested information in the browser as the browser shows the color tag or stars for example, then you simply can click, click, click the variants, save selection as album and done. click click click, process 3 variants and done. etc. etc. pp.
"Rewrite" is something different than enhance or amend/change. Re- write usually means throw the old into the bin and start from scratch. I simply do not believe this would be the case, but argue me wrong if you like.
I would appreciate to be able to customize which fields I can see in the browser. Much greater flexibilty. I agree on this aspect.
I have nothing against a floating tool in addition, if that serves your purposes better.
regards
BeO
EDIT: P.S. In addition, if the space is not sufficent, a hover over tool tip could show the information. Users would understand, as this is standard in many other applications, I wonder why this is not yet here in the browser, I simply do not understand this due to my nature.
1 -
Hello All. If you check the IPTC documents you will find that there are several IPTC fields designated explicity for the description of an image. These fields are supported by Capture One.
Other DAM software allows a user to choose some IPTC fields for display in the browser (or Viewer) if there is sufficient room below the image/thumbnail.
The Feature request could be as simple as this: show the IPTC-Status: Headline field below the Image in the Browser and Viewer, truncate as necessary - if there is no room below the Image it doesn't show.
From the IPTC website:
Headline (In Capture One--> IPTC-Content/ Headline)A headline is a brief synopsis or summary of the contents of the photograph. Like a news story, the Headline should grab attention, and telegraph the content of the image to the audience. Headlines need to be succinct. Leave the supporting narrative for the Description field. Do not, however, confuse the Headline term with the Title term. This field is limited by the IIM format to about 256 characters. In XMP there is effectively no character limit.
Description/Caption (In Capture One--> IPTC-Content/ Description)
The Description field, often referred to as a ‘caption' is used to describe the who, what (and possibly where and when) and why of what is happening in the photograph. It can include people’s names, their role in the action, the location. Geographic location details should also be entered in the Location fields. The amount of detail included will depend on the image and whether the image is documentary or conceptual. Typically, editorial images come with complete caption text, while advertising images may not. This field is limited by the IIM format to about 256 characters. In XMP there is effectively no character limit.
Title (In Capture One--> IPTC-Status/Title)
A short human readable reference for the image. It can be a text reference or a numeric reference, and serves primarily as an identifier. It has been used by photographers for their image filename, though since about 2008 IPTC now provides specific fields for image IDs like Digital Image GUID or Registry Entry (those wishing to, can use the Registry Entry. The Title field should not be confused with the Headline field which is a short descriptive field about the content of an image.
This field is limited by the IIM format to about 64 characters. In XMP there is effectively no character limit.0 -
Thanks Eric.
What the three fields do not cover is some variant specific "tag" which allows the user to say what purpose the specific variant was created for, e.g. print on paper x, developed for web, cropped for purpose y (or abbreviatons thereof).
Even watermarks can be customized with tokens, this would also be an idea for the browser variant information, so users can choose which fields would be shown if space allows, one line would suffice.
If it is one field, the field should be editable in the browser (in edit mode).
regards
0 -
Hi BeO
Thanks Eric.
What the three fields do not cover is some variant specific "tag" which allows the user
to say what purpose the specific variant was created for, e.g. print on paper x,
developed for web, cropped for purpose y (or abbreviatons thereof).These three fields are all variant specific tags. In each Tag you can write whatever you want, according to IPTC standard or not
In Capture One there are now 33 IPTC fields; if the user sets it Capture One will fill in the Copyright Notification and IPTC-Status Description on import, most users do not use the remaining 31.
According to your urging you wish Capture One to make a new Metadata Tag which is not IPTC (so it needs a new section in many GUI menus, it needs a new Tag in the XMP and JPEGs outside of the IPTC section, cannot be easily transfrerred to any other SW) and is very specific to solving use case that you have raised.
OR, one could choose that that a user can select any IPTC field to be shown in browser or viewer, and be editable. Now a user such as yourself might choose IPTC-Content/ Headline for recording the variant purpose information you have mentioned here (which I agree is very important) and the information will be present and readable by other SW if you ever export, but also one can choose IPTC-Content/Description and view the variant's Descriptions (Titles as we usually think). Another user might Choose a different field that is important to him. Or you might choose another field that is also important to you.
The second solution also meets your needs (it may meet your needs better if you use other Photo editting SW), but it also can meet the needs and enhances the user experience of many other Capture One users. It is also less dissruptive because no new special tags need to be added to GUIs and files, so less work for Capture One Developers.
Even watermarks can be customized with tokens, this would also be an idea for the
browser variant information, so users can choose which fields would be shown if space allows,
one line would suffice.Indeed. Use a token for one or more IPTC fields, e.g. the IPTC field that You, personally, have chosen to hold the variant purpose information (all the IPTC tags are variant specific)
0 -
You are right, having configurable IPTC fields in the browser is a more generic solution.
regards
0 -
BeO,
"I think that usually your arguments are stronger."
Well thank you - I think ... ;)
The challenge as I see it is that if you take the browser's grid view at it's smallest zoom and with the browser in vertical mode - there is NO text under the thumbnail (at least not on my system),
Use one of the other views and the situation is different BUT one would need to make the display quite wide to show much information field width.
Make the Browser horizontal and in grid mode the display is still limited, in the other modes one has the width but the height restriction is a bit limiting.
The "wasted space" seems to be just a function of the zoom level.The ability to wrap information or add fields as zoom levels change may be an option in the UI code to some extent but probably not as flexibly deployable as users might expect. If it is NOT an option then the work to add it (and get it right in all circumstances and with all display and zoom options and with the use of any field a user may wish to use) could be extensive. By comparison I would think some sort of of "pop-up" display window might be somewhat easier. And more flexible. Especially with different screen resolutions.
It might also be more portable across operating systems?
Eric has added a lot of description related to points about using the existing IPTC fields that I totally agree with.
Bear in mind that many of the IPTC fields have the potential to hold a lot of text. They may appear to be of limited size on screen but it you keep typing they may get wider and/or add extra lines.
Now logical people in this thread may, sensibly, say that they would only require a few extra characters to achieve what they want to achieve. That's fair enough BUT the C1 designers have to consider what ANY user might decide to do with the facility. Constraints for data fields are generally not a good idea as far as users are concerned. I can speak from a position of decades of exposure as both supplier and consumer.
So if someone has decided they want to tell a story of 4000 characters in a text field that will accept that amount of text AND they expect to see it under their Thumbnail image - no matter how absurd that might seem - they will likely complain bitterly about enforced restrictions. So how many character does a designer allow? Or is there another way to avoid any restrictions that would offer greater flexibility and cross platform compatibility and, perhaps, be easier to deliver?
If there is then there is a good chance they will eventually end up doing it anyway - so they might as well do it to start with.
IMO.
Grant
0 -
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.
0 -
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
0 -
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:
0 -
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
0 -
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.
0 -
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!
0 -
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
0 -
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?
0 -
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.
0
Please sign in to leave a comment.
Comments
33 comments