Medical Officer Bones

I think that you might have misunderstood my explanation: unlike Affinity Photo (or any other image editor that I am aware of), PhotoLine's layer opacity setting ranges from -200 up to +200. It is the only image editor on the market with that option for layers: Photo, Photoshop, Gimp, Pixelmator, etc. all offer a range from 0 to 100. And a negative layer opacity setting also allows for any adjustment layer's effect or blend mode to be inverted. This entirely novel concept of a -200 --> +200% layer opacity range setting falls outside the usual sphere of experience of most users (whose familiarity with layer blending is generally limited to a 0% --> 100% range). It falls outside the usual accepted paradigm how layer-based image editors work with layers. I did indeed work with the flattened original image, and applied a live unsharp mask adjustment layer with the same (or similar) settings as mentioned by the OP. I then changed the layer opacity to - (minus) 100%, which inverts (reverses) the baked original unsharp mask effect (up to a point, of course, since it is a destructive effect which removes original data).

Never really thought about reversing unsharp mask, but I will play too. The only image editor that I know of that can apply a filter "in reverse" is PhotoLine. So I opened the above image in it, applied an unsharp mask adjustment layer, and reversed the layer opacity to -100 (PhotoLine allows for negative layer opacity values which will invert an adjustment layer's effect). On the left, the original. On the right, the original oversharpened version. In the middle, the reversed unsharp mask filter (9.2 size). Unsharp masks destroys part of the original information through blurring, though. It can never be restored fully. The sharp highlight spikes remain, and should be filtered out in post. That said, the inverted unsharp mask version does look improved.

Hm. As it happens Krita was released a day ago for Chrome books and tablets. For free. That's a pretty awesome app to have on Chromebooks. https://krita.org/en/item/first-krita-beta-for-android-and-chromeos-in-play-store/ I agree that Affinity would be a good fit on Android, but I suppose it's the same issue as a Linux version, which would require a completely different port, which in turn requires a lot of energy, time, effort, and money.

Many other vector illustration apps on the market today already support DXF import & export: PhotoLine, CorelDraw, etc. Heck, even LibreOffice Draw will import and export these files. Aside from this, Designer needs vector fill support for this type of work, which it does not at this time. The competition, meanwhile, do. Apps like PhotoLine and Illustrator also support vector fills with the fill bucket tool to quickly fill areas independent of the actual vector shapes. There is still some catching up to do for Designer before it becomes a truly attractive proposition to architects...

One difference between your screen setup and mine is that yours runs a retina resolution, while mine does not. But no matter, exporting your vector art for this type of work generally works better if the lines and fills are aliased. To answer your question, no: that is currently not possible in Designer. You will have to export your work as SVG (for example) and import it in an design application that will support this. I myself use PhotoLine for this: import SVG in a bitmap document with the correct resolution, turn off the anti-aliasing (one click on/off button), and export as PNG. That is what I did in my Redbubble test as well: 1) created a design in Designer 2) export as SVG 3) create a bitmap document in PL at the required resolution and colour space 4) place SVG, and scale it accordingly. 5) turn off anti-aliasing 6) export to PNG. Upload to Redbubble. Until Designer gets a similar anti-aliasing on/off option, we will have to rely on secondary software to perform this step.

I actually did upload both an aliased and anti-aliased high resolution version of the same graphic to a test account of Redbubble, and couldn't tell the difference. I am acutely aware of the lack of a "turn all anti-aliasing off" button/function in Designer, though - one of the reasons I often have to switch to other apps. The question I have therefore is whether the final physical product quality shows any obvious difference (printed on a cup or a tee). The web interface in Redbubble is quite small, and cannot be scaled in a responsive layout manner in the browser. I can't tell much from that small product preview. I would have to see the final print on a product to tell if it makes any difference at all. It depends on various things. So have you ordered a test print of your pattern? Or is there a high resolution preview available in redbubble that I have missed?

I tried this with a sharp-edged non-aliased PNG vector design. You seem to zoom with the browser, and I get the exact same fuzzy result when I zoom into the page with the browser zoom. Which makes sense: the preview is only making use of a low-resolution version. Don't zoom into the view with the browser. Does the issue arise with the actual physical product or preview images on the site?

Nope, not the only one 😉 I agree with @Kuttyjoe : the way the controls are implemented in Photoshop for rotating the view is less from ideal. And I concur that the huge wind rose that suddenly appears in the center of the screen while rotating is quite distracting. Never liked that at all either. As far as shortcut keys go, I actually prefer Krita, which is more in line with how 3d applications layout similar controls: <ctrl> middle mouse button zooms and shift middle-mouse button rotates the view. I find ClipStudio's space-shift/ctrl not as comfortable, because the action requires two fingers simultaneously pressing down keys on the keyboard. Using a similar control method as Krita would be in line with how Affinity uses the middle mouse button to pan the view. @Pierre68 The anti-aliasing of Affinity's rotated view is absolutely dreadful (at least, on Windows it is, and I have not tested Mac yet). It is unusable in my opinion. Before the devs implement a proper view rotation, they need to deal with that first and foremost. Zoomed in inks at non-decimal percentages look bad as well in Affinity Photo compared to ClipStudio and Krita. ClipStudio looks best in this case. In short, my work requires a lot of inking, and I cannot tolerate Affinity Photo for this type of job. Even if I wanted to. PS on a side note: on top of these issues, a major problem is the bad interpolation while drawing zoomed out in Affinity Photo. For example, when I work on a 10000 by 5000 px canvas in Photo, and draw inks (thin black strokes) zoomed out, the resulting strokes display kinks and straight interpolated sections. This does not happen in either Krita or ClipStudio (and yes, even when I turn on the stabilizer at low values: I hate using a stabilizer that is set to strong values - If I can, I turn it either off or down to the minimum).

@Jowday Could not agree more. Well said.

The OP might be pointing at the lack of a built-in text/article editor, and the reliance of Publisher on external tools for text editing.

Done some research online. Maya IFF files are not the same as the old IFF format, and may include 16bit and z-depth channels. But why not use the converter utility that is shipped with Maya to convert from and to IFF? https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/Small-Utilities-imgcvt-htm.html

Are Maya IFF files identical to the classic IFF files? If so, use IrfanView or another image viewer compatible with IFF files to convert to a format that Photo understands. I doubt Affinity Photo is ever going to support IFF files.

Other recommendations: if possible, export as vector SVG files. In this case there is no need to worry about multipliers. Do make sure the SVG code is responsive, and automatically scales up and down in a HTML tag container. Even better, if you deal with GUI elements, work with the built-in framework GUI options. For example, instead of exporting that flat button design as a bitmap, use SVG. But if that same button design can be replicated using HTML and CSS styling code, definitely run with that last option. Built-in GUI components tops SVG which tops bitmaps. If it can be helped, never use JPG for sharp looking text, line art, logos, vector work, etc. JPG works well for photos and multi-tone images, but visibly degrades those aforementioned types of graphics due to the lossy compression algorithm Instead, use PNG. If your work consists of less than ~256 colours and tints, indexed PNG files are preferable and save file space. The best way to compress a PNG is worth an entire post by itself. Suffice to say, to best compress and optimize PNG files dedicated tools are required. Image editors are not that great at it. I use ColorQuantizer, which is (in my opinion) the best PNG optimization tool currently available. Only for Windows, though. But worth it and free! http://x128.ho.ua/color-quantizer.html WebP is also excellent for both photos as well as sharp non-lossy assets (WebP support both lossy and non-lossy), and supported by all major browsers now. Except, of course, Apple. Safari does not support it. 😞 Neither does Affinity, which only opens these files, but does not export to webp. @Ali1 Your original issue has to do with attempting to export a 600x100 px asset "as is" from a vector package. In my experience there is just NO chance to get a good quality acceptable result, even in Illustrator. This is caused by a couple of things, such as non-decimal positioning, which adds unwanted soft anti-aliasing to the edges. What works well to maintain high-quality sharp looking anti-aliased low resolution assets are the following steps: work at a 3 to 4 times higher resolution. export at that bitmap resolution. Optional: perform some pre-downscale sharpening. open the result in an image editor like Affinity Photo, and scale down to the required lower resolution. Optional: perform some post-downscale sharpening. the result will be much better looking. Ideally use a downsampling algorithm such as Catmull-Rom. This works extremely well to maintain sharp details. Unfortunately, most image editors do not support this. Of course, if you are already working at a @3x or @4x multiplier, the above steps generally are not required, because your base resolution is already very high. But it depends a bit on the image editor: the only way to check for quality is to go though the above steps at least one time, and compare your manually exported version with the automatic ones.

Help! I accidentally hid a response post that I was writing, and I can't seem to retrieve it anywhere. I would hate to think I'd have to write it again...

Some confusion regarding web resolution, PPI/DPI, how to prepare for the web, and such. DPI is completely irrelevant for web and screen (mobile/tablet/desktop) work. Forget about DPI or PPI. It tells nothing about the actual resolution of a file. 1 pixel can be saved at 50000ppi, and a million pixels at 1ppi. It is merely a parameter that tells print software at what relative size it should be printed. Technically DPI is the wrong term in Affinity's dialogs. PPI (Pixels Per Inch) is the correct term. For web/screen export, think PIXELS. When designing for screen output only pixels count. Forget PPI! Screen tech and software ignores that parameter. In the early BFP (Before Flat Panels) resolution of screens was more or less related to the size of those screens. The larger the CRT screen, the higher the possible resolution. 1 pixel equated to 1 pixel. I was very simple to calculate the required resolution/pixel dimensions of an asset for a web page: just export at the exact pixel size required. For example, if a logo had to be placed at 600px by 100px, that is what you exported and prepared it at. PPI was (and still is) entirely irrelevant. Things changed quite a bit AFP (After the introduction of flat screen technology). No longer can we relate the physical size of a screen to its physical pixel resolution. The first iPad had a 1024x768 resolution. The iPad 3 introduced the retina screen, which offers double that: 2048x1536. The screen size did, however, not change. Nowadays much smaller screens than an iPad screen are capable of displaying higher resolutions than that. Desktop screens display 4K or even 8K now, but the actual physical dimensions of those screens are similar or the same as the previous generations. This poses a problem to screen/web designers: at what pixel dimensions should assets be produced? To solve this problem the concept of MULTIPLIERS was introduced by screen designers. The multiplier tells the designer at what pixel dimensions a bitmap asset should be exported. The goal is to hit the native pixel resolution/dimensions for each targeted platform/screen (or close to that resolution). Example iPad 1: assets are exported at the native resolution (related to 1024x768 pixel screen). We prepare @1x: 600px by 100px. Example iPad >3: this is a device for which we prepare @2x assets: 1200px by 200px Result: we deliver two assets when our target platform is the regular iPad. For web export, at least @1x and @2x assets are required. When using the correct responsive <img> tag code, a browser will load up the correct version depending on whether the screen it is viewed at is retina or not. At this point the screen designer must realize that only providing a @1x asset will result in fuzzy looking bitmap graphics on a retina screen. But many handheld devices have far higher PPI resolutions (recall that PPI tells us about the relationship between the screen size and the native screen resolution). Very small screens at incredible high resolutions. @3x, @4x, and even @5x. How do we figure out the multipliers? Answer: we check the configurations, and calculate the multiplier. Luckily, someone already did this for us: https://material.io/resources/devices/ This means that BEFORE designing any bitmap screen asset, the designer MUST decide what the highest target multiplier must be. And create the bitmap asset at that highest resolution. At this point a "pixel" as a unit is unsuitable as a base unit when discussing the dimensions of a bitmap asset. Therefore, DP and PT units were introduced. DP ("dip"(s)) is a Google coined 'unit'. PT (point(s)) is Apple's preferred 'unit'. Example: We need to prepare a 600px *100px bitmap asset. When we communicate this to our fellow designers and developers, we no longer use pixels, but either dips or points. 600dp/pt by 100dp/pt. Next, we must decide on the highest multiplier: with @3x we target most devices right now. We then define the highest resolution with the formula 3x600 and 3x100. We create a new document at 1800px by 300px, and work at this base resolution. This is required for all our assets in this project. When the final asset is to be delivered, export all multiplier versions with a standardized prefix or suffix which indicates the multiplier. In our example above, that means three bitmap assets: logo.png, logo@2x.png, logo@3x.png

Thanks, wasn't aware that would work in all three apps.

Thanks, I tried ALT myself, and it did not work on the Windows version.

The simplest and most controllable method with the best result is the method I described above in Designer. Open the page in Publisher, place all comic pages, and the Designer-made compound balloon will be available in Publisher too. Create a couple of default balloons in your Symbols library, and when you work on a page, switch to Designer in Publisher. Drag a balloon symbol from your symbols library onto the page, and detach it. Then adjust it according to your needs. This works really fast: Create a new page in Publisher, place your artwork. Switch to Designer mode add the balloons. Detach them. Then adjust the balloons. Return to Publisher. Next page. And so on.

Yes, unfortunately still no free transform of vector objects. But not really necessary to do a proper comic ballooning job. As long as we can rotate and scale it's fine.

When you select both the tail and the balloon in Designer, ALT-click the ADD boolean tool in the tool bar. This creates a non-destructive boolean (something Photoshop cannot do, I believe), and the new balloon layer can be opened to reveal both components. Each one can still be moved and transformed and edited individually. Like so: Tip for nice looking tails: - keep the handle lengths to 1/3 max of the curve length - the tail root handles ideally should be kept parallel or close enough to it.

That is exactly the issue: there is no free transformation possible in Photo which maintains the vector status of the tail. It's been a much requested feature, but so far no cigar. Perhaps in 1.9. And boolean operation in Photo and Publisher are destructive, so it is not possible to keep the balloon and tail separately position-able. It is in Designer, but there is no warp option in Designer. Which means the simple task of quickly deforming the tail and keeping it vector is (as far as I am aware) not possible. You can deform, but it becomes pixels. You can work with vectors, but not freely transform it. Which resolution are you working at in FireAlpaca (just out of curiosity)?

Designer supports that: alt-click on a boolean operation to create a non-destructive merge, and then twirl open the compound, move each part separately.

Couple of things to consider: - Photo has no quick method to warp objects by dragging only one corner point (CTRL-T Free Transform in Photoshop equivalent is missing). This is quite frustrating for this type of work. I speak from experience. - Photo does not support 1bit high resolution inked art. This means you must work at 1200ppi and full RGB, and later convert in other software. Unsure whether 1.9 will have 1bit TIFF export to at least work around this hefty limitation for comic related work. - as far as I am aware there are no non-destructive booleans/compound paths option in either Photo or Publisher. Only in Designer. This does impede the workflow somewhat in this case. Ideally the balloon and tail should be able to be positioned separately. This can be achieved in Designer, though. - You may want to place your ink work in Designer, or use Publisher to layout your comic as a comic book. But both will convert your 1bit inks to RGB or CMYK when exporting to PDF. If you are relying on high resolution inks to be overlaid on top of multi-tone colour work, Affinity cannot accommodate that workflow at this time. Perhaps with 1.9? Unknown at this time. If you work with high-res 1bit inks, this makes it impossible to work with Affinity and (semi)professional comic publishing work at this point of time. Disregard all this if you have no idea what I am talking about or you are not interested in actually printing your comic, and only mean to release it on the web or digitally. In that case you are probably working at RGB 300ppi anyway, even when inking. The result will be lacklustre when printed, but for web work it is fine.

That does not matter for the user experience: in Photo the default behaviour ought to be that pixel alignment is always on for bitmap layers.

In my mind bitmap layers should never ever be affected by non-decimal movement/placement. Bitmap pixel information must be maintained, and Affinity's behaviour is somewhat unacceptable. The user should not be forced to turn on pixel alignment to prevent the blurring of bitmap information. With vectors and text this behaviour is understandable, and it is correct to have adjustable options how to render the pixels. Not when editing bitmap layers, however. Pixels must be absolute, and not be affected by such settings. Pixel alignment ought to be the 'default' behaviour, just as it is in pretty much any other image editor.