Granddaddy

For 40 years on mainframe and desktop computers I've used software that produces endnotes and footnotes and intermixes them in documents. Surely the principles are well known at Serif. We await someone with the will, energy, and skill to implement the basics in APub.

Affinity Photo's panorama stitching has always worked very well with flat images ever since I bought it 2-1/2 years ago. At that time one of my first tests involved scanning a 36" x 8" horizontal panoramic photo taken in 1944. I used my very ordinary Canon 9000F scanner. I made no special effort but simply eyeballed what seemed to be a reasonable amount of overlap for each individual scan. I ended up with 6 individual scans across the 36" width of the photo, each scan being the full width of the scanner platen (roughly 8-1/4"). There are 125 people across the 36" of the original. The image stitched by APhoto seems perfect to my eye. I cannot detect any seams or distortions. The depth of field of the scanner is obviously adequate to compensate for the picture being raised slightly on the left and right sides of each scan where the photo hangs over the raised bezel around the platen. Or else APhoto was able to compensate somehow. There is no way to snugly fit a photo on very heavy photo paper on the platen when that photo hangs out both sides of the scanner by one to two feet. The paper measures 0.014" thick and is very stiff. much thicker than the photo paper I normally use.

I have similar problems with white balance and color casts on scans of 40-year-old Kodachrome slides that have faded and drifted from the original colors. The Info Panel can be helpful in making such white balance and color adjustments as described by this InAffinity tutorial "Accurate White Balance Using the Info Panel in Affinity" https://www.youtube.com/watch?v=QcNpK941_yk Perhaps stealing color grading from an image you like also works. I've never tried this technique from Affinity Revolution.

There is a concise summary of ways to remove color that includes large sample images showing the different results at InAffinity has published an abundance of Affinity Photo tutorials, including some on monochrome conversion Quick and Easy Variable Monochrome Conversion in Affinity Photo https://www.youtube.com/watch?v=fuv3jJRRIDY plus others in this search result https://www.youtube.com/channel/UCOnLUmyPHr2rayOHVHWsHVw/search?query=monochrome

Here's how it behaves in Windows. Don't know how it behaves on the Mac. Mostly I zoom with Ctrl-MouseWheel with my selected tool hovering over the point I'm interested in. The image zooms to that point while maintaining the relative position of the point and the tool within the window. It does not move that point to the center of the window. You can pan quickly by pressing Spacebar to activate the View (Hand) tool, but be careful as there is a bug in the Windows version that fails to return to the correct icon for the currently active tool when you release the Spacebar. So, if you are hovering over the bottom corner and use Ctrl-MouseWheel to zoom to that point then your active area will still be in the bottom corner of the window. I've seen posts from a couple of years ago that claims Alt-MouseWheel works also, but that is not my experience. If you go to Edit/Preferences/Tools the Preferences dialog includes a checkbox that says "Use mouse wheel to zoom". Checking that causes the mousewheel to zoom and Ctrl-MouseWheel to scroll. I leave it unchecked .

Simply pressing the Alt key as you would do to choose Subtract from selection returns the brush to visibility. But, of course, releasing the spacebar should restore the tool's correct pointer.

Clearly problems might arise when saving a document to a format other than the native format of the application. Possibly some functionality will not be saved when older versions of the native format are used. But it should also be remembered that saving to older formats and to formats understood at least in part by other applications is a time-honored tradition in desktop computing. For example, as a dinosaur I continue to use MS Office 2000. In that suite, Word 2000 offers to save documents in 28 different formats, including formats used by competing word processing applications. Word 2000, through a free addon, can also read the docx file format introduced with Word 2007. Excel 2000 offers to save files to 31 different formats, including spreadsheet formats of competing programs, as well as older Excel formats. I would welcome the option to save APhoto files to the Ver 1.6 file format that was so much smaller in size than the current format. It has never been explained what capabilities might be lost in such an APhoto file. Remember that the huge increase in file size that began with Ver 1.7 was attributed to a last minute change in the Affinity file format to accommodate features of APub, not features of APhoto.

I see this was reported three and four years ago and has never been fixed. It appears to be a problem in all Affinity apps on all platforms. https://forum.affinity.serif.com/index.php?/topic/37046-view-tool-gets-stuck-very-often-when-pressing-space-bar/ https://forum.affinity.serif.com/index.php?/topic/26366-ad-151-mac-problem-with-the-view-hand-tool-spacebar-shortcut/ Choose the Selection Brush Tool and select part of the pixel image. Press spacebar to activate View Tool (Hand pointer) to move document in the window. Release spacebar, expecting to see the Selection Brush pointer since that was the active Tool before pressing the spacebar. Instead, the Hand pointer remains visible, which should indicate that the View Tool remains active. In fact, the Selection Brush Tool did indeed again became active on releasing the spacebar, but APhoto is displaying the pointer for the View Tool. This becomes immediately obvious if you make the mistake of clicking on the image with the Hand pointer. On clicking the image, he pointer immediately returns to the brush outline and selects part of the image. How can this bug still exist after four years? It is incredibly annoying to have the wrong pointer displayed for an editing tool. Is there any point in users reporting simple, basic bugs given that no one pays any attention to us?

Hi @MikeA : You tag like this: type the @ sign and the first few characters of the name you want. You'll see a list of possible names. Click on the one you want. In your case I had to type in your entire name MikeA as there were so many names that began just with Mike. Just typing an @ in front of some existing text doesn't seem to work. You have to begin to key the letters following the @ Check out the private messaging options also if you just have a private message for someone. In Windows I right click on the person's tag and open in a new browser tab. It shows me their personal info and there is a button to click for sending them a private message.

As a new user, @MikeA might find it interesting to read the longish thread that began 1-1/2 years ago concerning the preferences dialog and its useless Search. If it's any consolation, APhoto support staff couldn't find anything in the keyboard shortcuts either. It's not us users, it's the misleading design of the software. https://forum.affinity.serif.com/index.php?/topic/68413-preferences-window-ui-is-frustratingly-designed/ This is another of the many basics that seriously under-staffed Serif hopes to get to someday. At present they seem fully engaged in fixing the horrific bugs that appeared on day 1 of the release of Ver 1.8. We can hope they are also developing a more robust beta testing protocol. If you let this get to you, you'll understand why PCMag.com describes Affinity Photo as miles behind the programs provided by the company that shall not be named. On the other hand, I keep using APhoto because APhoto has very powerful features and because I think APhoto's emphasis on non-destructive editing is the correct model to follow. The makers of other editors I own keep sending me links to tutorials that involve destructive editing for the simplest adjustments. I certainly don't recommend APhoto for the average photo hobbyist who is not especially computer literate and who does not enjoy wrestling with technical issues.

There are many threads about huge afphoto files. I'm surprised @walt.farrell didn't mention them, perhaps because they pertained to jpg image files rather than nef RAW files. In Ver 1.6, afphoto files were hardly larger than an original jpg file. Suddenly in Ver 1.7 afphoto files became 4 to 10 times larger. Various people explained this as being necessary and quite understandable. But it was also said this huge file size was the inadvertent result of last minute changes made to the file format to accommodate Affinity Publisher. Then suddenly in Ver 1.8, afphoto files have shrunk again to not much more than twice as large as original jpg files. Apparently the reasons given for huge file sizes in Ver 1.7 no longer apply. The reasons for huge file sizes remain a mystery to me, though it seems related to the way APhoto was storing the jpg information and they have changed that again. It is possible to reduce an existing huge Ver 1.7 afphoto to the much smaller Ver 1.8 afphoto size by replacing the Background jpg with a new copy and saving in Ver 1.8 format. Since Serif does not document how the file format works, everyone seems free to make their own guesses. I just hope the enormous files of Ver 1.7 never return. You might be interested in the threads involving jpg files saved as afphoto files, for instance, pointing to just a few: https://forum.affinity.serif.com/index.php?/topic/108445-affinity-photo-file-sizes-much-smaller-with-ver-18/ https://forum.affinity.serif.com/index.php?/topic/109395-version-18-a-rant/&do=findComment&comment=592338 https://forum.affinity.serif.com/index.php?/topic/109471-use-aphoto-18-to-reduce-huge-size-of-aphoto-17-files/ https://forum.affinity.serif.com/index.php?/topic/86287-huge-file-size/&do=findComment&comment=572511

It seems that everyone who purchases any Affinity product is enrolling in a beta program. How else to describe software whose native file format changes dramatically with every minor update? Affinity's formal beta program seems to lack systematic testing protocols that will detect significant problems with new versions before they are released. On the day Ver 1.7 was released (June 5, 2019) I reported that Ver 1.7 afphoto files were 4 to 10 times larger than Ver 1.6 files. I discovered this no more than 10 minutes after downloading and installing the new version. https://forum.affinity.serif.com/index.php?/topic/87186-file-sizes-in-photo-for-windows-170-split/&do=findComment&comment=461955 This huge increase in file sizes seemed to be a surprise to everyone. I wondered how it could have been missed in beta testing. If the developers knew about it, why had they not informed Affinity support staff? It was later explained that the file size increase was an inadvertent result of last minute changes in APhoto to accommodate Affinity Publisher features. It was also said that it was a problem only for jpg files, which had not been tested prior to release. I wondered how jpg files were avoided during testing since that's the most widely used image filetype of all. Effective beta testing requires the systematic examination of all features of the software. If beta testing consists only of waiting for a small number of dedicated users to report problems, then only problems with the few things that those dedicated users do all the time will ever be noticed. If beta testers shoot only in RAW, then they won't detect problems arising for the vast majority of people who simply use their camera's jpg files. I would be interested in trying the beta versions except that Affinity warns me that beta versions should never be used for production work. Testers are warned that the beta version could crash and all work could be lost. But worse than that is the fact that the file format might change at any moment and any previously saved work might also be lost. It could be that no version of APhoto will ever again be able to open an afphoto file saved by a beta version.

Sorry, it's a family photo involving my grandchildren. In recent years I mostly photograph people having the experience of discarding thousands of 35mm slides that my father and I took beginning around 1954. I found that only people photos mattered, that landscapes and flowers just weren't worth scanning for my descendants and other relatives. You could do your own testing using any photo you've previously saved with Ver 1.7 to test the effect. The one I chose to describe most recently in my thread describing how I was able to easily use Ver 1.8 to revise a Ver 1.7 file and save it at a much smaller size is just a bit more complex than the others I've played with. It was @Dan C above who told me that opening a Ver 1.7 afphoto file with Ver 1.8 and then using Save As under a different name will NOT reduce the afphoto file size. Hence I thought of replacing only the Background layer as it seemed likely that layer had most to do with producing huge file sizes in Ver 1.7. Obviously APhoto Ver 1.7 does something to the original jpg file that is now done differently in Ver 1.8. And Ver 1.8 cannot change that old Ver 1.7 data to the new Ver 1.8 format. It remains unclear to me why using Ver 1.8 to open an afphoto file originally saved using Ver 1.7 and then using Ver 1.8 to Save As under a new filename does not rewrite the document using the newer Ver 1.8 format for all layers, including the Background layer. It seems that only by deleting the Background layer copied in from the Ver 1.7 document can you actually force Affinity to use the smaller sized Ver 1.8 format. I've had responses from others explaining why the afphoto files must be so much larger than the original jpg from my camera, even when the afphoto file contains only an unedited jpg file with no adjustments. And then suddenly with Ver 1.8 such files are much smaller again, though still not as small as in Ver 1.6. As quoted above, huge file sizes introduced with Ver 1.7 were an inadvertent result of last minute changes made to accommodate APub. Apparently these changes had nothing to do with requirements for photo editing. That's why I'm now wondering why the afphoto format changes with every minor update to APhoto or to other applications in the Suite. Every decimal point upgrade introduces a new file format. I've not experienced such continuous changes in file formats in any other application I've used in the past 35 years.

Adding to the above, you can dodge and burn non-destructively in Affinity Photo. It's not something I've done myself. I tend to use curves adjustments on selections as I'm not good with brushes. See for instance these InAffinity tutorials https://www.youtube.com/watch?v=cCopkFkK1G0 https://www.youtube.com/watch?v=B5oYSKsvcJA Also possible on the iPad as Bethany shows at https://www.youtube.com/watch?v=12IYIbzhR2Q

All of my editing in the Ver 1.7 document was done non-destructively so only layers are involved. There were no changes made to the actual pixels in the Background image, which remains completely unaltered during the editing process. I also had added a blank pixel layer on which I did Inpainting using the Current Layer & Below option to fix blemishes and remove distractions. That kind of Inpainting does not affect pixels in the original Background layer. As for cropping, I indicated that I had to first Unclip Canvas for the Ver 1.7 document to get proper alignment with the new Background layer in the final Ver 1.8 document. Cropping in Affinity Photo is non-destructive by default. (I almost never crop Affinity documents as I prefer cropping at print time as I've described elsewhere.) My method will not work if you make changes to the pixels in the original background layer because I delete that original Background Layer from Ver 1.7. Complications might also arise with complicated child layer structures. All my layers, both Adjustments and pixels were above the single Background layer. It seems the key to reducing the file size is deleting that original background layer from the document and replacing it with a new copy of the original photo image. I have no idea why Affinity Ver 1.7 creates such a large file when storing that layer in the afphoto file. Nor do I know why using Ver 1.8 to simply resave a Ver 1.7 file does not rewrite the original Background Layer using the new Ver 1.8 format. It seems to imply that the Ver 1.8 afphoto file is a container for files in different formats from different versions of APhoto. Something similar happened in the upgrade from Ver 1.6 to Ver 1.7 when Ver 1.7 could contain both Ver 1.6 and Ver 1.7 versions of the same Live Filter Layer in the same file. See, for instance, my post at https://forum.affinity.serif.com/index.php?/topic/88132-affinity-photo-live-clarity-filter-in-ver-17-vs-ver-16/ Perhaps I should also mention that I am working with jpg files from my camera. I do not know about file sizes when using developed RAW files. I do not know what Affinity does to the jpg file when it stores the image in the afphoto file. I switched to Affinity Photo 2-1/2 years ago when I learned about non-destructive editing. I recognized Affinity had the better model for photo retouching and editing. I've used several different editors since getting into digital photography 18 years ago. None of them emphasized non-destructive editing. The dozen or more books I've studied using those editors never mentioned non-destructive editing. A major competitor for Affinity keeps sending me links to tutorials that emphasize destructive editing even for the simple things that Affinity does non-destructively. (No, not the company that shall not be named. I dropped that one 6 years ago when the new upgrade removed features I used regularly.) So I keep using Affinity despite my complaints. Affinity is improving in directions I like, but oh so slowly for an old, impatient granddaddy. Does anyone else think it unusual for a software application to change its native file format every time the current version is updated by only one-tenth of a version number? Is the direction ahead so unclear that the file format could not have been designed before coding the application began?