Freixas

Understood. After dealing with a lot more images using my new flow, I think your luck with lack of color shifts depends a lot on the image you start with. Most of the images I've tried have few problems. Sometimes there are tiny color shifts in a few areas. I took a photo of a very red fall leaf, though, and it was tough to get anything close to the master image. I also had some very green leaves that became slightly but noticeably less saturated—that was the image that started my post. The color space for most papers is even more limited than sRGB (I think), so it's great if you're having so few problems. Some images drive me to tears. One can calibrate a printer all day, but in the end, if you put it in a room with variable lighting, the image can go from bright to muddy over the course of a day. But that's the way it is with prints...

Thanks for the correction. Yes, I'm using Wide Gamut. Yes, I'm exporting as ProPhoto. PhotoLab 7 just added a soft-proofing feature. I haven't done much with it. My quick tests seem to say that it works. But my question was about optimal workflow. My original image is RAW, which has no color space (or maybe it has an intrinsic color space defined by the hardware). As I work with the image, I'd like to have the widest range of color possible, which I believe is effectively limited to what my monitor can display. Once I have my "ideal" reference image, then I can worry about how to adapt it to sRGB or to a print profile. So the revised workflow I am considering is: RAW image -> DxO PhotoLab 7 with Wide Gamut color space -> export to TIFF with ProPhoto color profile -> import to Affinity Photo with ProPhoto color profile -> convert to target profile -> do the best I can to match the reference TIFF image -> export or print with target profile

Yes, I am re-thinking my workflow. The original images stay in ProPhoto, but when an image is intended for Facebook (which seems to always convert images to sRGB), I might as well start with sRGB. I also think I might be wrong in saying my monitor's color space is smaller than sRGB. It's rated for 100% of the sRGB color space. Someone claimed that it covers 90.7% of the Adobe RGB color space. It's possible the colors I can see on the monitor cannot be reproduced in sRGB. I ran through a series of photos. Most images survived the conversion to sRGB reasonably well. One deeply red image was pretty far off. The Soft Proofing adjustment is buggy. The gamut warning fails to update as I make changes to the image. And the conversion to sRGB, even when it seems to work initially when using the sRGB2014.icc profile, gets off track as I make adjustments. The adjusted image, with Soft Proofing on doesn't look like the converted exported image. Switching to the sRGB color space might be the best approach.

Thanks. Using the sRGB2014.icc profile for soft proofing shows the same result as saving with the sRGB IEC61966-2.1 and thus makes soft proofing possible. The process is not ideal although this gives me a fighting chance. The sRGB space is perfectly capable of representing the colors I want. This is easy to see by converting the image to sRGB and then increasing the saturation a bit. Affinity is already mapping the ProPhoto space down to the monitor's color space. It still seems as though converting to sRGB shouldn't change what I see on the screen. Since sRGB has been the default for images without profiles and for programs that don't pay attention to color profiles, I use sRGB for JPGs intended to be shared with others. My workflow seems more complicated than it should be: get the image looking the way I want, the soft proof it in sRGB and correct any color shifts. And the corrections have to be guesses—once I change the soft proof, the original image will now be incorrect. This just doesn't seem right.

My work flow is this: RAW image -> DxO PhotoLab 7 with ProPhoto color profile -> export to TIFF with ProPhoto color profile -> import to Affinity Photo with ProPhoto color profile -> export to JPG with sRGB IEC61966-2.1 profile -> view with IrfanView or MS Photo. There is a small but noticeable color shift when I compare the image in Affinity with the image in IrfanView. If I save the JPG using the ProPhoto color profile and then view with IrfanView, the images look identical. My assumption is that the sRGB color space cannot display all the colors in the ProPhoto color space. Fine. But let's keep in mind that neither can my monitor. I would think that a color in the ProPhoto color space outside of my monitor's color space would be converted to my monitor's color space, which shouldn't be much different than the result of converting it to sRGB. I wouldn't think the image colors would appear different. Of course, there is intent. My working color space is RGB/16, ProPhoto Perceptual with no Black Point compensation. When I export to a JPG with an embedded sRGB IEC61966-2.1 profile, I'm not seeing any place to declare the intent. In any case, I thought I would enable soft proofing using the sRGB IEC61966-2.1 profile—then I could at least preview what would happen. I added a Soft Proof adjustment with the sRGB IEC61966-2.1 profile and Perceptual intent. The image didn't change. If I enable the Gamut Check, it shows that there are gamut problems, but that's about all it does. I tried various other intents as well—the image remains unchanged. To preview the color shift from ProPhoto to sRGB, I seem to have to convert the document's color profile. Do I misunderstand the Soft Proof adjustment?

The problem occurs with Affinity Photo, v2.00, the latest version at this moment. It is easy to reproduce: import the attached watermark macros into Photo V2 and attempt to edit or use one of them. These macros still work with Photo V1. It happens with any document. The problem occurs on Windows 10. Hardware acceleration is ON, but probably irrelevant. I find Affinity macros a bit opaque to edit. The first macro step is "Set text stylesheet". I can't see what the text stylesheet is set to. Presumably, it points to my watermark file. You won't have an equivalent file, but whether the file is present or not, the program should not crash, and it should be less likely to crash when editing the macro (as opposed to trying to use it). Clicking on the macro does not cause a crash if no document is open. Create a document, click on the macro, and the program consistently crashes. Watermarks.afmacros

Thanks. I played around with it, though, and it's not quite that easy. It seems to depend on the mode one is in. With the Move tool selected, I can click on a table and it is selected, but I can't enter into it, not with click or Alt-click. Ctrl-C does copy the table. With the Text tool selected, then, yes, a click does nothing useful; an Alt-click displays the row/col headers and allows me to enter into a cell. Once I get the row/col headers, then I can click a cell in another table and have the row/col headers appear there. If I use Ctrl-C, I appear to copy the table unless I've selected some other content, such as the contents of a single cell. And on and on... None of this is intuitive, none of this is documented in the Help except selecting a table with the Table tool, which actually only seems to work when clicking on a table that is not pinned or clicking on the edge of a pinned table, so even that's not very accurate.

I managed to get that to work. One of the problems I ran into is that, if I click on a table cell, sometimes it does nothing, sometimes it brings up the row/column headers. If I select the Table Tool first, it sometimes works better although even then, selecting a table can be problematic. I haven't figured out the exact magic I need to make that work predictably. In any case, this is beating a dead horse. I wound up transferring everything to my ancient CS6 InDesign, which allows tables to cross page boundaries and repeats header rows automatically.

Thanks, but I don't want to edit text in one file and tables in another. And it's still not clear how I wind up with a document (made in AP) that had tables broken across pages and with the headers repeated across the breaks. As I understand it, AP doesn't support this feature. And if I try to create fake tables (using some sort of styling trickery), I still don't get automatic headers when a "table" breaks across a page. I've concluded there is no way to do this if AP doesn't support it--unless there is some extension mechanism that could add this feature. I used to do some fancy stuff with InDesign coding. Of course, I'd rather not. I'd rather work on my document than on AP.

Thanks, anto, but my problem was in copy/pasting within Affinity Publisher. Select the table tools Poke at the table until I get it selected Select all the cells in the table Copy If I select a text position and Paste, the table contents are turned into text As I recall, I have to maybe have the table tool enabled and paste somewhere outside the text flow Then I drag the table into approximately where I want it in the text flow Pin the table It seems like a pain. I am not trying to copy/paste from LibreOffice to Publisher.

Hmm... I thought I had been pretty detailed. This document is a detailed script language specification. The script contains commands. Each command has one or more properties. Properties have "names, types (float, integer, etc.), min values, max values, default values (if omitted), and explanation of what the property does." So I'm going to have one section per command. Each command will have an explanation of how it's overall function and a list of properties. The most space-efficient way to listing the properties is in a table. Here is an example, with a lot of stuff not yet filled in: This example actually came from LibreOffice—I'm checking it out as an alternative. It doesn't really offer a lot more advantage except in allowing tables to break across pages. Putting the tables in another file and importing them would be a ton of work and would make editing the document a pain in the neck. The text and the table contents need to be edited together. After posting, I decided that there really isn't any good substitute for a table. Tables exist for a reason. Affinity Publisher can't break a table across a page. I don't want to manually have to break the tables. In a "live" document, editing is ongoing and so any edit might cause existing tables to need to be split and split tables to be joined back. The final question for me is whether I can live with the tables being broken. If I need to share the document with someone else at any point, I'd either need to fix the tables or live with the document looking unprofessional. It's disappointing, but I have to figure out how I get the job done with the tools I have today. I realize that Publisher wants to treat tables like another kind of image, rather than as a special kind of text flow. While this works for some layouts, it's not the best model for tables. For example, it doesn't make sense to split an image across pages, but it's common for tables to be split. Changing the way tables are dealt with would require a lot of work, so I won't expect a change anytime soon.

I have a technical document. In it, I am going to document various commands, each of which have one or more properties. Properties have names, types (float, integer, etc.), min values, max values, default values (if omitted), and explanation of what the property does. I started by having the properties described in bulleted lists. This allows me to highlight the name, but with one bullet per property, it makes it hard to find things like the type, min and max values, and default values. I could create a nested bullet list with the outer bullets for the properties and the nested bullets for the various property attributes. This works, but takes up a lot of vertical space. To me, the most obvious tool for the job is tables and I tried those. Affinity Publisher's tables are really odd. I want all my tables inline. I read the entire help section on Tables and it gives no clues on how I would accomplish that. I finally found out that the magic is done with pinning; exactly which text position the table is pinned to is still a bit of a mystery. Clicking "Inline with text" will put the table inline somewhere (it seems to be the closest text position as measured from the upper left position of the table, but I'm guessing). Once again, the Help text is useless. After playing around with table styles, I managed to create a header row and set up some different formats for the various cells. When I try alternating background fills on alternate rows, every row in the last column gets the fill. Elsewhere, just the alternating rows get the fill. I haven't figured out this one. In any case, I can't define the column widths. I'm going to have a lot of tables; the widths need to be consistent from one to the other. On solution is, rather than create a new table and then assign a table style to it, I use copy and paste. This way, I get the column widths—but if I ever change my mind, it looks like I would have to re-edit every single table. EDIT: Actually, my attempt to copy a table and insert it into text didn't work—it created a text version of the table with tabs between the content in different columns. I figure out how to copy a table to get the right column widths and then tried to copy the content from another table and paste it into the new one. That sort of worked but the line heights were now all wrong. I had one table with 8 properties and it won't fit completely on the page it's on. Rather than being automatically split with the option of repeating the header row, it gets moved in its entirety and I see people complaining about this since 2018. The workaround is to split the table manually, which doesn't work when one has a "living document" that is going to be continually edited. I mean, even MS Word has this capability. There are other oddball bugs that I can manage to work around. For instance, if I create a new table and start typing any text, it comes out all capitals. I have to select all text and then go to Text Styles and reset all formatting. None of the styles I'm using have capitals set. It seems to be a style override that comes with every new table. Well, the idea of doing this document in Publisher is pretty much hosed, but before I try to find some other tool, I thought I'd ask whether there were any other options that might get me the same effect.

Thanks, Chris. Actually, focus stacking in Affinity has always been (in my opinion) fast. I only posted the performance measurement because someone else asked me to. I downloaded Helicon Focus because it (and Zerene Stacker) were most often mentioned in a macro group that I participate in. Affinity Photo seems as fast as Helicon and, despite the lack of any options to direct the stacking process, seems to produce as good or better results.There seems little awareness of this in the macro community. Helicon and Zerene are both more expensive the Affinity Photo and all they do is stacking. Stability is of primary importance so that is the correct thing to prioritize.

Finally got around to it. There is no performance difference and I reported this in the beta thread.

The comparison is between 1.9.0.932 (release) with hardware acceleration disabled (because it has a bug) and the 1.9.1.952 (beta) with hardware acceleration enabled (Radeon RX 580 series). The problem is that there is no performance difference. I used a stack of 13 images. With the release version, no acceleration, it took 45 seconds. With the beta, accelerated, it took 43 seconds, then 46 seconds when I repeated. In the post where I noted the bug in the release version, Walt Farrell suggested I report the beta performance (non)difference in this beta forum.

Turning off hardware acceleration eliminated the problem. Using the beta eliminated the problem as well (with hardware acceleration enabled). The funny thing about hardware acceleration for focus stacking is that it seems not faster with than without. I didn't try to time it with a stopwatch, though.

Now that Affinity Photo is using the GPU in 1.9, I'm getting errors which are probably due to this change. The first time I was trying to stack images, I was running another program, DxO's PhotoLab 4. which also uses the GPU. I had various results: a hang (had to reboot), a hang (was able to kill the program), a black screen that reset and sometimes odd results. And sometimes it works. I just tried the same focus stack three times, once with PhotoLab 4 open but inactive and one without but with Affinity Publisher open, and one with neither program. Twice I got incorrect results. The third time, I got a black screen and the program hung (I was able to kill it). It might work if I reboot after using PhotoLab 4. I've attached examples of the two focus stacks (the results ought to be identical). Here's the info for my graphics card. I did install the latest driver before checking all this. Display adapter 0 ID 0x2140001 Name Radeon RX 580 Series Board Manufacturer Sapphire Technology Limited Codename Polaris 20 XT TDP 185.0 W Cores 2304 ROP Units 32 Technology 14 nm Memory size 8 GB Memory type GDDR5 PCI device bus 29 (0x1D), device 0 (0x0), function 0 (0x0) Vendor ID 0x1002 (0x1DA2) Model ID 0x67DF (0xE353) Revision ID 0xE7 Performance Level Current Core clock 600.0 MHz Memory clock 2000.0 MHz Driver version 27.20.14533.1000 WDDM Model 2.7 Win32_VideoController AdapterRAM = 0xFFF00000 (4293918720) Win32_VideoController DriverVersion = 27.20.14533.1000 Win32_VideoController DriverDate = 01/27/2021