Galm

I run all the tests i could think of on the 105, 107 and 109 pages and i couldn't find any difference between them. All the values are exactly the same on all 3 pages!

I have a similar setup (gtx 1660 super; 32gb ram; i7 processor, win10), and just applied unsharp masks and clarity filters to a bunch of photos, with acceleration on, without any problems. Could it be the graphics card driver? I'm using the studio version, currently 472.12.

Thank you very much! Not only the 400dpi macro by John Rostron works perfectly but also, knowing the 1.6 release doesen't have this bug, i will set up a virtual machine with version 1.6 to make new macros if needed!

I found this issue because i had a book with almost 400 color images with different sizes and orientations and all the pictures are bigger than necessary in size and almost all had a resolution of 1200 dpi. For the workflow we use, we only need the pictures to have 400 dpi, so i wanted to downsample all the images to 400 dpi retaining the size in mm to save time processing such unecessary large files. I tried with AP and got the problem i mentioned. I already send the files to a colleague that solved the problem with another software... I really wished i didn't have to do that. I would be very grateful if there is a workaround for this situation if i need it again before this bug gets fixed. Thanks

Thanks for the answer. I want the macro to use it in the batch job. I know you can change image size in the batch tool, however, i don't want all the images to have the same size. I want the same resolution with different sizes.

So i need a macro to downsample a bunch of photos. I tried recording a macro of "Document-> Resize Document", and no matter if i put the "resample" tick box on or off, it always seem to copy the proportion of the image used for the macro recording and applies it to all images. So, if i record the macro of a vertical oriented image, all the horizontal oriented images end up all distorted. I tried everything i can think of, and i even tried upscaling to see if it worked. I got the same problem. Even using the "Resample Pixel Art Document" has the same problem. So , unless i'm doing something wrong, i think it's a bug.

Thanks for taking the time to do the test. At least for now i can discard machine problems. My processor is a lot older and slower than yours. It's an i7 5820K.

I just confirmed, and the image i used for the tests on the previous page was in CMYK. The same image on beta .952 in rgb took 40s with opencl enabled and 17s with opencl disabled. It doesen't seem to be any difference, with the nvidia gaming driver between a image in CMYK and a image in RGB. And by the looks of it, it isn't reverting to software which, at the moment, is faster on my computer than hardware opencl.

I dind't know that. However, the above test with the stock photo was done without converting the image. So it was done in RGB. If @PetervL finds the time to do the test, and if he doesen't get the delay i'm having, then there could be something wrong with my system. I still haven't excluded that. The lack of CMYK opencl acceleration could explain why some images took over 2 minutes to deselect. When i find the time i will convert those images to RGB and try again for testing purposes. Thanks for the tip

On my machine is almost instantaneously with small files (1 our 2 mb). When i do it on this particular set of images (around 300mb, cmyk, tiff files) i get the delay. Can you please test on similar images (i cannot share this ones), to see if it's only on my machine that it happens? Thanks Edit: If you can, please do the folowing test: On the latest AP Beta: Create a new blank document On the Stock panel, select Pixabay and search for "Beach". The second photo should be a silhouette of a women against a yellow/redish sunset. Drag that photo to the document Select it, copy it and then choose File-> New from clipboard. It should give you a new document with the full photo. Go to Document-> Resize document and change the dpi to 250 using the Lanczos 3 Non Separable and with the "Resample" box thicked. Now with the patch tool select the woman (roughly), click the area in front of her to make it dissapear and then deselect the tool. After 5 tries it took always betwenn 45 and 50 seconds to deselect with opencl enabeld on the latest .952 beta. Here are a few screenshots of the image

I did run the benchmark multiple times, and got consistently higher results on the gaming driver. As for the patch tool times, i run every test 5 times and take the 3rd result if it's not much different from the other 4 and it's indeed about 50%, faster on the same image, with the same beta just changing the driver. Also, i just finished the same patch tool test on the release version, and got 1m9s. Thats also about 50% faster than the studio driver, but still slower than the opencl disabled times.

Just changed the nvidia studio driver to the gaming one, and on beta 1.9.1.944 it took 43s to deselect the patch tool. Also, i get better results on the benchmark tool

Just tested the new beta 1.9.1.944 with the same images that were giving me problems. Now i get no artifacts. The patch tool works fine. There is just a big lag between clicking to deselect and it actually deselecting. During that time, i get a "not responding" info on the title bar, and AP graphics card usage oscillates between 50% and 100%. After a while it starts responding again. I just tested with a scanned image (AP recognizes it as a 75MP image) and it took 1 minute and 21 seconds to deselect. But the resulting image was fine. I just runned a couple more tests, and the results are curious. My setup as a i7 5820k with 32GB ddr4 and a GTX 1660 with 6GB. Both Windows and gpu drivers are the lastest versions. The same image running the patch tool on the same area. Beta 1.9.1.944 took 1m21s to deselect with opencl enabled. There seems to be a bug that doesent allow to deselect opencl at the moment. Stable 1.9.0.932 took 2m15s to deselect with opencl enabled. Stable 1.9.0.932 took 17s to deselect with opencl disabled. It seems the patch tool is alot faster with opencl disabled. Here are my benchmarks on both the latest beta and current stable.

I notice a great improvement. However, on my setup, it still happens. It only happens sometimes, on high resolution photos, and the resulting problem is smaller in size, but it's still there. Here are a screenshots of before/after deselecting. Has you can see. It's just a small black "shadow" that wasn't there before deselecting.

Maybe you have a diifferent graphics card or driver version?