Search the Community
Showing results for tags 'edit with'.
Found 1 result
Hi, so, I am reporting a rather obscure error. It may be difficult to reproduce unless duplicating fairly exact conditions, so I will be specific. System / Software Operating System: Windows 10 Pro 64-Bit 1709 Build 16299.371 Hardware: Gigabyte 15X - i7-7700HQ / 16GB Ram / 1.5TB NVMe SSD / Nvidia GeForce GTX 1070 Max-Q GPU Affinity Photo: v 18.104.22.168 Capture One Pro: v 22.214.171.124 Issue Description Using Capture One (C1) 'Edit with' to edit an existing NEF raw file, a 16-Bit uncompressed TIF file is generated and saved in C1 and then sent to Affinity Photo (AP). Once this file is updated and saved within AP, the TIF file is successfully returned to C1. However, on trying to edit the filename in C1 immediately afterwards, C1 says that the file is locked by another process. This happens on all successive similar edits of NEF files. If one exits C1, and goes back to those files, they are no longer locked and can be renamed. To Duplicate 1. In C1, select a file such as a raw NEF file named IMG-1234567.NEF.2. In C1, right click the image thumbnail, and use 'Edit with' to edit in an external app, selecting Affinity Photo.3. In C1, this creates a TIF file in the same directory, in this case naming the file IMG-1234567.TIF.4. In AP, this TIF file is opened up. The image is simply adjusted (such as brightness or curves) and the image is flattened.5. In AP, use 'Save' in the File menu (or Ctrl-S) and then Exit (you can alternatively just exit AP using the close window button and confirm saving changes to the file on exit).6. In C1, after being returned from AP, the image thumbnail looks okay, updated and all looks fine. 7. In C1, however, it is not possible to RENAME the file, as C1 says the 'item is being used by another process'. Essentially the file is locked from file-based operations, unable to be renamed or deleted. Investigation 1. This occurs when a raw file is converted to a 16-bit TIF files that are uncompressed, using any ICC profile, 300 px/in. fixed 100% scaling, before being sent to AP. This problem does not occur when converting to and sending 8-bit TIF files, jpegs, PSD files or any other from C1 to AP. 2. It only seems to occur when raw files are converted to 16-bit TIF prior to sending. Editing an original jpeg or TIF file, where a 16-bit TIF is made and sent to AP does not produce any issue. 3. I have tried out this problem on a similar hardware system, with the same operating system (Windows 10) freshly installed, and the same issue occurs. However, on a Windows 7 system, this issue does not occur. 4. Using SysInternals diagnostic software, I have ascertained that when the TIF file is returned from AP to C1, the process that has locked the image file is in fact C1 itself, as though it has stalled on some operation on the file once returned from AP, thus locking the file until the software is restarted. 5. Sometimes, when I have tried this, 10% of the time there is no issue, but I cannot determine the reason for this variation. 6. Using 'Edit with' in C1 to call other editing software, such as Photoshop or OneOne PhotoRaw, using a 16-bit TIF is not an issue. Using software, such as Lightroom, to call AP is also not a problem. It is specifically when pairing C1 with AP, using a 16-bit TIF as the round-trip file format. 7. I have had one other user say that they were unable to duplicate the issue, although I cannot be sure that the exact operating system, software and GPU setup were the same. While I do not expect much of an outcome on this issue, I place it here for reference should the issue ever hit another user with similar hardware, operating system and software versions. In many cases, when people try to duplicate such an issue, one of the common reasons that the issue is not duplicated is due to some variable, environmental condition or procedural steps not being mirrored. However, should anyone with this setup like to report back their own findings, I would certainly welcome the information. Thank you, Cass.