marking psd file as variant / grouping of variants
when I modify a raw file with Photoshop, a psd file is created and saved beside the original raw file. In the browser I see now the raw and psd side by side. So far so good. Can I tell C1 to treat the psd file as variant, means to show the numbering in the upper right (or left) corner of the thumbnail ?
and in this regards... is it possible to group variants like in LR, means click on the first (raw) file and all variants are stacked below in the browser window ?
and with a second click on the first variant, the group is expanded again ?
Holger
and in this regards... is it possible to group variants like in LR, means click on the first (raw) file and all variants are stacked below in the browser window ?
and with a second click on the first variant, the group is expanded again ?
Holger
0
-
You can’t get C1 to show the PSD as a variant of the raw file.
If you have two or more variants of the same file, though, perhaps trying out different looks for it, you can stack and unstack them (collapse or expand in C1 terms). Click the small icon top left on the thumbnail.
Ian0 -
In Capture One parlance, a variant is a variation on the way that the image file should be rendered/previewed. Every image has at least one variant, though it can have more than one. It's not possible to have one variant "belong" to more than one image file, like you're requesting. 0 -
thank you Ian and Ben 0 -
I also think such a functionality would be very useful. I used "stacks" in Apple's Aperture a lot and I am still missing them in my workflow in Capture One. Stack: a collection just like your variants currently (can be opened and closed, a variant promoted to top), but can be defined by the user from any pictures.
One often takes several variants of a picture, e.g. by exposure bracketing, or varying a composition, or a timed series, but want to pick just one in the end, hiding the others. One needs to be able to say which pictures are variants (creatively speaking – a different meaning than technical cloned variants) in one's mind.
I don't see how to do this efficiently in Capture One now. Aperture's approach (incl. keyboard commands for creating, expanding/collapsing stacks and promoting pictures) still seems perfect to me.0 -
NNN635753566829448018 wrote:
I also think such a functionality would be very useful. I used "stacks" in Apple's Aperture a lot and I am still missing them in my workflow in Capture One. Stack: a collection just like your variants currently (can be opened and closed, a variant promoted to top), but can be defined by the user from any pictures.
One often takes several variants of a picture, e.g. by exposure bracketing, or varying a composition, or a timed series, but want to pick just one in the end, hiding the others. One needs to be able to say which pictures are variants (creatively speaking – a different meaning than technical cloned variants) in one's mind.
I don't see how to do this efficiently in Capture One now. Aperture's approach (incl. keyboard commands for creating, expanding/collapsing stacks and promoting pictures) still seems perfect to me.
The thing is that there is no functionality in C1 that would then allow you to do anything with the "stack". For that you would need to go to an external application and thus anything that allows "collective" functionality to group images in a way that is somehow different to the grouping options currently available would have no real purpose. No further associated functionality at this time.
Phase do understand the concept of "stacking", It exists in their own camera system complete with functionality to make use of it. But that is a proprietory approach over which they have development control.
Now, if some form of processing to deal with "stacked" images becomes part of C1 then it would seem logical that a stacking mechanism would also be expected. But if that doesn't happen I'm not sure there would be any benefits, compared to current options, that would be so great for everyone that image stacking (beyond some form of Album functionality) could be developed in a way that would add useful functionality yet still satisfy the great variety or perceived needs.
If we are looking at stacking for the purposes of merging images (as per the Phase camera systems) there might be some viable approaches given a common grouped file type.
For a set of images with different file types - i'm not sure how that would differ from, say, an album. (At least in concept.)0 -
SFA wrote:
...If we are looking at stacking for the purposes of merging images (as per the Phase camera systems) there might be some viable approaches given a common grouped file type.
For a set of images with different file types - i'm not sure how that would differ from, say, an album. (At least in concept.)
An existing stack should not require a binding to a specific processing pipeline. Why not let the user do the binding and decide how to use it?
I like your reference to album. A stack is already a limited or "mini" album". The limitation appears to be imposed by a stack being a collapsed presentation of "variant" from the C1 vocabulary instead of variant from a normal user's vocabulary. User's tend to think of variants of an "image", C1 developers appear to think variant in terms of one "image file". Subtle difference, but they are not the same.
"Stack-albums", I mean albums presented as stacks, could work just as well as the current list of album names. Kind of GUI versus command line thing with the difference that we have to click on album names anyway.0 -
The C1 vocabulary is 'interesting' in this usage but, ultimately, accurate.
If one is considering a single image then any edit of the image after the basic conversion is a "variant". A variation on the orignally presented conversion. However by implication and due lack of an alternative word, the first generation 'conversion' or original jpg/tiff is also likely to be a 'variant' of the original data file (less so the jpg/tiff/why analogy but still quite likely if only for crops or something.)
Therefore even the 'original' file, once made displayable, is a 'variant' of the starting point data file.
Thus the original version is also a 'variant' by definition.
Since, for a single image, any multiple edits applied are held in the same edit instruction file the 'stacking' of variations of the same edit is automatically implied by the approach. Indeed people complain that they have no easy way to 'unstack' those variants without duplicating the original image. (That said once the output files potential is taken into account "stacking" is once more a possibility.)
"Stacking" multiple Images (typically for merging purposes) is a completely different requirement as is 'grouping' different images in particular when different file formats are to be grouped.
Grouping a number of images, for whatever purpose, can already be achieved using Albums (or smart albums perhaps should that be preferred) if the traditional (but possibly less convenient) "put them all in the same folder" concept is not identified as an ideal answer by the user.
How many ways do we need to achieve the same results?
What simple enhancements would make for an easier workflow using the existing options?
Grant0 -
SFA wrote:
The C1 vocabulary is 'interesting' in this usage but, ultimately, accurate.
I think we both know the C1 variant pretty well, but I think the C1 word "variant" is part of the problem. We have seen it in numerous forum posts.
One image file + any C1 process that produces a rendered image, makes a C1 variant, stored on disk or not. A variant exported by C1 to a new file on disk, is however; still a variant in the mind of many users. But not to C1 because the image data is in a separate file. If C1 renders identical images from the first and second second file, the images are not C1 variants despite the fact that they have the very same origin in the first file.
When it comes to grouping images as stacks, why not let the user decide what images to stack? The more I think of it, "stack albums" with one of the images promoted to top and presented as a stack in the browser grid, could probably work just as well as the current list of album names, if not better.
How many ways do we need to do the same thing? I find a "one correct way only" route hard to defend as C1 is full of multiple ways to achieve the same thing, and so are most applications.0 -
OddS wrote:
SFA wrote:
The C1 vocabulary is 'interesting' in this usage but, ultimately, accurate.
I think we both know the C1 variant pretty well, but I think the C1 word "variant" is part of the problem. We have seen it in numerous forum posts.
One image file + any C1 process that produces a rendered image, makes a C1 variant, stored on disk or not. A variant exported by C1 to a new file on disk, is however; still a variant in the mind of many users. But not to C1 because the image data is in a separate file. If C1 renders identical images from the first and second second file, the images are not C1 variants despite the fact that they have the very same origin in the first file.
I get your point here but bit then the user has alread chosen to split things into two groups for whatever reason they have in mind. Just like saving a backup set from the original files and names as they came from the camera but renaming all of the files on import for some other purpose.
So if you now want to treat an originally "common" file as one image having previously split it into two purposes one has to ask why you split it in the first place and why, now they are to be re-grouped, you don;t consolidate the edits into a one ore other of the 'channels' created and save a lot of unnecessary hassle with a few seconds of work.
However, that's a somewhat philosophical discussion and, if pursued, might drag on for a long time without reaching any sort of agreement.OddS wrote:
When it comes to grouping images as stacks, why not let the user decide what images to stack? The more I think of it, "stack albums" with one of the images promoted to top and presented as a stack in the browser grid, could probably work just as well as the current list of album names, if not better.
Because from 1000 users you will probably get at least 500 different ways of doing the same thing meaning the the majority will never see what they think is the best approach and few will be satisfied.
If not that then a comprehensive solution might be developed - but not used by 99% of those with licences, - and everyone objects to the cost involved for both development and support.OddS wrote:
How many ways do we need to do the same thing? I find a "one correct way only" route hard to defend as C1 is full of multiple ways to achieve the same thing, and so are most applications.
True enough in many cases - bit how often re the multiple ways used? And how many MORE are needed?
Indeed one might ask a question about how many users actually KNOW that some many options might be available to assess.
I would bet that the number would be small and that of that number few people would make use of their knowledge in their regular use of the application.
I would contend that Phase can compare the number of requests of enhanced functionality with the number of licensees for whom the request would be 'valid' and the number of times the area of functionality might actually be used.
Thus informed they will make their decisions.
My wild guess would be that, in terms of the majority of income and potential profit across the group, the 'big number' players are unlikely to be concerned about this particular aspect of functionality.
Of course I may well be wrong.
Someone somewhere will have the required information and the data to back it up whatever the outcome.
Grant0 -
I don't want to start the disucssion again what is better or more needed by the users, but just to give you an example of a use case...
I am also fully aware of the difference of two files on the disc, and one file on the disc with a description of modification in the DB (Variant). And I can also image that the developers have a different view on handling several files, or handling one file with several description.
But if i think of a folder from one photo shoot with e.g. 100 files. While 10 of them have 2,3 or 5 variants and 5 of them have "variations" from other applications and stored in the same folder in a different format (maybe tiff or psd or whatever).
Of course I can now create 10 albums to collect all the variants and variations of one photo, but the number of albums will increase rapidly. Of course, the albums can be structured like the file folders.
But for me and in this case, I would prefer to have this structure only once and having files and variants (which are anyhow in one folder) together in this folder and just stacked (or grouped for different file types) in the file-folder.
Typically I use albums to build collections of photos from different shoots or file folders, which comprises more than a handful of variations of the same photo.
Having variations of the same photo in the same folder, I prefer to have them simply stacked.
That may not be every ones workflow, but a mechnism called "grouping" which is similar to stacking, but available for raw-files, variants and other file types would provide this functionality. Don't need to be done with the already existing stacking mechnism. Can be a new symbol in the preview and therefore a new function. I think this could be something which some other users would like too 😉
Holger0 -
In computer terms it's effectively the same thing surely?
And you are still managing the grouping mechanism.
Grant0
投稿コメントは受け付けていません。
コメント
11件のコメント