Jump to content
You must now use your email address to sign in [click for more info] ×

Justin

Staff
  • Posts

    131
  • Joined

  • Last visited

Everything posted by Justin

  1. @DylanGG What machine do you have? We will try to get a matching one to do some testing on. Also, could you upload an Affinity document that shows the problem using the following link please? https://www.dropbox.com/request/L3ukkbekYapTrtI2AiYm
  2. Hi Julio Background calibration: This adds an offset to each light frame so that the median value in each frame is the same across all light frames. Each channel is treated separately. It's attempting to compensate for the sky brightness changing over the course of the night. Subtract black level: Normally when we open a RAW file we subtract a black level which is an average of the masked pixels around the edge of the sensor. If dark frames have been specified then this step is unnecessary and can be skipped by unchecking "Subtract black level" if you think that it's causing a problem. Regards Justin
  3. Hi Brad We've fixed a bug that was probably causing your issue so you might want to try it again when the next beta is released, which shouldn't be too long. Cheers Justin
  4. Brad, could you try turning off hardware acceleration in Preferences|Performance please? Thanks Justin
  5. Thanks for trying that Brad. I think this suggests the data has already been corrupted by the time it does the noise reduction and corrupted in such a way that the noise reduction code doesn't cope with it, which narrows things down a bit.
  6. Hi Brad All the crashes are happening during noise reduction, so could you try turning off noise reduction in Develop Assistant (reached via the icon that looks like a butler's tuxedo towards the right of the toolbar), run the batch again and see if it still crashes. Thanks Justin
  7. Hi numberonesoniafan Thanks for reporting this. I'm not sure exactly what's wrong as yet, but I note that if I change the format to RGB/32 (HDR) before converting from the scanner profile to ProPhoto, then it seems to work correctly. Regards Justin
  8. Hi Depa Thanks for the file. This has been fixed for the next beta. Cheers Justin
  9. Hi NotMyFault If you disable "All layers" in the selection brush it will be quicker. The "All layers" option requires rendering the noise reduction live filter, the lab curves and the gaussian blur filter effect at full resolution for at least some of the document, which will take some time, hence the delay. You should only turn on the "All layers" option when you really need it, i.e. edges are derived from multiple layers. In your cut down document all the edges are derived from the one pixel layer, so maybe you don't need "All layers". Regards Justin
  10. Hi nomi02118 The file is a panorama merged in Lightroom but we are treating it as an out-of-camera RAW file and applying lens profile corrections when we shouldn't. As a work around, in Develop go to the 'Lens' page and turn off chromatic aberration correction and the other lens profile corrections. Hope that helps Justin
  11. Hi Jeroen There are a few isolated pixels in your file that have red channel values of NaN (not a number). The live denoise filter is getting confused by these and producing black squares centred on the corrupt pixels. I'm guessing the image comes from a RAW file via the Develop persona. Do you remember what adjustments you applied in Develop? Thanks Justin
  12. Hi Mike Can you post a sample image, please? Thank you Justin
  13. Hi hanshab Thank you for reporting this. A fix has been implemented for 1.7.2. In the meantime is you disable hardware acceleration it will work as expected. Justin
  14. There will be an option to use the old filter. I will seek to make improvements to the new filter in the future.
  15. Hi Steve Thank you for posting your image. I agree you can get a better result on this image using the old filter, which is disappointing. We will reinstate it as an option in 1.7.2. Cheers Justin
  16. Hi Steve Can you post some sample images to illustrate the problem, please? If you include the original image I will do some tests. Thanks Justin
  17. Hi Nigel This is to be expected. The destructive filter estimates the noise level throughout the image and scales the intensity of the effect accordingly. The live filter cannot do this as the full image is not available to it due to the tiled nature of the rendering pipeline. Justin
  18. Hi Daniel I can reproduce this if I set the Rendering Intent in Colour Preferences to Absolute Colorimetric. Is that what you have set? If so, does it behave as it used to if you change to Relative Colorimetric? Justin
  19. Yes, I can reproduce this. I'm not sure what the problem is yet but it will be fixable.
  20. Hi Hanterdro I believe this has now been fixed. Thanks for your help. Justin
  21. Hi Hanterdro What you are seeing is not expected. The selective colour adjustment has been rewritten but adjustments created in previous versions should be preserved. They should be labelled as "Legacy Selective Colour Adjustment" in the layers panel. Do your adjustments have this label? Note that if you edit a legacy adjustment it will be updated to the new version and a toast will appear saying this has happened. This is all working as expected on my machine. Are there any other adjustments in your document that might be at fault? Regards Justin
  22. Hi j3rry Good spot. This has now been fixed. Thanks Justin
  23. Hi j3rry The problem was with how the DNG was developed - it made it very slightly transparent and the border fx always recolours partly transparent pixels. I think the problem with Develop has now been fixed (in RC1). To fix your .afphoto file you should fill the alpha channel of the pixel layer. I usually do this by turning off editing of the other channels in the Channels panel and then painting over everything with white. Thank you for reporting this. Justin
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.