Asser82

DxO is becomeing more customer oriented. There is a public feature request board available. You can now vote for official Affinity support for NIK here: https://feedback.dxo.com/t/official-support-of-nik-plugins-with-affinity-software/3283/1

The more interesting question is, why the Affinity guys comment things on sundays, instead of turning their steaks on the grill. Hopefully this does not end in burnouts.

If something gets updated, it is not a new installation. Hence, the configuration is not necessary. Just look at it like on an update to your browser or your office package. You can't place it on each update into a new folder. If there were no disabled fields, the desire to change something wouldn't be there. So hiding the disabled items is the simplest solution to avoid unintended feature requests, which saves development time to work on real problems. So the beta run had a sense already. Btw. having these fields active and functional would not be an improvement, because it would make the user think, whether the destination is the same he used last time. He would have to open the windows explorer or the available file dialog to compare the paths, which is an ugly thing. My guess is that 99% would like to replace the existing beta, the others can do a clean install.

First my heart jumped...because I thought spotlight might be the Affinity lightroom. But thinking about it, I remembered, that I read a RAW vs JPEG article on spotlight yesterday, which was great. So, thx for this.

Yes, I also do not understand why a print layouting tool is preferred to a DAM / RAW tool. Looking at the Facebook follower of Adobe products: Photoshop: 7.6 Mio -> Affinity Photo Illustrator: 1.5 Mio -> Affinity Designer Lightroom: 1.4 Mio -> Missing InDesign: 0.7 Mio -> Affinity Publisher the Lightroom clone should come first, because it has a twice as large user base. But maybe such a tool is harder to make, because of the different RAW formats, camera/lens profiles, metadata stuff and undocumented raw features. Hence the decission, to postpone it to later. Making a DAM tool can really be a time sink.

Ah, good to know, thx.

Maybe some sort of user defined preset or template functionality could help which could be applied as default starting point, when the user opens a raw. This way the user could set up the settings from the video as default preset. Today's raw tools tend to do more 'Auto' with more or less success.

And if you make a DAM, please make the window which contains the preview tiles dockable. This will allow the user: 1) to dock it to the centre to see many tiles at once. 2) to dock it as filmstrip to the bottom to place a large preview window to the centre for culling It would also work with 1) only, but would not be that flexible.

Cool finding, comment at the bottom: raw.pixls.us is used by darktable for regression testing of rawspeed and by RawTherapee. It is available for any projects that need access to a library of raw files.

The meltdown patch has strong influences on SSDs. The faster they were, the more impact the patch had. Loading from old school hard drives was nearly not affected, loading from SATA SSDs was affected, loading from M2 SSD was strongly affected, all in realation to the speed before. When a tool like Affinity Photo starts up, it is the timepoint, where it performs the most IO operations. It loads assemblies, it loads fonts etc. Each IO operation needs a context switch into the kernel, where the bottleneck lies after the patch. After everything is in memory and nothing has to be written to disc or sent via network, there is no performance decrease. This is why games run nearly as fast as before (-5%), where all the cloud storage provider cry about >= 30% slowdown. Their servers do almost IO only. No one knows whether the problem lies in it, but it could be one of the reasons. Maybe Affinity Photo is more IO intense than others, or Dave has a large library of something, which is loaded when Affinity Photo starts up.

Lets hope that these are not the effects of the meltdown patch, which came around that version. If you have an older Intel processor, then you could see IO based slowdown.

@Mark Ingram If you need some inspiration, have a look on IMatch. Not from the usability and visual design point of view, but from its capabilities and the possibility to be used with different raw development tools. Looking at it, Lightroom becomes really limited. Especially the metadata, version and buddy file handling are unique. Maybe this can help to make the right decissions. Wish you good luck.

If you really make an Affinity Darktable, please consider: Hierarchical Collections, Smart Collections, Possibility to display photos in a whole directory subtree, XMP Import/Export, Batch Metadata Editing, Hierarchical Keywords, Search by Metadata Tags, Pass raws to external development tools (not as tiff), Stacks, Virtual Copies, Autostacking Raws and (jpeg/tiff)-versions using Regex on name or metadata, Token based batch renaming and destination folder definition on import and inside catalog. There are so many companies like On1, that bring out only partially usable DAM solutions.

Oh, I like to speculate: Only unprocessed files from cameras are wanted, because you do not want to loose internal metadata like maker notes and you want to get real raw data instead of some linear DNGs or similiar. This is usefull for: 1) Testing and improving the raw engine (Needed for Demosaicing, Noise Reduction, Lens Correction, Lens Sharpness, etc). Also needed for regression and performance tests to measure how development goes. 2) Implementing a DAM / LR like tool, which imports OOC JPEGs and RAWs. (Here especially the preview generation and metadata extraction could be tested). If I would develop this, I would use LibRaw for previews and an ExifTool wrapper for metadata. Cold, Warm or Hot? :-)

Hope this is not the result of meltdown/spectre mitigation updates...