Amateur John

Still not fixed at 1.7.3.481 release and 1.8.0.532 beta.

I think that a glossary of technical terms would be a useful addition to the present documentation for all three of the applications. It is too easy for writers of documentation aimed at new users to assume more user knowledge than they have. I fell into that trap while documenting an engineering database. I was soon 'put right' because I worked in the same office as some of our users.

A simple curve seems to do a reasonable job, but I suspect that the Develop Persona also makes more complicated changes which depend on the histogram of the original file.

I also find this more of a bug than a feature. The macro workaround is fairly satisfactory but not ideal. Please, what do the developers say.

Don't forget that a file could be copied and renamed at an OS level. Publisher could not act on that. I think that the program's action is correct. It would be helpful to draw more attention to the fields in the help documentation in the sections on document creation. We should be updating author and other fields. That is our responsibility not the program's. There may be times when we do not want the title to be the filename Elsewhere in the forums there are comments about transfering master pages from one document to a new document. Copying and renaming a file plus manually updating the fields is a simple way of achieving that and avoids further complicating the program. Again documentation, or even something in one of the tutorials would be helpful.

Sorry folks. I was missing the fields panel. A default title is set according to the initial file name. I needed to change it when I changed the filename. I hope that I have not wasted anyone's time.

I would like to save an existing afpub file as a new file and then work on it to create a new document using much content from the original file. This seems to work fine until I export a pdf file and open that file in Google Chrome or Firefox. The tabs show part of the old filename, not the new. This is not a problem with Acrobat reader or Internet explorer since they identify tabs by the new filename. I am not including history. Am I missing something?

The afphoto file created by a default develop is an RGB 16 bit per channel non compressed file. No information from the raw file (typically 12 or 14 bits) is lost. That implies that HSL can be done just as well in afphoto as in ACR. I suspect that the detractors are hardened Adobe users who are very set in their ways. You may find that the afphoto file looks flat because the default curve applied during development is not aggressive. If you disable that curve then the result looks even more flat. Some people like to start from the flat state. Expert videographers, for example, demand flat files so they can create consistant colour grading. If you want to start editing from an image that looks like the jpeg preview on your camera screen, a perfectly reasonable way to work, then you can do your raw conversion to 16 bit tiff using your camera manufactures' software. Then use Affinity to do the real edit. If you go down that route then make sure that you avoid any form of jpeg as an intermediate file format. 16 bit Tiff files are big because they throw nothing away; Afphoto files are even bigger but huge discs are cheap so who cares. Affinity is an excellent alternative to Photoshop. It is not a replacement for LR yet. Hopefully it will soon replace both of them.

I have wondered about this myself. My present approach is to do the least possible in Develop. I use the defaults in Develop Manager so I get lens corrections. Then I run a batch job on all the raws in the directory of new pictures saving as afphoto files. When you select a large number of files you may get a brief 'not responding' message. No problem; it just needs time. When you run the batch you can see progress and I used to watch it. The present release (1.7.2.471) seems to be reliable, so now I go and make a cup of coffee while the batch runs. The batch uses all the cores of the processor. Its best not to try and do anything else on the computer while the batch runs. I would be interested to know how Serif developers intend it to be used.

When Serif produces some form of DAM it will handle files from Designer and Publisher as well as Photo. It could also handle Publisher dependancies and give warnings when you attempt to change a design or photograph which has been used in a publication. The degree of integration possible in Affinity is likely to be market leading.

Thanks Walt. That was the problem but I have no recollection of changing that default deliberately.

OOPS Creating the flood selection does work. It was the next part of the exercise that failed to work as expected. When creating the new adjustment layer this is created as a child layer of the background layer rather than a layer above. In this case the adjustment of course works because the background layer has no layers below it. So no real problem except to someone learning from the book who sees something not working as described. Sorry for confusion.

Please check that all the examples in the Workbook work as described. This is possibly a very basic check that nothing fundamental has been upset. Perhaps you could even recruit a team of keen users to do this check. Instead of releasing on a Friday, and expecting a member of staff to respond to queries over the weekend. Hold off until Monday while volunteers do that simple but time consuming check. Shared between around half a dozen people it would not be too onerous. For example 'Creating a flood selection' does not do so in the new release 1.7.2. It does work properly in 1.7.2.464 (beta). A more positive issue. Congratulations of doing rather well in both Amateur Photographer's affordable alternatives to A***e and Practical Photography's Powerful editing suites for under £100. Knocking the opposition for four in both cases is very good. With an optional DAM or Library module I reckon that you would have hit them for six.

I think that we have two things missing. One is the ability to quickly brouse files and show them in an affinity product ready for processing. Even crude products like Nikon's own free software allows a similar ability. One can quickly traverse (backwards and forwards) a directory of files and process or discard as appropriate. There is no need to inport. Second is a full DAM such as Light Room. Let's remember that LR is not a raw processor or an editor. LR sits above ACR and Photoshop and calls on them as needed. For this functionality a formal inport is needed. I agree with Cecil that refining the present products should take precedance at present however I would expect that the architecture of the Affinity suite was developed with provision for an overall application that could sit above the other products. I would not expect that to be a free 'add on'. I like the modular approach by which I have purchased licences to Photo and Publisher. I would purchase a DAM module licence at the same sort of prices as the existing modules. Incidentally I noticed the term 'inport' was used somewhere in the documentation before getting photo and publisher. It confused me somewhat because we don't import anything. I guess that DAM is planned. Also we export rather than 'save as'. Another clue that developers within Affinity might have something cooking?

No need to apologise Walt. This captioning process tends to be repetitive for some publications, especially the one I am practising upon. I have found that creating the required field correctly once and copying it into Assets to be very effective. For the next field j ust click in assets and drag to the required position. Make minor changes to the text; job done. This works and is very effective. The behaviour might be a bug, or maybe not. In looking for a workaround I have got into using Assets at an early stage of my self education. This might all be obvious to experienced users, but to me is a huge improvement to what I was using.