Asser82

Hi, I do not know, what the tool tries to say me, but after dragging a crop region and trying to rotate the region with the mouse, the thirds grid changes to a strange presentation and no rotation occures although the mouse cursor indicates that it is possible. See screenshot

In the 51 beta the 'Background Grey Level' was at 100%, which caused I white scroll viewer background which is the same as the color of the background layer after creating a new document. white on white => no border

There is a slider in the preferences which allows you to change the luminosity of the document area. Could change it from white to gray yesterday. It is near the UI gamma slider.

I think the opening time improvements after opening files several times are caused through operating system I/O caching. It is comparable to files which are not related to AFP. Would be interesting to profile how much time is I/O dependent and where the rest of the time is spent before the first preview is shown. There is much to optimize. In lightroom the preview generation seems to be zoom level and viewport dependent, so that only the visible parts are calculated and only in the detail, how it is needed for the zoom level. I know for example that sharpening and noise reduction are only previewed on the 1:1 zoom level in detail.

Hi James, after reading your suggestions, I have found a strange thing here: uncompressed 16 Bit TIFF (102 MB) -> 16 Bit AFPhoto (102 MB) -> Document Colour Format to 8 Bit RGB -> 8 Bit AFPhoto (137 MB) Tested with Release Build and latest Beta. History and snapshots are empty. The only possible reason for such a behavior could be that the original 16 Bit image is in the TIFF container and the 8 Bit converted image also. Now to a next step: 16 Bit AFPhoto from above -> Export to 16 Bit TIFF again (109 MB). Looking into the file properties it can be seen that the LZW compression is used. This compression method has been dropped by Adobe for 16 Bit TIFFs, because in photos it often leads to file sizes that are larger than of non compressed TIFFs. Maybe someone could try to implement ZIP compression for TIFFs (84 MB) or uncompressed (102 MB) as they are produced by lightroom. Btw. Photo can open ZIP compressed TIFFs, so why is there no option to use it for export? Here are some links for reference: https://forums.adobe.com/message/1918848#1918848 https://forums.adobe.com/message/1402821#1402821 I think, if it would be possible to select ZIP compression for TIFFs and also have the option to compress AFPhoto files at the cost of opening times and if there would be a settings page to better control the contents of AFPhoto files (no snapshots, no history, ... with check boxes), most of the file size discussions would end. I think people understand the size vs speed issue and are happy when they have options to go the one or the other way.

Hm, interesting question. Is something missing if you reopen the TIFF compared to AFPhoto file? Maybe the TIFF uses compression and AFPhoto not?

lightroom -> edit in Photo.exe -> 16 bit TIFF -> Affinity -> Save -> lightroom works fine. The only thing is, that Affinity photo on windows does not feel like a finished software. Yesterday I almost got crazy using quickmask and refine mask. After leaving and reentering quickmask, I could not see my masking brush strokes anymore to correct my selection. And I hope you have a really fast cpu, otherwise the refine mask is no fun either.

I think if you do not have a limited set of non destructive commands and the user has the possibility to change the pipeline execution order or influence its length (layers) it is really hard to realize the parametric approach, because you cannot assume and optimize anything and will fail because of performance when the pipeline gets to long. I think, I have read somewhere, that people tried exactly that and failed. Here is a nice response to a user, who asked the Adobe guys, why there is no content aware fill (inpaint) in lightroom, with the following response: "No, Lightroom does not have content-aware fill. I think that everyone would like to see that, but it's not that easy. The biggest problem is that any changes to the image will affect content-aware filled areas, so it would require a lot of recalculations that will slow down Lightroom. Photoshop does not have content-aware fill for smart objects either, possibly for the same reason."

Hey there, I am also using lightroom. I think raw files are a great thing if you want to recover highlights or shadows. In addition, the parametric approach with small size overhead is great too. But I am using LR6 instead of CC to not have monthly fees. The only thing I use AF photo for is as last step for inpainting (because it is not possible in LR) and maybe some adjustment layers / creative work (text, combining photos, ...). The inpainting algorithm is really great in AF Photo. I compared it with the one in PS Elements, and the PS Elements algorithm really sucks. For me I decided to not import a RAW file in photo, because it was slow the last time I tried and the lightroom RAW development process had much more time to mature. So my workflow is: 1) Import RAW photos in LR into one catalog with one root folder, do not think about your file structure twice, because you have your import presets. 2) Work as long as possible in LR, create your virtual copies, make your adjustments 3) If there is some functionality missing at the end of the process, generate 16Bit TIFF (Edit In > AF photo). 4) File auto opens in photo, work, save in photo => Changes on TIFF are visible in LR automatically, do not touch the TIFF in LR anymore, only to view or to export it What I did not know and was happy to see, that the TIFF preserves the layer information from AF photo. So the TIFF can be reopened next time and the layers are there. The only problem is when the underlying RAW/LR parameters change, then there is no way I know of to auto synchronize the derived TIFFs. This is a market gap for a lightroom plugin or so. Here it would be a really cool feature, if the AF photo history could be exported as a file and reapplied inside another TIFF, whithout replacing the base data in the background layer. I think AF photo will never be and is not intended to be a replacement for LR in the same way as PS will never replace LR. For me LR6 + AFP is the best combination you can get for the price of 150€.

OK, then it is maybe an old bug, where popups are placed in top left corner in a non reproduce able way, if the window is maximized when the popup is opened. You could check what happens if the window is unmaximized before you open the context menu.

Yes, this is a common mistake when developing software that document commands stop working, when focus is set to control bars outside of the document. Then the UI technology just walks up the controls hierarchy and does not find the command with that shortkey, because it sits parallel to the focused control bar inside the document window and not above of it. Yes I am with you here. All user settings should be persisted as long as they are not constraint by the image. The "Original proportions" setting should be the default for croping. The photo's proportions of 3x2 or whatever are used almost all the time. "unlimited" is a special case which is often realized through an "unlocked" image button. The export dialog settings should be persisted also. The probability after exporting a JPEG is at least 90% that the next export will also be a JPEG with the same quality. And there is also a high probability that the export will go into the same directory. There should also be an automatical croping overlay visible after an image is rotated which does exclude the transparent areas. "Enter" should always OK a dialog, "Escape" should always cancel.

From my experience as wpf developer I would say that the following aspects must be considered: 1) This may be a focus/selection problem. Maybe one of you first left clicks to select a layer and then right clicks to open the context menu, where the other right clicks directly. 2) There are often problems/bugs to calculate popup possitions, if multiple monitors are used. Note: there may be a difference whether the monitors are configured 1-2 or 2-1 3) Often popup positions are miss calculated if the DPI settings are set to 125% or 150%.

I really hope that Serif resolves just this one use case: 1) Open 25MB raw directly from lightroom in max 5 seconds with all LR development adjustments applied showing histogramms the same before and after develop persona is left. 2) Develop in affinity without further changes in develop persona, because all lens corrections and adjustments have already be done in LR. Or optionally just skip develop persona. 3) Apply effects, heal spots, etc 4) Store Affinity photo file near the imported raw file 5) Export TIFF, JPEG, whatever to LR Does affinity persist the Undo/Redo stack? If so, it would be great, if the base RAW would be referenced as link, and the Redo stack could be reapplied on second cycle. This way the base RAW could further be changed in LR and affinity steps reapplied as last step. The last evolution step would be if an affinity photo file would persist the modification date or hash of the referenced base RAW, to detect whether the RAW has changed since last time. Then there could be a batch processing function in Affnity which operates on a folder root, which scans all folders below for affinity files and reapplies the Redo stacks + exports for all RAWS which have changed. This way we would have a single click post processing build on the complete catalog. This would be a killer feature. But the "problem" here is that the RAWs never change, only the instruction sets in LR :-/ So if a partial build is not possible a rebuild all on a subfolder would be nice.

1) This is not comparable. There is really no need to rent software if there are options. You have no option to cancel your electicity subscription. I have MS Office 2013, and will never rent MS Office 365 for sure. I would rather switch to libreoffice before I start to rent software. The same is now true for Lightroom. 2) My current computer is now 7 years old, everything is OK. It went all the way from windows 7 to 10 without compatibility issues. And to cite microsoft, windows 10 is the last windows :-) And yes a separate partition for legacy software is always an option.

Hey guys, you missread what I have written: 1) I do not and will not subscribe anything. Never CC for me. 2) There is a lightroom version called Lightroom 6, not Lightroom CC. It is updated all the time with current version being 6.8. It is 95% identical with the CC version. You pay one time 115€ on amazon for example and can use it 10 years without updating. OK maybe the support will drop after 2-3 years, so no lens profiles will be added by adobe, but there are other sources for them. You will also get no new features. But hey, the features that are currently there are enough for me. And if new features will be added to say LR7, I will think about whether it is necessary for me to buy this update which costs 80€, or whether these features are irrelevant for my workflow. The cool thing is that an update to LR6 costs 80€ independently of whether you update from LR1 or LR5. So if they do not change this policy, I could skip the update to LR7 and update to lets say LR8 or LR9 saving costs for irrelevant updates. If adobe will not release LR7, I will stay with LR6 forever or switch to somewhere else. But there must be a really good reason to switch, because LR6 has everything I need. There is no standalone, non CC photoshop in the price tag of the LR6, so this is why a hope that Serif will improve Affinity Photo, so that I can import my LR preprocessed RAWS fast with correct histograms to give them a final touch or to apply some effects before they are exported.

I do not know what is the problem with LR. I bought LR6 standalone two days ago for 115€ and I do not regret it: Great raw import into a well structured catalog. Fast and efficient photo development. Great indexing of photos with keywords and face detection. Absolutely stable so far. Support of all lens profiles I own or know about. Covers 95% of the workflow of a photographer. I bought Affinity Photo to cover the remaining 5% as Edit In > Affinity Photo. This way I would have to pay 115€ + 40€ = 155€ one time fee for a complete toolkit, which is in the range of one year CC subscription for LR + PS. But I have returned the affinity license because it currently needs 18 seconds on my PC to open an average CR2 RAW file and also the histograms are very strange. I will look into it again in one year or so to see whether the software has matured. Paying 10€ more then does not play a role.

Same is true with Canon CR2 files.When loading a 21 MB file I need to wait 18 sec. Then the UI/Main thread blocks for a short time and the image is displayed.The free tool from Canon "Digital Photo Professional 4" needs 1-2 seconds to open the same images. There is a second strange thing: Before a RAW is developed, I get one histogram displayed. After developing it, I get a totally different histogram displayed. How can this be true? Third thing: I could not find a one click way to auto crop an image after I have rotated it, so that no empty background is visible within the image bounds. It taskes to much time to crop it manually, if you are batch processing RAWs. Please implement fast ways for the following use case: 1) User opens raw file. The raw file opens instantly if photo is already loaded. 2) The user makes his adjustments. Rotate (horizon, walls) and crop to fit is done efficiently. 3) Develop, export and close the raw file 4) Repeat with 1

@mark, this is caused by the different Key values for the buttons: System.Windows.Input.Key.Oem1 vs NumPad1 The same is true for +, - if it used for zooming. Hopefully your command infrastructure supports multiple key gestures per command. :-)

First feedback to menu structure: - Some menus are too overloaded with commands. Especially the View menu. I would strongly recommend to put some people which do not know the tool into a meeting and do something like "Card Sorting" https://www.usability.gov/how-to-and-tools/methods/card-sorting.html. Maybe this has been done, but I feel a little bit lost in these menus. - The personas seem to be the root of your information architecture. It was surprising to find them in the File menu. I have seen them as "Workspaces" and would expect them in the View menu. But I also see, that the availability of the menus depends on the personas. Anyway, having File->New not as first item in the File menu feels strange to me. Interesting to see that this is a WPF application, so I can Snoop around a little bit :-)