Amateur John

I wouldn't dream of running a batch of raw to jpeg. I run a batch of raw to afphoto. then edit and export to whatever format and size that I need.

Affinity batch process works on raw files. Sometimes with a long list you will get a not responding as they load; just give it time. The running of the bath process has been reliable for several releases.

FastRawViewer is a useful tool for quickly sorting through a batch of raw files before submitting them to Affinity Photo's develop persona. It is not a DAM and its authors do not claim that it is. Thanks for mentioning it. It is useful.

I hope that you can get this 90 day trial viral amongst college and older school design students. You could end up with a lot of self taught users who know no other package. The potential sales as things come back to normal are enormous. It is very generous to allow people enough time to learn how to use the apps. It may also prove to be wonderful marketing. Thanks for all the development work. Take care and I hope that your home working stops you catching the virus.

The database for DAM does not contain the editing information that is stored in xmp files in the Adobe system. The LR database keeps track of where files are stored and information about them that we want to add in order to find them. It also tracks duplicates which are made for further processing. In an affinity installation, should a DAM be produced, I would also expect it to keep track of files being used in other documents. For example photographs being used in publications. A database is an essential part of a DAM.

I would expect an afphoto file to be at least twice the size of the high quality jpeg file from which it was generated, even if no editing was done, for two reasons. The jpeg file uses eight bits per channel per pixel whereas the afphoto file uses sixteen bits The jpeg file uses destructive compression.

I do not need a DAM. I would like a DAM very much. I would expect it to use a database and accept that importing would be necessary. A browser like Bridge is not worth the effort of creating it. I am aware of the problems of creating such a system since a colleague and I created a system for controlling engineering drawings, which ended up as a product database. This system used an Oracle DBMS. I understand that Lightroom uses a light single file version of Microsoft SQL Server. These DAM systems are not trivial and require several man years to develop. I am still hoping but do not underestimate the resource needed. I would expect this, if ever created to be an add on at extra cost. This would be a huge project for a company whose expertise is in graphics, imaging, and desktop publishing.

Thanks for posting. Starting the previous beta was not alerting the update which has gone live today. The Affinity team have even been working Saturday on this . I have tried the new beta on Nikon NEF and it is good. John

There may be a combination of causes. One contributory cause, possible with Nikon NEF files is the effect of Active D-Lighting (ADL). This is intended for producing acceptable out of camera JPEGs in high contrast situations but does effect NEF. Exposure is reduced to reduce the burning out of highlights then the shadows are recovered in creating the JPEGs including the embedded jpeg in the NEF file which is also displayed on the camera monitor. An entry is made in the NEF EXIF such as "Active D-Lighting Auto". The in camera histograms are generated from that embedded jpeg so the deliberate underexposure is not obvious to the photographer. If the NEF file is opened in Nikon's own software such as Capture NX-D that software picks up the EXIF entry and acts upon it. Affinity does not seem to react to that entry so the image appears dark and the histogram is created from the real raw data. I see this as something that Nikon users need to be aware of, and not something to be fixed by Affinity. I agree with other users that something else is going on. ADL has affected files which I submitted on another thread.

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.