lenmerkel

Hi, I'm just about to retire after 43 years in the software industry, and I'm still dealing with TLAs (as per Alfred)! Many years ago, in a bar somewhere in London, and after some serious lubrication, I remember a competition with some IBM engineers to come up with the true meaning of the acronym. I believe the top 4 answers were:
 
4. I've Been Moved (flexible office assignments).
3. It'll Be Monday (we're there for you, but not on weekends)
2. It's Broke Mate (definitive summary of problem analysis).
1. International Brotherhood of Magicians (my personal favorite).

No, AP is just a tool. There are no jobs for hammer experts either. For carpenters there are plenty.

It will be this month, perhaps next week, through the Affinity Store, and described in a marketing page like the Designer Workbook one. I would expect an announcement like Ash made last time for the Designer Workbook, or a post on the blog announcing it as available. It's en-route to (Amazon) the fulfilment centres right now in English and German, and will be sendable to the same countries as the Affinity Designer Workbook. Some countries (like Switzerland, China & Russia ) are not in the list of countries that our fulfilment partner offers, but most major other countries can be sent to.

I think Tony said that we would at least consider any platform where we can make our investment back.  So, for Linux - that'll be $100,000 a copy for each of the five users for us to break even.   ;)  :P

Oh, I agree completely (says the idiot who works in print).
 
I still have companies I do the odd manual for. Such technical and reference manuals may be dying, but they aren't dead yet. But the industry as a whole has pretty much abandoned them. I believe it is largely due to users demanding lower cost software over the years & companies deciding they like larger profit margins. I mean, I paid over $2k for Ventura Publisher and its various modules/applications in 1989. There was quite a box of manuals. Same with CorelDraw, Illustrator and the others. I paid a lot for software/hardware when I started that business. But think about it, the software cost was large, employee costs were a fraction of today, real-estate was inexpensive, taxes were way lower. They had the "extra" money to spend on such things.
 
I wrote and illustrated 30 to 40 technical, reference and user manuals between 1989 and 1992. Some of those companies are still around and still updating, adding and creating new manuals. They are a heck of a cost burden for a modern company to bear--despite what these recurring studies show.
 
One of these days I'll be able to sit on the porch in a rocking chair, G&T in-hand, and opine about the good ol' days that have completely vanished. Oh, wait. I guess I do that now...

We know about the PSD format specification, but this is only part of the story.  The specification is in no way complete or well explained.
 
The working of the Text Engine is undocumented.  We have our own text engine, which is different to the Ad0be one.  We import editable text from PSD as best we can, but we have to convert the data. PSD export requires us to do even more work - it is an area which we hope to do in the future, but will take some considerable effort. It's not enough to say that we will just offer "editable text" - it also has to have as small amount of differences when the exported PSD is loaded into Photoshop.  Not easy to do, and not something you will find other (if any) third party apps doing.
 
From experience, we've not found another third party app that can fully support editable text import from PSD.  We've only recently worked out how to deal with part of it after some considerable effort.

That's very observant. B)
 
Base on some tests (monitoring Windows processes), it appears that Photo starts a new ExifTool process each time it reads metadata from an image, then kills the process when it's done. If that's the case, there's a significant performance hit. ExifTool is written in Perl, and a new instance of ExifTool needs to start a new Perl runtime environment - this is a little expensive.
 
ExifTool has a "server" mode which allows a single ExifTool process to be started and remain resident, processing piped commands. This limits the Perl startup overhead to a one-time hit and significantly improves performance. I can personally attest to this, as I have developed my own utility software that "wraps" around ExifTool, utilizing this mode. It's much faster.
 
Maybe the Photo development team could look at implementing this? It's documented under the -stay_open FLAG section here: http://www.sno.phy.queensu.ca/~phil/exiftool/exiftool_pod.html

That's very observant. B)
 
Base on some tests (monitoring Windows processes), it appears that Photo starts a new ExifTool process each time it reads metadata from an image, then kills the process when it's done. If that's the case, there's a significant performance hit. ExifTool is written in Perl, and a new instance of ExifTool needs to start a new Perl runtime environment - this is a little expensive.
 
ExifTool has a "server" mode which allows a single ExifTool process to be started and remain resident, processing piped commands. This limits the Perl startup overhead to a one-time hit and significantly improves performance. I can personally attest to this, as I have developed my own utility software that "wraps" around ExifTool, utilizing this mode. It's much faster.
 
Maybe the Photo development team could look at implementing this? It's documented under the -stay_open FLAG section here: http://www.sno.phy.queensu.ca/~phil/exiftool/exiftool_pod.html

Hi Pete, I think you've rather answered your own question. Photo is a pixel editor, while LR is a parametric editor (as are most raw converters, like DxO Optics Pro, which I use). 
The advantage of parametric editing, as you pointed out, is that the software only stores editing instructions. The disadvantage, to many, is that you have no control over the sequence in which those instructions are executed in order to render an output image. The instruction processing pipeline is baked into the software. The sequence in which you actually apply your edits is ignored. Plus, you simply can't achieve the same fine level of control you can with a pixel editor.
 
If the sequence of edits is important to you, or you want to change them (e.g. repositioning layers), it's hard to see how a parametric editor could enable you to do that. That's when you need a layer based pixel editor.
 
It boils down to what kind of editing you need to do, and how much control you need, or are prepared to sacrifice.

To put this into perspective, let's first remember that the .afphoto file isn't an image file (or an image format). It's a project file, that contains everything you do in a Photo editing session for a specific image file. Its whole purpose is to allow you to save your editing work when you exit Photo and return to where you left off when you restart it. It contains your edits in a non-destructive form, so you can go back in time and change your mind about individual edits, etc. That potentially adds up to a lot of information to save.
 
Let's revisit some numbers from your specific example.
Your image is approx. 8,700 x 5,800 pixels. This gives us a total of 50,460,00 (about 50 megapixels).
 
When you develop this in Photo, you automatically get a background pixel layer. This layer will be 16 bits/channel (unless you chose the 32 bits/channel HDR option in the develop assistant). 16 bits is of course 2 bytes. Your pixel layer is RGB, so there are 3 channels (Red, Green, Blue). Therefore, your pixel layer will be approx. 50 (megapixels) x 3 (channels) x 2 (bytes) = 300 megabytes.
 
You added a pixel layer. Not knowing the inner workings of Photo (or the .afphoto format), I'm guessing this pixel layer is also 300 megabytes by the same logic as above. In fact, it's probably more, as the "transparent" pixels you refer to are likely still there in the pixel layer, just marked as transparent in some way, and this marking would also take up some memory. After all, you can always come back and change this layer to broaden or narrow the transparent selection, so the pxiels would still need to be there in the pixel layer for you to be able to do that. So, now we have 600+ megabytes.
 
Now we add in information recorded about the other non-desctructive edits you've made, like sharpening (recorded so you can later manipulate them again, view them in history, etc). Some more megabytes. Finally, it's possible that Photo also records some information from your original raw file and/or the Develop process (though that's just a wild guess). If so, still more megabytes.
 
Note that some of the calculations above are estimates, and there are some assumptions about how Photo stores info in your .afphoto project file. Nonetheless, it's probably a fairly reasonable guess as to how in your case you could end up with a 700 megabyte project file. Not sure there's much that can be done to get around this if you want to maintain project files. ;)

Hi Pete, I think you've rather answered your own question. Photo is a pixel editor, while LR is a parametric editor (as are most raw converters, like DxO Optics Pro, which I use). 
The advantage of parametric editing, as you pointed out, is that the software only stores editing instructions. The disadvantage, to many, is that you have no control over the sequence in which those instructions are executed in order to render an output image. The instruction processing pipeline is baked into the software. The sequence in which you actually apply your edits is ignored. Plus, you simply can't achieve the same fine level of control you can with a pixel editor.
 
If the sequence of edits is important to you, or you want to change them (e.g. repositioning layers), it's hard to see how a parametric editor could enable you to do that. That's when you need a layer based pixel editor.
 
It boils down to what kind of editing you need to do, and how much control you need, or are prepared to sacrifice.

To put this into perspective, let's first remember that the .afphoto file isn't an image file (or an image format). It's a project file, that contains everything you do in a Photo editing session for a specific image file. Its whole purpose is to allow you to save your editing work when you exit Photo and return to where you left off when you restart it. It contains your edits in a non-destructive form, so you can go back in time and change your mind about individual edits, etc. That potentially adds up to a lot of information to save.
 
Let's revisit some numbers from your specific example.
Your image is approx. 8,700 x 5,800 pixels. This gives us a total of 50,460,00 (about 50 megapixels).
 
When you develop this in Photo, you automatically get a background pixel layer. This layer will be 16 bits/channel (unless you chose the 32 bits/channel HDR option in the develop assistant). 16 bits is of course 2 bytes. Your pixel layer is RGB, so there are 3 channels (Red, Green, Blue). Therefore, your pixel layer will be approx. 50 (megapixels) x 3 (channels) x 2 (bytes) = 300 megabytes.
 
You added a pixel layer. Not knowing the inner workings of Photo (or the .afphoto format), I'm guessing this pixel layer is also 300 megabytes by the same logic as above. In fact, it's probably more, as the "transparent" pixels you refer to are likely still there in the pixel layer, just marked as transparent in some way, and this marking would also take up some memory. After all, you can always come back and change this layer to broaden or narrow the transparent selection, so the pxiels would still need to be there in the pixel layer for you to be able to do that. So, now we have 600+ megabytes.
 
Now we add in information recorded about the other non-desctructive edits you've made, like sharpening (recorded so you can later manipulate them again, view them in history, etc). Some more megabytes. Finally, it's possible that Photo also records some information from your original raw file and/or the Develop process (though that's just a wild guess). If so, still more megabytes.
 
Note that some of the calculations above are estimates, and there are some assumptions about how Photo stores info in your .afphoto project file. Nonetheless, it's probably a fairly reasonable guess as to how in your case you could end up with a 700 megabyte project file. Not sure there's much that can be done to get around this if you want to maintain project files. ;)

To put this into perspective, let's first remember that the .afphoto file isn't an image file (or an image format). It's a project file, that contains everything you do in a Photo editing session for a specific image file. Its whole purpose is to allow you to save your editing work when you exit Photo and return to where you left off when you restart it. It contains your edits in a non-destructive form, so you can go back in time and change your mind about individual edits, etc. That potentially adds up to a lot of information to save.
 
Let's revisit some numbers from your specific example.
Your image is approx. 8,700 x 5,800 pixels. This gives us a total of 50,460,00 (about 50 megapixels).
 
When you develop this in Photo, you automatically get a background pixel layer. This layer will be 16 bits/channel (unless you chose the 32 bits/channel HDR option in the develop assistant). 16 bits is of course 2 bytes. Your pixel layer is RGB, so there are 3 channels (Red, Green, Blue). Therefore, your pixel layer will be approx. 50 (megapixels) x 3 (channels) x 2 (bytes) = 300 megabytes.
 
You added a pixel layer. Not knowing the inner workings of Photo (or the .afphoto format), I'm guessing this pixel layer is also 300 megabytes by the same logic as above. In fact, it's probably more, as the "transparent" pixels you refer to are likely still there in the pixel layer, just marked as transparent in some way, and this marking would also take up some memory. After all, you can always come back and change this layer to broaden or narrow the transparent selection, so the pxiels would still need to be there in the pixel layer for you to be able to do that. So, now we have 600+ megabytes.
 
Now we add in information recorded about the other non-desctructive edits you've made, like sharpening (recorded so you can later manipulate them again, view them in history, etc). Some more megabytes. Finally, it's possible that Photo also records some information from your original raw file and/or the Develop process (though that's just a wild guess). If so, still more megabytes.
 
Note that some of the calculations above are estimates, and there are some assumptions about how Photo stores info in your .afphoto project file. Nonetheless, it's probably a fairly reasonable guess as to how in your case you could end up with a 700 megabyte project file. Not sure there's much that can be done to get around this if you want to maintain project files. ;)

If the final version of Photo is released on my birthday (December 9th), it is going to be more than a perfect day!  :)

As far I can see half of the videos do not have subtitles, as I am deaf. Please include them. I am having to go through some of the videos over ten times without subtitles and still cannot figure it out how it had been done.

The vast majority of Windows applications (including File Explorer in Win10 and Windows Explorer in Win7) don't actually retrieve image file thumbnails for display by themselves. They rely on codecs installed in Windows. Windows has built-in codecs for common image file types, including JPG, PNG, TIFF, etc. However, for raw files from various camera manufacturers, codecs are typically installed by that camera manufacturer's raw processing software if/when you install it in Windows. I believe Affinity Photo installs a codec for AFPHOTO files. Sometimes the raw codecs are poor quality and/or slow, and sometimes not available at all. An alternative is to install a 3rd-party codec pack, such as the Fast Picture Viewer Codec Pack. It isn't free, but it isn't expensive either. (Note: I have no association with the company - I'm just a very happy user who's had it installed for several years.)
 
Attached is a capture of the Affinity Photo File>Open dialog in a folder containing several image types (JPG, TIFF, DNG raw), as well as an AFPHOTO document. All display thumbnails as expected. Incidentally, the same thumbnail (and metadata viewing) support works directly in File explorer / Windows Explorer, which is essentially what's being displayed in the File>Open dialog.

Any chance of publishing a hash (MD5, SHA1, SHA256) with the download Link? It's handy to be able to verify largish downloads like these.

Ah, I see. I also noticed from your later post you're a Pentax user. Me too! Still shooting with a K10D (and saving to DNG).
 
I personally prefer to save sidecar files rather than write to the DNG (faster saving of changes, as Ablichter pointed out, is one reason). The main rationale though is that I use DxO Optics Pro for raw development, and it writes out its own sidecar files with raw development settings, in DxO's proprietary format. There's no easy way to embed that in a DNG, so sidecars are the only option.
 
My DAM tool takes care of syncing other metadata with the DNG (i.e. XMP, EXIF, IPTC) when I choose to do so, but not raw development settings. It also takes care of managing my raw files with their sidecars as "units".
 
Be aware that the raw development data that Adobe Camera Raw writes to your DNGs is written as embedded XMP data, in a namespace specific to Camera Raw, not surprisingly called the "Camera Raw Namespace". What this means is that the raw development data is proprietary to Adobe, and is completely specific to Adobe products (Camera RAW, Photoshop, and possibly Lightroom). It has no meaning to other raw processing software, because every raw processing software applies its own unique algorithms, settings, etc. The data are not transposable between softwares.
 
Consequently, for Affinity Photo (or any other raw processing software, like DxO Optics Pro, AfterShot Pro, Capture 1, etc) to write its raw development settings to your DNGs, the Adobe Camera Raw namespace is useless, and the developers would need to define their own custom XMP namespace to hold values that make sense to their software. I can't imagine it would be worth their while to do so. There is no "universal" way to describe raw development settings, as their is no "universal" raw processing software. Thank heavens, or we'd all be stuck with a choice of 1 raw workflow. :o
 
Your workflow of requiring to store raw development data in your DNGs limits you to using Camera Raw for raw development, I'm afraid.
 
Len

I think that to get the best out of a processor/memory-intensive program like AP, you might want to treat yourself to some hardware upgrades. The Intel Core Duo, while it has a reasonably fast 2.66 GHz clock, only has 2 physical cores. Most modern photo editing apps thrive on having multiple cores available. Upgrading to a 4-core processor with hyper-threading would help. Undoubtedly though, your system performance is mostly constrained by RAM. 4 GB just doesn't cut it I'm afraid. I would think that 8 GB would be the absolute minimum for memory-intensive apps like AP. I would personally recommend 16 GB for more "wiggle-room" - AP would certainly benefit from that. I'm not familiar with your graphics card, but be aware that AP will pefrom best when it can take advantage of the processor and RAM in the card. The faster the GPU in the card, and the more card memory, the better your overall experience will be. Just my 2 cents.
 
Len

I find Affinity Photo to be way more "intuitive" than Photoshop. Probably because I've never used Photoshop. :o
 
Seriously though, evaluate Affinity Photo on its own merits. Don't compare it with Photoshop, or whatever software you've used before. Of course it won't work exactly the same. Of course it will have some learning curve. Treat that as an excuse to re-evaluate the way YOU do things - don't limit yourself to the way your existing software does. Who knows, you might learn something new, discover new opportunities, and enjoy yourself along the way.
 
Len

If you are not aware of this the famous Nik Collection is a collection of great Photoshop filters that you have to install into Photoshop for some really great effects for photos and pictures alike. Now once the Nik Collection was expensive business and you had to pay for those.... but now the people at Google purchased the lot and give you them as a FREE download. Lucky sausages!
 
Here is the link if you wish to take a peek at the site and see what all the fuss is about....
 
https://www.google.com/nikcollection/
 
Here are some snap shots for you to peruse of the Nik Collections working on my system using the first Beta version of Affinity Photo...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
All the filters are working perfectly and are saving normally as you can see from the pictures here!
 

Hello,
 
     I am currently editing my first Nikon .NEF file in AFFINITY 1.50.35 and the screen refresh from moving the sliders is excellent.  A small but import criticism is that the split screen showing before and after is swopped (in my opinion).  It is more comfortable and more logical (thanks SPOCK) the other way around.  After all we say 'Before and After' not 'After and Before'.
 
I shall continue using AFFINITY (good name by the way).  Let me know if this is the sort of feedback you want please?
 
cheers
Ian