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

dmstraker

Members
  • Posts

    825
  • Joined

  • Last visited

Posts posted by dmstraker

  1. Curious rider: To double check on another machine, I downloaded the jpg image and there was no problem. But the .afphoto still displayed the problem. Is this something to do with file size or rendering? The problem also appears on v1.9. For reference, the problem image is uploaded (suggesting it's not rendering).

    Edit: Further experiments show that the problem occurs in 16 bit but not 8 bit.

    colour_burn_problem.jpg

  2. Excellent increment. Well done, folks!

    I'm planning on doing an InAffinity video on these and would appreciate a little more detail on these so I can demo them:

    • Added more filter support for masks / adjustments / spare channels (Add Noise, Perlin Noise, etc.)
    • Improved Blend modes to work on “alpha only” layers (masks, adjustments, live filters, etc.)

    Thanks.

  3. Hi Hans -- I'm really trying to get this to work and understand the difference here between fill (via fx) and opacity, but I cannot produce a difference. I used your macro, grouped and duplicated the result, then set curves opacity to the same as fill, plus set fill to 100. The result seemed the same as using the fill opacity. I suspect I'm doing something wrong and would appreciate guidance. Thanks!

  4. 17 hours ago, Jowday said:

    In Photoshop deconvolution is beautifully implemented in "Smart Sharpen"

    I'm an inveterate tinkerer and would be grateful in the shorter term with just a basic implementation.

    There does seems to be all kinds of sharpening methods out there, from stacking to use of assorted blend modes. I've played with quite a few though it's tricky to figure out what works best where. Maybe one day there'll be an AI (yes, I know, over-used) sharpening which understands parts of the image and uses different sharpening methods for different parts. You could already do things like avoid sharpening skies and do selective sharpening on different parts of a face.

    Where we are now, Custom Blur is an interesting sandpit, and would benefit from the ability to set and use presets, plus being made a live filter.

  5. 9 minutes ago, Alfred said:

    So that explains three of the four ‘#DIV/0’ errors, Dave, because you’re dividing by mr instead of (mr+.001). But what about the last one, where the divisor is 6?? :/

    You're right, Alfred. How is that div0? Now I'm also puzzled.

    Edit: There's also the puzzle of the original post, where odd effects are seen.

  6. On 7/24/2020 at 9:33 AM, Chris B said:

    Hi Dave,

    Your equation is causing a 'divide by zero' error using 'greyscale' RGB values which is why it is not working on those colours.

    The equation has been broken down and attached in an Excel spreadsheet (also a screenshot incase you do not have Excel). 

     

     

    Thanks, @Chris B. Pardon delay in responding. Also pardon bug in code! I usually add .001 to divisors to avoid div0 errors but got lulled by ifmo variable mono tweak. I do use Excel to develop code, then concatenate and copy to APh TP. Please send my thanks to whoever found this.

    Watch out for interesting macros coming out in InAffinity channel. I'm currently having fun exploring possibilities with colour.

  7. Here's a funny thing.

    Load the attached RGB....jpg file. Procedural Texture. Add variable 0..1 called 'xx'. Put the following code (a snippet from some HSL tinkering) into R, G and B channels. 

    var mx=max(R,G,B);var mn=min(R,G,B);var mr=mx-mn;var ms=mx+mn;var ifmo=roundup(mr-.001);var ll1=ifmo*ms/2;var iflo=roundup(.5-ll1);var ss1=ifmo*(iflo*mr/ms+(1-iflo)*mr/(2-ms+.001));var ifrx=1-roundup(mx-R-.001);var ifgx=1-roundup(mx-G-.001);var ifbx=1-roundup(mx-B-.001);var hr=ifrx*(1-ifgx)*(6*roundup(B-G)+(G-B)/mr);var hg=ifgx*(1-ifbx)*(2+(B-R)/mr);var hb=ifbx*(1-ifrx)*(4+(R-G)/mr);var hh1=ifmo*(hr+hg+hb)/6;xx

    You should see the value which is in the xx variable (0 to 1, black to white) as the rest are vars. But what I'm getting is the variable acting on the colours within the image, but not the mono. Just to confuse things further, if you remove the last var statement (var hh1=ifmo*(hr+hg+hb)/6;) it works as it should.

    Don't know if its significant, but I created the image using shapes and no (white) background and exported it to jpg. I re-did this export and same effect. I then tried it with another exported file and had a similar effect.

    Something to do with exporting of files with no background to jpg? Still odd about the PT code effect.

    EDIT: Hmm. More tinkering. Don't think it's export. Happening also on fresh pixel image.

    RGBCMYKGW solid and gradients.jpg

    image.png

  8. 7 hours ago, Wosven said:

    A fill layer behave like a mask for colour. If you paint on it in white or black, it'll show or mask the colour.

    An invert will only convert this "white mask" to black, that's why you don't have any colour on it.

    It's different of a pixel layer. Rasterize it if you want to invert the colour.

    Might this be something for the Assistant to do? It does rasterise other layers.

  9. Take an image. Apply Blend Ranges and adjust transparency. Add live Unsharp Mask or High Pass sharpening. The moment the radius leaves zero, all transparency is lost on either and everything gets sharpened. I also  tried this on an image with Alpha adjusted via a Procedural Texture algorithm and the same effect happened.

    What gives?

  10. Holding down space bar invokes view tool with hand cursor icon so you can drag around. You know this.

    However, when you release the spacebar the cursor icon remains as a hand and does not revert to the previous function, even though clicking invokes the function. This can lead to confusion and unintentional error.

    Not a biggie, but one for those spare moments :)

  11. Yes of course. It simply was that I found I could draw the blue node selection area but with nothing to select. At the time I didn't know what it was for so was rather baffled.

    It's a general usability principle to not allow users to do things that have no immediate function and can end up with strange effects (like the blank Curves panel). So when there are no nodes, do not allow the node selection to take place.

    It's not a biggie. I was a programmer, then in software QA, so little things bug me. I report what I find, but then it's up to you to decide what to do about it.

  12. Ok - figured how having noded curve that Alt-click/sweep selects nodes.

    Can't replicate tips with polygon selection with just pixel layer. Hmm. However Alt-clicking around on a simple pixel layer still creates blue selection area (releasing Alt does not escape this), whence Ctrl-M brings up curves layer but without content.

    Not a biggie, but it would seem that confusing non-functional scenarios should be suppressed, perhaps throwing up an error message rather than ploughing ahead into strangeness.

    And yes, I'm on a PC. The dark side, and all that.

  13. Select node tool. Tips at bottom of page include Alt-click for polygon selection. Tips then change, now suggesting actions for lasso selection. Playing with this it seems to be a part-complete feature. You can draw, but Return or closing path makes selection disappear. Hitting Ctrl-M when selection visible leads to a curves panel without the curve.

     

  14. It would be nice if there was consistency in the treatment of categories, folders, presets, within and across folders. This includes New document, Swatches, Macros/Library, Procedural Texture formulae/Categories and general Adjustment Presets.

    The basic and very welcome principle is of preset 'recipes' that are offered either as defaults or as user shortcuts. As users use the products more, and especially in professional settings, consistency is very helpful.

    Key elements of a useful and consistent preset system include:

    • Creation and deletion
    • Containing folder/ategory system, including folders-within-folders hierarchy
    • Naming/renaming
    • External export/save and load
    • Editing (especially macros, please)

    What else?

    It's understandable as different sub-teams implement variations specific to local requirements, but architecturally and usability-wise it gets increasingly messy.

    Coding-wise, I'd suspect useful efficiencies could be gained here.

  15. I'm working on isolating the maximum value colour in each pixel, so in Apply Image I'm successfully using:

    DR=SR*rounddown(1-(max(SR,SG,SB)-SR))
    DG=SG*rounddown(1-(max(SR,SG,SB)-SG))
    DB=SB*rounddown(1-(max(SR,SG,SB)-SB))

    rounddown is effectively a boolean operator that reduces this expression to 1 or 0, which happens when the R, G or B value is the same as the maximum value.

    Implementing this in Procedural Texture I'm getting an illogical and different result.

    R: R*rounddown(1-(max(R,G,B)-R))
    G: G*rounddown(1-(max(R,G,B)-G))
    B: B*rounddown(1-(max(R,G,B)-B))

    In a test case using B to check out differences, the evalution of B differs *sometimes* when Blue is the maximum. I suspect a rounding or clamping effect, so (max(R,G,B)-B) is not sometimes wholly zero when B is maximum. An example where this evaluation fails is RGB of 102, 109, 135. This seems to be happening more when the value of Blue is higher.

    A fix is clamping the max calculation, B*rounddown(1-clamp((max(R,G,B)-B),0,1)), but is a kludge that shouldn't happen (and, I'd suspect, most users would not find).

    Procedural Texture, for some reason, seems to calculate much faster than Apply Image. Not sure why this is. When PT calculations don't need kludges I'll move over a number of macros I offer in my InAffinity YouTube channel (which currently take several minutes to calculate in Apply Image).

    APh version is 1.8.0.585

      

×
×
  • 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.