Bri W

Even if you've never used this before, not sure how anyone could watch Neil's video and not think oh yeah, we need that! 🙂
 

Hi,

One of the feature that is holding me back to switch our studios (CG-studio) pipeline to Affinity Photo is the lack of the equivalent of Smart Objects from a well know competitor. The alternative for our pipeline could be that the EXR file format is added to the list of supported RAW files. In this way our EXR renders can be developed in Develop Persona as an embedded layer. And can be replaced easily with an updated version of it without loosing the Develop Persona settings.
Currently EXRs are pixel layers when opened in Affinity Photo. In Develop Persona it is not possible to develop an EXR (pixel) layer as an embedded layer. Nor can an EXR embed layer (via Place) be opened and developed in Develop Persona.
So Devs what do you think?
 

I'd love to move away from Adobe Photoshop and use Affinity Photo for all my painting, but I just need one feature to make the switch, Affinity needs to let users Clip a layer to a group. I've made a video showing off the feature, examples of using it, and why it's a must have, please check out the video and consider supporting this feature!
 
- Neil

I'm talking about The Metadata Working Group standards set by Adobe, Canon, Apple, Microsoft, and Sony. Ratings are part of that standard and it specifies -1 for rejects and 0-5, if no rating is present 0 is supposed to be assumed. IPTC provides for extended data, which also have standard places in XMP or the legacy IIM. Some DAMs will read IIM and sync it to XMP. XMP is an ISO standard, there are name spaces provided. Yes the X is for extensible, but it is stupid when programs like ACDsee ignore the name spaces already there and create their own. If users decide to switch, they have to use EXIFtool or other tools inside the new DAM (which often rely on EXIFtool) to change those tag names.
Hierarchical keywords are the sticky point. There is a MWG standard but it seems no one really likes it from what I could find. EXIFtool supports it. The closest we have to a standard in use is writing them to XMP:XMP-LR:HierarchicalSubject. Since Lightroom is the 800 pound gorilla, whether we like it or not, that is an unofficial standard. It's what Imatch and Daminion use and I'm sure others. EXIFtool also supports it. ACDsee use their own proprietary name space  again and you have to tell it to sync to flat and then it only syncs the leaf. You should have control over how hierarchical keywords are written to flat keywords, since outside your DAM, it is the flat keywords that will most likely be used. Again there are standard named spaces in XMP for flat keywords.
I actually like how Capture One supports XMP more than how LR does despite C1's weaknesses in keywording. LR is just write it or don't. I have C1 set to load XMP. Since I write all metadata in IMatch I don't want C1 writing over it with it's more limited features for metadata. I do want to be able to filter with the ratings, labels, and keywords that are in the XMP sidecars. Since C1 doesn't use XMP to store develop settings like LR, I don't lose anything by leaving it on load only. There are pros and cons for storing the develop settings in XMP, the main pro would be less sidecars to worry about. A strong DAM can make sure sidecars stay with the master file as long as you move them in the DAM. The con is as I mentioned, when both metadata and develop settings are stored in the XMP, you risk overwriting the metadata with a weaker tool.

Keep in mind this thread was not begun by Serif themselves. It was a consumer that posted the poll and comment thread based upon a number of rumors and a few isolated unofficial statements made by forum moderators. Very few companies pre-announce their future products at least until they are only weeks or months away from delivery. If they have nothing near delivery, then I don't expect to hear anything from them. 
This thread says less about Serif and more about how consumers' minds work. We don't "deserve" better treatment by Serif. They've already gained my trust, and I signal that by spending my $$$ on their imaging products. If and when they release a DAM, I'll be happy to check it out. But for now, there are other capable products that perform this function well enough for my workflow.
Creating a true DAM (which Lightroom itself is NOT) is difficult business. I hope Serif figures out how to define and design one that fits in with the aesthetic and capability of their rest of their tools.

The problem I see in most of these posts is the requests are for another limited photo manager/processor a PAM or PAMP. Lightroom is far from the bar a real DAM solution should reach for. A full featured DAM does not hinder its use for photos only. I agree LR is probably the standard for photo manager/raw processors, but it too falls short even in that limited scope. LR does HDR but saves as a DNG, another attempt to lock you in. The standard is openEXR or older and more limited .HDR, some of us care more about that "super raw" than the tone mapped/fused byproduct (which by the way is no longer HDR). A real DAM needs to follow standards, the metadata needs to be written to the correct sections of XMP (Extensible Metadata Platform), yes that means sidecars for files that don't allow embedding the data, like raw files. When standards are followed, any other program that also follows standards can read it and use its functions to sort and search on it. All proprietary metadata should be easily extracted for remapping to the next DAM. Nothing should be locked into that particular DAM. At the very least it should handle graphics files, but that's just a GAM  
Steve said: The use of a database should not be required. However, if there’s just no getting around it for whatever reason (speed of searches, etc.), then perhaps the DAM could recreate it knowing only the root directory where all photos are stored.  Of course, this might take awhile. 
Yes, speed of searches is why you need a database. Following XMP standards would take care of the second part if the XMP was written to standards in the first place at least for EXIF, IPTC, and hierarchical keywords. I agree that it should be a referenced database that leaves all files where you want them in your file system. 
Steve also brought up mapping and location tags. Again I have to bring up IMatch. I create location boundary on the map, then fill in all the location data for the IPTC section of XMP. I also can specify keywords to be written. I have my own location hierarchy in keywords, and some locations may also have keywords written unrelated to the location branch but always wanted for that location. I can use the GPS data if present or drop the photos on the map and even add direction of view. From there all the metadata is written and I'm in full control of all of it. I never use reverse lookup. It is too often wrong and/or not granular enough for my desire.
Don't confuse XMP or other sidecars with transferring your raw conversion. Yes, some processors store the recipe for conversion in the XMP, that can serve transferring the raw in its parametric edited state to the same processor in another location. Yes some raw processors will attempt to translate that recipe to its own "kitchen" People need to understand the fact that each raw processor has its own selection of tools, and even if the tools have the same names they work differently. If they all worked the same, only the subjective attractiveness of the UI/UX would differentiate them. That is not the case, and it is a blessing and a curse. If you want a permanent copy of how that photo looks as edited in the raw processor of the moment, export it to jpg. or better 16 bit tiff. The non-destructive parametric editing we love about raw processors is the reason only that processor can read, write, and properly "cook" the recipe. If you want to use a different processor, start over. Look at it as an opportunity to do better. This is also argument one for separation of DAM and processing. 
Hierarchical keywords of course. Those that don't need them, don't use them, but without them a DAM it isn't. It should support import and export of controlled vocabularies. These can be created in app,  found for free online, or paid curated lists. Those need to be easily editable. There should be controls for grouping keywords (keywords that are only used for organizing the list such as Who, What, Where, Why, etc.) LR has this. There should also be controls for the mapping between flat keywords and hierarchical keywords, LR doesn't. It should be quick and painless to fix the files where this mapping fails because it will. One cool feature in IMatch that I've come to depend on is color coding keywords. I color code each first level branch of keywords. All keywords under it then have that color. I can see at a glance of the thumbnail if I'm missing branches of keywords. Drilling down hierarchies can be time consuming, so you should be able to start typing and have matching keywords show in a list to speed up the assignment of keywords. Synonym support can help the organization and speed of assignment. Animals are a great example. You probably want the taxonomy, then you often have multiple common names (Puma, Panther, Catamount, Mountain Lion...) Sure you could build all of that into the hierarchy, but then you'd need to remember which did you use for the leaf. Better to use synonyms so that entering one common name applies all and the hierarchy of classification. The lack of synonyms in C1 is what drove me to separate DAM from processing when I dumped LR.
Version and buddy file (sidecars like xmp, processor files, even supporting documents) control is vital. This way you can control how metadata is copied to child files and moving the parent also moves the children and and buddy files.  
Labels are so useful, most programs cripple them. Lightroom gives you sets of labels, you can only see, search, and filter one set at a time. You can change the label text, but not the color. There are only 5 colors plus the white custom label. Capture One has seven colors, cool two more, but you can't change the text or color and there are no sets. IMatch labels allow editing of the color and text. If there is a limit to the number, I haven't found it yet and I have 19. I have labels that match C1, others that I use for stages of workflow outside of C1 or non photo files, and others that match my main set from LR. I can see all of these labels in the IMatch viewer and thumbnail windows. I can quickly click on one in the collections list and instantly filter my view and I can use them in complex filters that combine other metadata. The point is in a real DAM I can make it work with the limitations of LR, C1, On1.... both to read the labels they can write or write labels to XMP that they'll read and filter on.
I think Affinity can come up with a number of ways to make the raw conversion more like dedicated converters. Maybe something like a raw adjustment base layer that brings up the develop persona when selected with the settings always adjustable. They could facilitate copying raw settings in a number of ways without creating a PAM/PAMP/GAM or best of all DAM. If they do create a manager I hope it isn't as limited as the majority of requests on here are asking for. At the very least it would have to support all files types the current suite can edit. It must follow XMP standards so that if it didn't write metadata with the control and flexibility of IMatch it could sort and filter what I create in IMatch without mucking it up. I still stand by my post back on page 3, I'd rather they concentrate their resources on Photo, Designer, and Publisher. All amazing version 1 products. I look forward to paying for version 2.

The problem I see in most of these posts is the requests are for another limited photo manager/processor a PAM or PAMP. Lightroom is far from the bar a real DAM solution should reach for. A full featured DAM does not hinder its use for photos only. I agree LR is probably the standard for photo manager/raw processors, but it too falls short even in that limited scope. LR does HDR but saves as a DNG, another attempt to lock you in. The standard is openEXR or older and more limited .HDR, some of us care more about that "super raw" than the tone mapped/fused byproduct (which by the way is no longer HDR). A real DAM needs to follow standards, the metadata needs to be written to the correct sections of XMP (Extensible Metadata Platform), yes that means sidecars for files that don't allow embedding the data, like raw files. When standards are followed, any other program that also follows standards can read it and use its functions to sort and search on it. All proprietary metadata should be easily extracted for remapping to the next DAM. Nothing should be locked into that particular DAM. At the very least it should handle graphics files, but that's just a GAM  
Steve said: The use of a database should not be required. However, if there’s just no getting around it for whatever reason (speed of searches, etc.), then perhaps the DAM could recreate it knowing only the root directory where all photos are stored.  Of course, this might take awhile. 
Yes, speed of searches is why you need a database. Following XMP standards would take care of the second part if the XMP was written to standards in the first place at least for EXIF, IPTC, and hierarchical keywords. I agree that it should be a referenced database that leaves all files where you want them in your file system. 
Steve also brought up mapping and location tags. Again I have to bring up IMatch. I create location boundary on the map, then fill in all the location data for the IPTC section of XMP. I also can specify keywords to be written. I have my own location hierarchy in keywords, and some locations may also have keywords written unrelated to the location branch but always wanted for that location. I can use the GPS data if present or drop the photos on the map and even add direction of view. From there all the metadata is written and I'm in full control of all of it. I never use reverse lookup. It is too often wrong and/or not granular enough for my desire.
Don't confuse XMP or other sidecars with transferring your raw conversion. Yes, some processors store the recipe for conversion in the XMP, that can serve transferring the raw in its parametric edited state to the same processor in another location. Yes some raw processors will attempt to translate that recipe to its own "kitchen" People need to understand the fact that each raw processor has its own selection of tools, and even if the tools have the same names they work differently. If they all worked the same, only the subjective attractiveness of the UI/UX would differentiate them. That is not the case, and it is a blessing and a curse. If you want a permanent copy of how that photo looks as edited in the raw processor of the moment, export it to jpg. or better 16 bit tiff. The non-destructive parametric editing we love about raw processors is the reason only that processor can read, write, and properly "cook" the recipe. If you want to use a different processor, start over. Look at it as an opportunity to do better. This is also argument one for separation of DAM and processing. 
Hierarchical keywords of course. Those that don't need them, don't use them, but without them a DAM it isn't. It should support import and export of controlled vocabularies. These can be created in app,  found for free online, or paid curated lists. Those need to be easily editable. There should be controls for grouping keywords (keywords that are only used for organizing the list such as Who, What, Where, Why, etc.) LR has this. There should also be controls for the mapping between flat keywords and hierarchical keywords, LR doesn't. It should be quick and painless to fix the files where this mapping fails because it will. One cool feature in IMatch that I've come to depend on is color coding keywords. I color code each first level branch of keywords. All keywords under it then have that color. I can see at a glance of the thumbnail if I'm missing branches of keywords. Drilling down hierarchies can be time consuming, so you should be able to start typing and have matching keywords show in a list to speed up the assignment of keywords. Synonym support can help the organization and speed of assignment. Animals are a great example. You probably want the taxonomy, then you often have multiple common names (Puma, Panther, Catamount, Mountain Lion...) Sure you could build all of that into the hierarchy, but then you'd need to remember which did you use for the leaf. Better to use synonyms so that entering one common name applies all and the hierarchy of classification. The lack of synonyms in C1 is what drove me to separate DAM from processing when I dumped LR.
Version and buddy file (sidecars like xmp, processor files, even supporting documents) control is vital. This way you can control how metadata is copied to child files and moving the parent also moves the children and and buddy files.  
Labels are so useful, most programs cripple them. Lightroom gives you sets of labels, you can only see, search, and filter one set at a time. You can change the label text, but not the color. There are only 5 colors plus the white custom label. Capture One has seven colors, cool two more, but you can't change the text or color and there are no sets. IMatch labels allow editing of the color and text. If there is a limit to the number, I haven't found it yet and I have 19. I have labels that match C1, others that I use for stages of workflow outside of C1 or non photo files, and others that match my main set from LR. I can see all of these labels in the IMatch viewer and thumbnail windows. I can quickly click on one in the collections list and instantly filter my view and I can use them in complex filters that combine other metadata. The point is in a real DAM I can make it work with the limitations of LR, C1, On1.... both to read the labels they can write or write labels to XMP that they'll read and filter on.
I think Affinity can come up with a number of ways to make the raw conversion more like dedicated converters. Maybe something like a raw adjustment base layer that brings up the develop persona when selected with the settings always adjustable. They could facilitate copying raw settings in a number of ways without creating a PAM/PAMP/GAM or best of all DAM. If they do create a manager I hope it isn't as limited as the majority of requests on here are asking for. At the very least it would have to support all files types the current suite can edit. It must follow XMP standards so that if it didn't write metadata with the control and flexibility of IMatch it could sort and filter what I create in IMatch without mucking it up. I still stand by my post back on page 3, I'd rather they concentrate their resources on Photo, Designer, and Publisher. All amazing version 1 products. I look forward to paying for version 2.

Hi, while I'm not on the beta, cryptomatte is a feature, I would really appreciate for postproduction of renderings. Would implementing this be possible?
For those who don't know this, it's a render output in exr format, that holds masks for all the objects/materials/special tags for the entire scene and is starting to become the standard for post-production in softwares like Nuke or Fusion, it's also become available for Photoshop users thanks to the EXR-IO plugin recently.
It would be great to have this in Affinity Photo as well.
Cheers,
Ivan

Sometimes you want a mask to affect multiple layers, and the layers are in radically different parts of your layer stack, making grouping those layers impossible. It would be great if you could instance a mask between layers, so you apply the mask to layer 1, then apply the same mask to layer 2, and if you modify either mask, its instanced version is modified as well.
 
- Neil

I voted no. I use IMatch as my DAM and Capture One Pro as my main raw processor. I think it would take years to catch up to the power of IMatch as a DAM, and I'd rather they put the resources into Photo & Designer. I would like non-destructive raw processing in Photo, and I'd like to be able to copy and paste raw settings on a batch of photos, but neither would be top priority.
I once thought all in one management and processing was a great idea. I no longer think that way. LR is a rather weak DAM and it may be the best of the bunch in that regard compared to the other be all photo raw processors. Same goes for HDR and Pano. I wasn't even happy with the raw processing in the end which drove me looking for another does it all solution. I finally realized I already used a handful of specialized programs for HDR. I used PTGui Pro for panorama stitching with Affinity for finishing. So I changed my search to finding the strongest, most open DAM and a raw processor that was fast, had great color editing, and tethering. IMatch and C1 won out. Since I manage everything in a dedicated DAM, I don't hesitate to process a raw in Affinity,  or DPP if a certain image just isn't getting there in C1 (rare). Maybe I'll add DXO for it's reputed noise and geometry handling. Photo and Designer are great v1 programs, I look forward to them getting even better.

I voted no. I use IMatch as my DAM and Capture One Pro as my main raw processor. I think it would take years to catch up to the power of IMatch as a DAM, and I'd rather they put the resources into Photo & Designer. I would like non-destructive raw processing in Photo, and I'd like to be able to copy and paste raw settings on a batch of photos, but neither would be top priority.
I once thought all in one management and processing was a great idea. I no longer think that way. LR is a rather weak DAM and it may be the best of the bunch in that regard compared to the other be all photo raw processors. Same goes for HDR and Pano. I wasn't even happy with the raw processing in the end which drove me looking for another does it all solution. I finally realized I already used a handful of specialized programs for HDR. I used PTGui Pro for panorama stitching with Affinity for finishing. So I changed my search to finding the strongest, most open DAM and a raw processor that was fast, had great color editing, and tethering. IMatch and C1 won out. Since I manage everything in a dedicated DAM, I don't hesitate to process a raw in Affinity,  or DPP if a certain image just isn't getting there in C1 (rare). Maybe I'll add DXO for it's reputed noise and geometry handling. Photo and Designer are great v1 programs, I look forward to them getting even better.