Jump to content
You must now use your email address to sign in [click for more info] ×

Asser82

Members
  • Posts

    141
  • Joined

  • Last visited

Everything posted by Asser82

  1. Nice work, Hopefully GPU acceleration on windows will also get some love in the future. In addition a Lightroom like app would be cool, where a virtual copy of a raw file could be edited in Photo via Studio Link.
  2. There is a keynote in two days. There we will see, what comes next after Publisher. At least it is announced that way.
  3. Perhaps offer two denoise algorithms: 1) Fast and ordinary one (default) 2) Slow and perfect one (option) The ones, who select 2) have time to wait. The ones who do not care (1)), have fast develop times. Same strategy works well in DxO PhotoLab with ordinary denoise and prime denoise.
  4. I have also written to a resposive forum moderator to shortcut you to the NIK department, so hopefully things will go the right way. At least we will now, which side has work to do :-)
  5. I have already reposted the current progress here. https://feedback.dxo.com/t/maybe-improved-nik-support-in-affinity-incoming/7907 But speaking developer to developer would speed up things.
  6. 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.
  7. 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 :-)
  8. I think every developer hopes, that Windows 7 dies sooner than later. It is enough too deal with different .NET versions on Windows 10. What makes me wonder is that Serif does not publish payed major versions of Affinity Photo, like other companies do with their softwares. Since I bought the first version for Windows, there was every new release for free. Because I am only interested in photo software, which has nothing to do with Apple, and DAM software, there has been no further revenue from me. So hopefully people buy all the other stuff, so that there is enough income. :-)
  9. 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/
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Hope this is not the result of meltdown/spectre mitigation updates...
  20. When I am at home I will try to use the exiftool to restore the metadata. Should be something like that: exiftool -X -b -makernotes -all a.jpg > a.xml Work with Affinity Photo exiftool -tagsfromfile a.xml -all:all a.jpg Perhaps -all arguments can be removed, if the problem lies in makernotes only. If this works, I will write a batch automation application while this is not addressed.
  21. It might be the Makersnote, but the delta seemed to be much greater. I would not expect the metadata to be changed at all, except maybe the modification date and the creator tool. Lets discuss this in the bug forum, so we do not have two places to look at. Goto here:
  22. I have this problem also: I import my Canon RAWs in Lightroom and develop the JPEGs in DxO PhotoLab. The lens information produced in the JPEGs is OK at that point, because Lightroom combines the CR2 and the JPEG under the same lens filter (Canon EF-S 18-135mm f/3.5-5.6 IS STM) after DxO export. Now I want to remove red eyes inside the exported JPEG in Affinity Photo. What comes out is a JPEG with broken metadata. DxO can no longer find the lens that belongs to the Photo, Lightroom assigns the Photo under an own Lens Category which is different from the one of the RAW. Parsing the Affinity modified JPEG with "ExifTool" reveals that many of the Canon specific metadata tags have been lost. This is a serious bug and makes AF photo unusable in environments, where tools must work together.
  23. I have started with Lightroom 6 + Affinity also. But the created TIFF sizes were to much for me, so I have changed my workflow further. I just do not want to spend >100MB on each photo.
  24. This is also the reason btw. why Adobe can do what they want. They just have "locked in" all their users, because the users do not want to loose their edits while switching to another tool. Even if the develop results are bad compared to others tools. As long at there is not a standard raw format and develop process defined by IEC or something and as long as all camera manufacturers have their own format, nothing will change. So you have to make a hard break at some point, where you use Lightroom for your "before 2018" catalogs and create new catalogs or workflow within a new tool.
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.