Jump to content

Lorox

Members
  • Content Count

    139
  • Joined

  • Last visited

About Lorox

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes sure, it took me a while (and a visit to the Affinity forum...) to discover that button and learn about its significance. But it's a bit of a peculiar way to do it, I find. Looking at your examples, I think it is quite strange, that you can obviously assign a fill color to an image that already has (mixed) colours in the first place. With a grayscale or 1 bit TIFF on the other hand, it seems just natural that you should be able to replace its original inherent colour (black) with another one, but when you do this with a full color image the underlying logic seems not so clear. Do you have some sort of "rationalization" to understand what might be happening here? In your examples those with just an fill color assigned look a bit like they probably would when you first convert them into grayscale and then put the fill color above them in "Overlay" mode (or when you use the "colorize" mode of the Hue/Saturation adjustment in Photoshop). Plus the "K only" they look more like grayscale images just printed with the assigned fill color instead of black (where in case of CMYK that pseudo-grayscale color image looks like just the K channel of the CMY image).
  2. Absolutely so! I was quite baffled when I discovered that the Affinity apps are obviously still ignoring this format (meaning: 1 bit strict b/w images) – especially as there is no such export option in Photo. Also, the whole business of colouring grayscale images in layouts – which used to be so easy in the Adobe apps – is handled in an unnecessarily complicated way in Publisher. Although I generally love to use it there's still some headroom, I'd say.
  3. Thanks a lot! This feature – while so intuitively to apply in InDesign – is certainly well hidden in Publisher... I'd never have looked there!
  4. I'm not quite sure how this is handled in the Affinity apps but I've worked in InDesign for a long time and in InDesign's colour management settings you could/can set the rule that CMYK content preserves/keeps its "numbers" (meaning its original CMYK values) when placed/pasted into the layout document. This actually makes a lot of sense to me as this way I could/can be sure a logo's colours defined for print with certain CMYK values in fact "migrate" 1:1 from the original – say – Illustrator logo design document to the layout document (and on to the PDF for printing). This way these colours are treated exactly the same way as if they had been just assigned within – say – InDesign using its current colour profile. Accordingly they don't get changed when in exporting the PDF for printing that very colour profile is used. So the logo's CMYK colour values will be exactly the same in the PDF for printing as they have been in the original CMYK AI design file (which is what you generally want). As I said I'm unfortunately not eactly sure how this really works in Affinity Publisher and Designer... (I definitely wish I knew exactly – I'd feel quite a bit more relaxed when giving PDFs away now that I'm trying to adopt the Affinity apps as my premier go-to design apps...)
  5. Not necessarily so. As it has been said it depends on either (most) common usage in a certain area of the world or what the printer who's gonna do the print job for you expressively asks for. There are very likely to exist established or standardised workflows in regard to specific print processes (sheet offset, roll/continous offset, newspaper print or whatever). You should possibly ask your printer(s) for information about the standards they adhere to. I personally mostly use the ISOcoated_v2 colour profile for CMYK being the one that's most commonly used by printers around here. Or ISOcoated_v2_300 which is basically the same but limits ink coverage to a maximum of 300% which is preferred by some of the bigger online print services as printed sheets dry faster when there is less ink coverage. That said, one should remember that regardless of the profile you have initially set for your (layout) document (even if that should preferably be the most common one in your area) it is actually the job of an application's internal colour management to create the final PDF for printing according to the profile you haven chosen in your output/export settings! You may have initially created our design for usage in regular sheet offset printing, but when your client then needs another PDF to be sent out to be printed on sort of "spongy" newspaper stock you will most certainly have to export your design using a CMYK profile which separates the colours accordingly (i.e. most likely with considerably less ink coverage). That's what Colour Management has been meant for in the first place. Mind, however, that all this predominantly applies to outputting final printing PDFs from a layout application like Affinity Publisher or Adobe InDesign! Colours of CMYK vector objects should – in my opinion – be preserved anyway 1:1 by the layout application they are placed or copied into, because it generally seems to be a sound assumption that the colour values defined in CMYK for these objects are actually meant to be precisely as they are (e.g. in logos etc.). On the other hand photos – and generally photo-like "pictures" – can or should be left as they are (assuming they have an assigned colour profile that's saved inside of them and that is detectable by – say – Affinity Publisher) – for purposes of correctly display on screen the layout app should be able to convert the colours according to the profile chosen for itself (the layout document). For purposes of creating a PDF for printing the export settings should take care of that.
  6. If I may contribute something from my angle as a graphic designer working mainly for print: I personally very much prefer or suggest starting from CMYK (if not black and white only) when designing a logo. Starting from CMYK ensures that the logo will be printable by offset printing quite exactly the way it has been seen on screen before (given, of course, that the system/display is more or less calibrated). As the CMYK colour space is considerably smaller than the common RGB colour spaces, the logo begun in CMYK should be easily reproduceable on screen once it has been converted to RGB as there are almost no colours in CMYK that cannot be closely reproduced in RGB. Given that the vast majority of displays in use will not even be able to truly display any RGB colour space bigger than sRGB it seems reasonable or sufficient to me to produce an RGB-version of the initial CMYK-logo using just that sRGB colour space. There may be exceptions, however, if you consciously and decidedly design for screen only and really want to push one or the other other colour for that vibrant (if not garish, posibly...) highly saturated, almost neon colour look as it is possible in RGB with some hues. These sort of colours just cannot survive in CYMK, though. So you'll lose them and will be forced to accept considerably dulled versions of these after CMYK conversion, should the necessity arise at some time to have a print ready version nevertheless. Alternatively you might consider to create a version of your logo not using (just) CMYK but adding a suitable vibrant PANTONE spot colour (or even a fluorescent spot colour).
  7. I guess Chris26 (and the article he'd referred to) made the topic relatively clear and understandable – at least as we're talking about RGB colour mode. This given, I'd think this will be useful predominantly for photographers whereas converting from RGB to CMYK (and possibly from one CMYK profile to another) will be important to designers doing work that is bound to be commercially printed using e.g. offset printing. In this area it might be crucial that certain colours will not be changed at all and be printed with the exact CMYK values which had initially been assigned to them (e.g. for some corporate design or house style) whereas colours in pictures (RBG and/or CMYK) placed in the design actually should be converted to fit the actual printing process/workflow and thus appear – visually – unchanged in the end (while in fact their colour numbers/values have been more or less altered in the process). It can actually get a bit complicated when a proper prepress workflow is concerned. In this respect Affinity Publisher has given me some headaches recently as black text/type – which in CMYK printing should normally be just 100% black (with no C, M or Y in it) – had turned out to be a mix of all the four components of CMYK in the PDF meant for sending to the printer's shop. It could be corrected in the end, but one has to double check and be quite careful – mistakes can happen easily as it seems.
  8. Yeah, I think it's obvious that when you go from RGB to CMYK (or vice versa) there must be a conversion. When going from one CMYK profile (say Fogra27) to another (say ISOcoated_v2) you sort of can decide whether the colours already there in the document should maintain their given CYMK values ( > Assign) or if the colour's appearance should be encoded according to the values the new target CMYK profile considers appropriate ( > Convert). However, I've encountered some recurring difficulties regarding colour profiles myself and I'm not sure what to finally think about it...
  9. More often than not I find myself cursing when I check the PDFs for print which I‘ve exported from Affinity Publisher: elements I thought were "Black“ (meaning just 0C/0M/0Y/100K) turn out to be some "RGB-Black“ with variable amounts of CMYK respectively, even though I chose some "real" CMYK colour profile like ISOcoated_v2 when I first set up the document. Usually I can correct this when I go back the document setup and „Assign“ (seemingly for the second time) my profile (usually ISOcoated_v2 or ISOcoated_v2_300%) that's already listed there as the document's. When I then check my blacks they appear to have changed to 0C/0M/0Y/100K as I thought them to be in the first place... Does this really mean that it isn't sufficient just to choose the said CMYK colour profile from the list when setting up the document? Do I then actually and expressively have to once more ”Assign" it by pushing that button to make it "really active"? One would think that just choosing the profile from the pop-up-list on document setup should be enough... That said, I'm really glad that I have an older version of Acrobat Pro installed on another computer so that I can reliably check the PDF exported by Publisher (and e.g. notice strange Blacks) before sending them off to the printer's. As for now I'm quite unhappy, though, that I seemingly cannot trust Publisher to immediately create correct PDFs from a document that appeared to be correctly set up (whereas InDesign actually DOES this once you've generally set your colour profiles for the whole suite of apps). Though I generally do love working with the Affinity apps I'm not happy at all about the way the apps deal with colours – be it in respect to colour profiles (as noted above) or in the way swatches can be managed in the corresponding panels. I almost hate to say it, but I think Adobe still does a better job at this...
  10. It's like that. With the problem described AndyQ seems to back our feelings/impressions perfectly: after some time anybody working in pixel graphics will have realized that pixel masks ARE in fact just grayscale images applied in certain way to select corresponding pixels (meaning those having the same 2D position on the canvas) and allow to do certain things to them (i.e. adjusting their opacity etc.). This given it seems only natural that masks should be editable just like any other grayscale image (including copying, pasting, painting in it, filtering it etc.) once you have them as the contents of your active window. In Photoshop this is very much the case once you know how to make the mask content visible as the actual content of your active window. It doesn't take more than just going to the channels panel and clicking on the mask's channel – there you go and it's easy and intuitive. And turning the mask's content to a selection which you then can use in any pixel layer, adjustment layer, channel or other mask of your file is just one more click away... In Affinity Photo this whole "field" of channels masks, selections and pixel layers is generally organized in such a "fragmented" approach that it becomes ”cryptic" as no obvious logic becomes apparent: so it becomes hard to understand and cumbersome to use. In effect you experience exactly what AndyQ said: you spend a day on a job which you could have finished in an hour with Photoshop. And true: as the way of achieving comparatively simple thing is so unnecessary complicated you're prone to have forgotten at least half of it of it by the time you have to work on the next job needing this a month later. Please, to all you developers at Serif: I guess there are quite a number of guys here among us who REALLY WANT to work with your apps, who REALLY WANT you to succeed long term on the market. The workflow must become smoother, more unified and necessary actions for closely related goals should not be scattered over different places in the UI. I'd think in the end it just has to be at least as efficient as it is with those applications you – rightly – chose to challenge. Let's be honest: there may actually be a limit to the time professional users can afford to spend with Affinity Photo or Designer on jobs they could have finished in a fraction of the time needed if they had just reverted– however much loathingly – to Photoshop and Illustrator.
  11. Exactly! I often find myself quite impressed with what you can do in Affinity Photo (same in Designer and Publisher BTW) but at the same time I'm often sort of turned off midway in a job by the clumsy and uncomfortable way to get these things actually done within the apps. The Affinity apps regrettably – in several aspects – still lack an "elegant" and intuitive ergonomic concept. Especially Photoshop, however, has developed and refined this approach quite convincingly over the (long) years it has been on the scene. To really compete with the Adobe apps it's not sufficient for the Affinity apps to just let the user come up finally with (about) the same results he'd get using Photoshop & Co. but he must be able to get there by a workflow that's at least as easy and convincingly ergonomic as it is with the (still) market leader. Having to go to two places in the menus and one place in the control bar and/or context menu to get something done, what the rival makes possible with just a click (OK: maybe with some additional modifier key...) won't do the trick eventually. I REALLY do want to make the transition and I'm absolutely thankful to Affinity/Serif for having taken up the challenge. I actually admire what they've achieved so far, but PLEASE keep on working on the ergonomics of the apps to make the users enjoy what they're doing in the most satisfying way!
  12. Exactly! This is such a basic feature for the efficient management of a document's colours that still having to request it seems quite strange actually (especially for a program that's set to rival InDesign...) There isn't a feature yet for the swatches palette like "List (or add) unnamed", is it? (I hope I haven't missed it) This one has served me very well with InDesign and Illustrator in the past to gather all the colours actually used in the document... While we're at it: being able to "Select unused" in the colour palette (and then deleting them; like it's possible in ID and AI) is also a very useful means for slimming down the palette and getting rid of all those colours you don't use anyway. Last but not least: deleting a colour swatch from the palette and being given the option to replace it with another given one while doing so is another very helpful feature to efficiently deal with a document's colours. Again, in InDesign you have been able to do so for 10+ years...
  13. As this appears to be pure (and basically not that advanced) math – exactly what a computer should be able to do efficiently – you'd think it really couldn't be so hard to implement. For the user it eventually shouldn't be more than: Choose a point for the axis to run through, choose whether it's going to be horizontal/vertical/at-an-given-angle and let the machine compute the new coordinates...
  14. As much as I love working with Affinity Publisher I'd wish there was a simple menu entry for this like in InDesign...
  15. That's unfortunately true... I'd love to see that feature in Designer as soon as possible. BTW: "14,551 posts"??? How on earth is that possible?
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.