Dazzler

I imagine this is a dithering algorithm making a blend between two values that won't interpolate further?

Hi Gabe, Thanks for looking into this. Here's the design file I saved. The black block with the white lines is what I used to make the brush from (just exported that element as PNG), and hopefully the brush line will emain anyway? This raises the question, if I save a file like this does it carry the brush information with it that is needed to recreate the design? If so you should see the red lines over the top, otherwise I guess that may not be showing. I've attached the exported png anyway, and also the brush (hopefully if I've done that bit right!) The issue is easily recreatable - it'll be the same with any pattern that has lines running diagonally, or some repeating pattern like this. Thanks, Darren brush test.afdesign Brushes.afbrushes

That's similar to my method, apart from my method is probably a bit quicker as it doesn't involve carefully working out the pixel sizes of the resize document - you just basically make sure it's big enough to allow the extra surround that you want (which you can do easily and visually with the crop tool as I mentioned). Any excess that is left after can easily be removed using the Document > Clip Canvas once you've done everything else. I'm not sure why step 2 didn't work for you? I have the same version and it works for me. You will need to have the image layer selected for it to work with that. Alternatively, you can CTRL(CMD)+click on the thumbnail of the layer to make the same selection. Also, the Select > Outline only seems to give a radius measured in pixels, so the 1.5mm might be troublesome to work out. But it's there as an alternative if you can get it to work.

I think there's maybe another way to do this. No rectangles and no manually drawing anything, so a fairly accurate way to create set sized frames around a picture. 1. Open your image and using the crop tool expand it to allow plenty of space for the borders/framing around your image. (pull the top left corner outwards followed by the bottom right corner outwards). Unlock the layer if it is locked. 2. Choose Select > Selection From Layer. This should put a selection around the outer edges of your image. 3. Choose Select > Outline. You will now get a dialogue showing a radius control and an alignment option. Choose 'Outside' in the alignment option and then use the radius control to choose the width of the inner frame that you want to create. 4. Choose Edit > Fill to fill the frame with a colour of your choice. 5 Repeat steps 2 to 4 for the outer frame (note that step 2 now selects around the edge of the inner frame that you've just created. You could continue this to add further frames easily. Hope this helps.

There may be another workaround way for certian situations ... do the normal circular corner tool and choose the largest radius out of the two you want, then bake the corner choose the two nodes at the sides of the curve and select the 'transform mode' icon in the context bar at the top, which you can then use to squash the corner up a bit. Not very accurate but depending on the exact requirements might work in some cases? It's certainly easier and less cumbersome than the boolean method, but is going to be less accurate of course.

...actually I think I just worked out what the MBWP is for - if you are creating small sprites/icons and find a nice alignment of pixels using a vector that is sat off of the pixel grid, it means you can move it around without losing that pixel setup (ie. keeping the anti-aliasing the same). That might actually be important in certain situations.

IMHO the force pixel alignment should force any creation, movement or adjustment to snap to the nearest pixel. However, move by whole pixels is obviously not compatible with that. It's a bit odd and I think the two should actually be completely separate from each other so you can have one or the other turned on, not one as a sub option of the other. If you stop and think about it, the Move by whole pixels is actually kind of redundant if you have an option that snaps everything to the nearest pixel anyway. But I guess the thinking is that if you have a shape where not every node is sat on a pixel division and you want to move the shape, you don't want every node on the shape to snap to a pixel division because that would change the shape, so I think this is where the move by whole pixels comes into play? Having said that, that doesn't appear to happen anyway, so the move by whole pixels does seem a bit redundant. It's really handy though if you don't want to snap to pixels and want to move something by whole pixels <stares into space and tries to picture situation that requires this>

Yeah that's a real shame, and a bit of a surprise. However, in general I really like the way they've separated the 'macro' parts from the image type in Photo - so converting to different formats whilst applying a macro at the same time is a breeze compared to a PS macro, where you have to deal with the 'override file open' type things that never seem to work as you'd expect them to. It's early days with this software - and once they've cracked these early bugs it should become a fantastic piece of software.

Maybe the cog thing is a protected piece of IP that can't be done here? But yeah in PS that would be an option. Anyway, 'tis a bug, has been noted by the devs and hopefully they'll fix it. It should recognise when recording the macro that you've unchecked the resample button, and at that point the dimensions should not be recorded into the macro (because they are not relevant in any way) and it should replicate the DPI change only when played back.

Yes, just check the bug reports and it has been reported and logged - it's a known bug.

Yeah, that kind of defeats the purpose of recording macros. You should be able to do DPI changes like this without the image dimensions being affected by the macro. I'm saying bug!

No I wasn't saying that at all ... I was testing this myself and finding out there's what looks like a bug here. It's recording the dimensions of an image when it shouldn't be.

@firstdefence Try recording this as a macro. Sure it greys out the size as normal, but it seems to record the image size of the document that I have open when I record the macro. So, say if I have a document at 100px x 100px at 72DPI and I record the macro (unticking the resample button as you've said, and changing the DPI to 300), I end up with my orginal image at 100px x 100px and 300dpi. So far so good. But now I export that macro, and run it on an image that is 200 x 600px @72DPI, and I import the macro and run it, I'd expect to get 200 x 600px @300DPI but instead get 100px x 100px @ 300DPI ?!!

What was the size of the document that you used when you recorded the macro? I suspect that's where the 4960x2965 comes from. It appears that it records the dimensions as part of the macro, even though you uncheck the resample. I'm thinking this might be a bug.

Alternatively, the Select > Select Sampled Color... option when clicked on will give a default selection around most of the items of all colours, however when you then click on a colour on the image it'll sample that colour and select items that are that colour and the tolerance control allows you to expand that range a bit if needs be. You can also keep clicking around in the image area whilst the dialogue is open to select slightly different colours etc.

You might find Select > Alpha range > Select Partially Transparent and then delete works here if the bats are completely opaque.

Or just get the entire set of Photo , Designer and Publisher . Seriously though, just drop your cloud subs for a couple of months and there's the money to do just that! From what it loooks like you're doing I'd say Designer is a much better tool for that than working in a raster package like Photoshop. Give it a spin and I think you'll see the benefits fairly early on. PS = raster with some vector abilities. Designer = Vector with some raster abilities. Publisher + Designer + Photo = everything in one place using the personas.

I've always thought of it as an additional constraint, however the two can't really co-exist, so the MBWP takes precedence. Personally I think if you turn on the MBWP it should turn off the FPA button, as that clearly no longer applies.

I'm not sure what you mean by composition area? Can you expand upon that and what you would use it for?

It happens in other software too. It's because if you take a one pixel line and position it half a pixel to the left (the fractional part of the position) it needs to now render that across two pixels (it will most likely do two half opacity lines instead of one full opacity line), to make it look like that's where it is sat. It's called antialiasing and is the whole reason the 'snap to pixel' style constraints exist.

The problem you have is there's not a lot of area available that shows how it would look without the car. It may be easier to clone a light trail in over the car and continue that up beyong the tree line. It's definitely not an easy job that one as either way you have to deal with lots of gradients because of how the lighting is - you'll have to find a way to remove the headlights on the road, otherwise there will be an odd bright spot for no reason. You'll probably need some decent painting skills for this!

Affinity Designer 1.7.3.481 Windows 10 (spec probably irrelevant here) So, I'm identifying this as a bug, but there may be other opinions about the way this works. Ultimately, fixing this will have an affect on older designs that use brushes. I've made a test brush pattern within designer as a PNG, and exported it (it's 200 pixels height and 568px width). So I then bring this in as a Textured Intensity Brush with a width of 200px to match the height of the exported brush image (black rectangle with white stripes). I then draw a path over the top widthwise of my original brush and assign my new brush - see attached image - brush is in red on the highlighted straight two node path. IMHO I'd expect that brush to be aligned perfectly with the original design now being that the length of the line is the same as the width of the rectangle, and the height is the same. So, heightwise it's fine, but widthwise it's off by a long way. More interestingly is when I use the node tool and drag the end node to the right the pattern will stretch, but then suddenly snap back to allow another repetition to fit in. This then looks very squashed. I would expect the behaviour along a path like this to be consistent - certainly on a straight line, so I think this is highlighting a problem with the maths algorithym - it looks like modulus is bieng used with the repeats but in a way that's not quite right. I'd expect that behaviour to be consistent from the start of the line running to the end, so altering points on the end of a long path with lots of nodes doesn't affect the brush pattern at the start end of the line. It should be working on length of line based from the start node. This is not whats happening, and thus why I'm reporting it as a bug. Brush settings are Width: 200px, size variance: 0%, Opacity Variance: 0%, default pressure curve, Body: Repeat, Head Offset: 0px, Corners: Fold (I tried them all here), Tail Offset: 568px (with a brush graphic width of 568.0px). I've just tested a thought I had and discovered that changing the stroke to Butt Cap makes the alignment on the image below perfect, however pulling out the node with that mode on still stretches the brush pattern a lot and then snaps back when there's more than enough space for two patterns to fit. My expectation would be that it would simply add pattern onto the end of the first pattern and allow it to get cut off at the end of the path, rather than stretching one pattern length until there's room for two pattern lengths. It's hard to describe, but it looks to me like the algorythm is working the wrong way round with the modulus. So if the line is 1.5 pattern lengths long, I'd expect it to be using two pattern lengths and cropping the second pattern halfway along. That way the start of the line would always look the same when you adjust the end point.

Hmmm this seems to highlight a problem (I'd call it a bug?) with the way the brushes are working. I've made a test brush as a PNG, in a similar way at an exact pixel dimension, and exported it (it's 200 pixels height). So I then bring this in as an intensity brush with a width of 200px to match the height of the exported brush image. Things aren't looking too bad, but with just a two point line you can see a problem - if you grab the node tool and slowly drag one end of the line out to make it longer you'll notice that the brush gets stretched, until it reaches a certain length, then it snaps back to allow another repetition to creep in, which then looks squashed. So rather than just extending the brush pattern and repeating it's actually affecting the brush right back up the path. This seems wrong to me - I think there's an issue with the maths in there somewhere. I can only imagine what a nightmare this is to program, but ultimately the brush should IMHO run consistently from the start point and be aligned with the length of the line, so when working on the end of the path it doesn't affect the beginning of the path. Affecting the brush width should really be the only thing that has an affect on the pattern position along the entire length of the path. Also, if my line is the exact length of my original brush graphic and has a brush width that matches the height of the orginal graphic, I'd expect it to align perfectly - it doesn't even come close. Edit: I've reported this as a bug. I have discovered that using Butt Cap on the stroke makes it align perfectly with the original so long as it is the same length, but upon pulling out the end node it still stretches the brush rather than repeating it as I think it should.

I'd also go 8 cores, I have a 6 core PC and just tested doing something in designer whilst looking at the CPU stats and indeed all cores (12 because of the hyperthreading) were being utilised. So with that being the case, in theory with the 6 core you'll get 15.6 - 27 Ghz total, whilst with the 8 core you'll get 18.4 - 38.4 Ghz total. Of course it doesn't work exactly like that due to the way cores are utilised and managed, but as a guide it's probably good enough to go by.

Thanks very much Callum, that looks like it's the way to do it, and I was trying to do that earlier but it wasn't working, but I've just reaslied why - I had the layer locked! Doh! It works better if I turn off the 'Show pixel selection' in the view menu, I can see what I'm moving properly then.