Asser82

Yes, this is also what I see, that Mac is more on track concerning performance increase through GPU usage. Windows supports many graphic cards, but it does not matter, because in the end all graphic cards use chips from AMD (Readeon), NVidia (Geforce) and Intel (CPU integrated, more dedicated in the future). Above the hardware/driver layer there are abstractions in form of DirectX, OpenGL and Vulcan. So if we are on Windows, just target DirectX 11/12, if Vulcan is too experimental and OpenGL too geeky. Fallback to software renderer where needed. I mean, games do it all the time. The "only" thing that you need is a "game engine" which manages the working parts and distributes them efficiently to the available processing units. I think, the main reason, why we see minor progress here is a growing code base (no green field engineering any longer), increased number of products and with it the lack of resources. Google says Serif has 190 employees. Now take 100 out, which cannot write code, divide the remaining into 2/3 Apple and 1/3 Windows factions, because for Apple there is Mac and iOS. For the remaining 30 people, distribute them over designer, photo and publisher and maybe some non announced products. What remains for Photo on Windows is maybe 10 people, where some must be educated, visit fairs like MSBuild, become parents or get ill. The remaining 8 person years per year for development is not much to make big jumps. Hopefully the team is not hit further through brexodus, because development teams tend to be international, and new employees (if there are any) do not contribute much in the first years to the overall progress.

Sadly the development speed of Affinity Photo for Windows started to feel very slow. If someone, like me, is not interested in Apple products in general, then the last release (not beta) in the photo domain was 1.6.5 from August 22, 2018. It is almost 9 months now. Time for a new baby :-)

Just for your information: There is a new release of the DxO NIK, which has targeted some crashes with Affinity Photo on Mac. They are explicitely working on a better compatibility with Affinity Photo now: https://nikcollection.dxo.com/release-notes/

Or you buy AcdSee Pro for around 50€/$. It replaces Lightroom very well in terms of DAM for me and the payed amount is a one time fee for many years.

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

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.

@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? :-)

Yes please. Lightroom seems to use them too. If this is going to be fixed, please ensure that the before and after jpegs are shown under the same lens name in LR when the user filters by lens. I do not know, what else depends on maker notes and which workflows are broken by striping them away. Thx.