lenmerkel

You didn't get it for free before because you paid for AP or AD. It has nothing to do with Affinity. You got it for free because the new owner of the software (DxO) was offering it for free. They paid Google (the previous owner) for the rights to it (paid money for it), have upgraded it, and are now offering the upgraded version to buy. That's all.

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).

As one or two others have said, this image has large areas of heavily underexposed and overexposed pixels. Particularly, in the heavily overexposed areas there is no information to recover. Essentially, the dynamic range of the original scene is significantly wider than your camera's sensor is capable of recording accurately. It's a great example of a situation where you'd take bracketed exposures, then run through the HDR tools in Affinity Photo to combine them. I took the liberty of opening your raw file in my copy of FastRawViewer. I use this software for initial examination & culling of my raw files, as all of its analysis and displays are based on the actual raw data, and not any rendering (e.g. an embedded jpg preview). The first image shows the overexposed and underexposed areas. The black parts of the sky have no usable data, meaning that all 3 channels are "blown out". It's not possible for any highlight recovery tool to recover data that isn't there. The next image shows the raw histogram (i.e. the distribution of sensor channel values as captured by the camera sensor). EV0 corresponds to middle grey, and is typically 3 stops below a camera's saturation level. Note that you have several sensor points between EV0 and +3 stops. These are sensor points where some recovery might be possible. You then have a bunch of sensor points above +3 stops - the saturation level. These are basically blown out for good - there's nothing to recover. The final image shows the number and percentage of sensor points considered under or over exposed. The last column shows overexposure data if positive exposure compensation were to be applied (simulating the "hidden" exposure compensation applied by Adobe's Camera Raw). As you can see, there are a lot of overexposed sensor points, particularly in the green channel, which is where most image detail is derived from.

As Alfred has said, your "300" and "72" numbers are DPI, and that is irrelevant for the web. It is only a hint to printing software that you want to physically print that number of pixels per linear inch of medium (e.g. paper). Changing an image's DPI does not change the number of pixels in an image - it only changes that hint. It is essentially just metadata (which applications can choose to honor or ignore), and is one of the most widely misused and misunderstood terms in digital imaging. As R C-R has said, it is the actual pixel dimensions that defines the resolution of your image. A 1500px by 1000px has exactly the same resolution, regardless of what you set the DPI inside it. I understand you don't want to upload a sample image. What would be helpful is if you could let us know the pixel dimensions of your original image, and the new dimensions you want to create in your downsampled image. For example, original is 6000px by 4000px, desired new image is 600px by 400px.

Well, if it were just a matter of exporting a jpeg, it would be simpler. However, as you are resampling, then as R C-R says, it does get complicated. With resampling, you are either removing pixels (downsampling) or artificially adding pixels (upsampling). Each process requires different algorithms for best results, and while the details "might" be boring, understanding them will help you get better results. Go ahead and read the articles first, then come back for more help if you need it. BTW, would it be possible for you to reply and attach a sample "before" image, and briefly describe what you're trying to do? E.g. "I want to downsample the image to exactly xxx pixels by yyy pixels, and save as JPEG with 95% quality (compression)".

Honestly, the "best" option is the one that gives you the results you like. I recommend trying each option for one particular image and see which works best for you. Sometimes it needs a little trial & error. Here are some resources that explain the differences between the various re-sampling methods. They all refer to Photoshop, but the principles are the same. https://support.esri.com/en/technical-article/000005606 http://www.dummies.com/software/adobe/photoshop/how-to-resample-images-in-photoshop-cs6/ https://www.photoshopessentials.com/essentials/resizing-vs-resampling/ http://www.graphics.com/article-old/fundamentals-resampling-photoshop

Wonderful news, ordered today!

I sense an early Christmas gift coming my way. Nice!

All 8 plugins are working for me on version 1.6.0.89 (Win 7 SP1).

So here's Adobe's published specification for its proprietary PSD & PSB file formats: https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/ To fully support exporting to these formats (including editable layers), the Affinity products would need to map their own internal document structures / data to those represented by the formats, or develop complex structure / data translations where such mapping isn't one-to-one. In some cases, this may not even be possible. I imagine such an undertaking would be none of quick, easy nor inexpensive.

I think the last comment from MEB in this post explains it. "Currently it's not possible to export text as native PSD text when exporting to PSD. We do intend to implement this in a future version but it may still take a little since it's not something easy to achieve."

As a temporary solution until a new release is made available, you can open the help in a regular web browser (the help is HTML based). In Windows Explorer, navigate to folder "%PROGRAMFILES%\Affinity\Affinity Photo\PhotoHelp\Contents\Resources\de.lproj". Then double-click on file index.html to open it in your default web browser. Now the help is available and independent of Affinity Photo. The last part of the folder path (de.lproj) points to the German help. There are other folders at the same level that point to the help in other languages. Via Google Translate: Als temporäre Lösung, bis eine neue Version verfügbar ist, können Sie die Hilfe in einem regelmäßigen Webbrowser öffnen (die Hilfe ist HTML-basiert). Navigieren Sie im Windows Explorer zum Ordner "%PROGRAMFILES%\Affinity\Affinity Photo\PhotoHelp\Contents\Resources\de.lproj". Doppelklicken Sie dann auf die Datei index.html, um sie in Ihrem Standard-Webbrowser zu öffnen. Jetzt ist die Hilfe verfügbar und unabhängig von Affinity Photo. Der letzte Teil des Ordnerpfads (de.lproj) verweist auf die deutsche Hilfe. Es gibt andere Ordner auf der gleichen Ebene, die auf die Hilfe in anderen Sprachen zeigen.

Do you have a pixel layer selected (e.g. Background)? I believe the inpainting Brush only works on pixel layers (as you're painting pixels).

You're welcome!

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