Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Lagarto

  1. I can confirm the same behavior on Windows (release does not wrap, the beta does). The problem is related to TIFF file's transparent background. If the file is saved flatted (without transparent background), it will wrap also in the release version.
  2. What probably happens here is that when you export, you do not convert the CMYK image to RGB but just pass it as it is, without embedding a profile. When such file is viewed in an app that does not color manage CMYK images without a profile, you see the kinds of "weird" colors you describe. Most apps can nowadays show CMYK images using some common CMYK profile as a reference of rendering, but most browsers show CMYK images without a color profiles by using direct conversion, so what you see is something like below (this is less "psychedelic" in forum screenshots, but in context of wide-gamut displays color difference can be remarkable). Google Chrome browser: The top image has CMYK color profile embedded, the bottom image has not. The images have identical color values: When you open the same file in e.g. Photo or another app that is color managed and assigns a working CMYK profile to unmanaged CMYK images : You can avoid the problem by exporting your CMYK images and converting them to (s)RGB during the process, e.g. here when exporting to JPG: (Embedding the profile is not typically necessary in web context as when an RGB imaged does not contain a profile, sRGB is assumed, so some disk space can be saved when not embedding the profile.) If the receiver views images in color managed environment, you could also export in CMYK format and embed the color profile.
  3. On Windows the operation described by @anon2 can be done by holding down the left and right mouse button down on top of the transform origin and dragging (yes, awkward, but works ok after a little practice)..
  4. Which PageMaker version? Adobe InDesign CS2 to CS6 can open Adobe PageMaker version 6 and 7 files, and versions starting from CS4 can save .INDD files as IDML files, which can be opened in Publisher. But if your files are not complex, and you can still create PDF files from within PageMaker, then the PDF route is probably the most painless.
  5. I forgot to mention a couple of key things that are important and not so obvious (espeociall when working with Photo): 1) The image on a spot color fill is applied must be an image layer (e.g. placed bitmap; if you open, you'll get a pixel layer). 2) The document where you place the image, must be a CMYK document (a spot color fill will be converted to CMYK if you have an RGB document). 3) The image must be grayscale, bitmap or an RGB image where "K only" mode using the button of the Toolbox has been turned on. 4) If you ceate a simulated duotone (below the image at the bottom), the blend effect needs to be Multiply. If you use a curve or level adjustment to control how black is applied, the curve must be applied as a mask to the grayscale version of the image (see below); otherwise the colors will be converted to CMYK). 5) The PDF must be exported using PDF/X-4 method (I am not sure about this but the other methods seem to fail and at least do not work with default settings). 6) I would not trust too much in what is shown on the screen. Duotones are not a safe bet even when properly supported by software but they are much more guesswork here where PMS colors are initially not shown accurately (as they will be shown in sRGB gamut in Affinity apps, and the effect of overprinting black shown in blend mode cannot accurately simulate the effect on paper). But both effects, monotone and simulated duotone, might work well with certain kinds of images.
  6. You're welcome. There are professional tools like pdfToolbox, but that's as pricey as Adobe Acrobat Pro. One possibility is of course open the PDF in Photo (or another Affinity app) and make some basic checks. The file may get incorrectly interpreted but you should be able to see if e.g. spot colors are retained as spot, etc.
  7. Yes, sure, and thanks for those explanations. But I am now more concerned about the color cast part of this problem, and mentioned assignment only because it does not touch the pixels but removes banding (and it seems that along banding, also the color cast). This is an odd thing, which you showed is somehow dependent on use of OpenGL on macOS (or at least on your computer, as other macOS users have noted the color cast when using the latest beta and the release version, which on the other hand you and I have not experienced). I have not been able to find a similar feature on Windows that simply just allows turning off and on the side effect of color cast (even if it does not yet explain it), which worries me a bit as a possible indication about a problem with hardware or display color profile. (My earlier note on recalibration having made the color cast smaller however was wrong on another look; it did make reandering dark tones better but did not affect the color cast, the problem is just not as prominent at the part of the image where I focussed when creating the new screenshot.)
  8. I get pretty much similar reddish color cast when opening the image with Affinity Photo Windows version on my laptop (both release version 1.8.5 and latest beta). Rendering with internal Intel HD Graphics or WARP instead of the dedicated graphics card does not seem to make any difference on Windows. On my deskop with a dedicated graphics card there is no color cast, nor is there on my Surface Pro 7 with Intel Iris Plus Graphics. As calibration did help a bit, this might be a profile problem but as mentioned, the problem only happens in Affinity Photo when opening this kind of a 16-bit linear color space image, and can be fixed by assigning another color profile, or converting to 32 bpc color mode. I extracted the Linear Color Space profile using ImageMagick but as you mentioned, in Affinity apps it is listed only in context of 32-bpc color mode.
  9. I had a second look on this,.and opened the image in Affinity Photo on a desktop computer with a separate display and the image stayed neutral there despite of identical banding. Thereafter I recalibrated my laptop display, and the color cast diminished a bit but there are still slight magenta tones in the places where banding is worst. I cannot figure out why, but as the same image is neutral when it is viewed with other apps, I am not sure if there is anything wrong with the display profile. It seems to operate as expected in any other situation, and the color cast is also removed in Photo if I convert this image to 32-bit and then back to 16-bit. It is removed also if I just assign e.g. ProPhoto RGB profile without a conversion (but the gray gradient gets also more compact then). It would be good to understand why there is color cast on one display but not on another (displays are of course different but the OS and measuring software and device the same). The color cast that I now experience is pretty much identical as in @HANDJOJO's post (showing a screenshot from Photo beta), but I can experience the same both in the release version of Photo (Windows, and the latest Windows beta.
  10. Yes, thanks, I realized that afterwards. I mentioned this because as a regular feature Affinity Photo does highlight the current profile so I failed to understand what was actually going on. The UI should not highlight any of the listed profiles but should show similarly as in Photoshop that Linear color space is the current state of the image (or if that is not an option, then just show "Current" as highlighted and other profiles as non-highlighted options).
  11. Check these files: tactest.afpub tactest_pdfx1a_apub.pdf Part of the problem might be in export format: if you do not export using PDF/X presets, the color intent is not included and you might get wrong readings in the viewer app. Note that when you specify at export time a color profile that conflicts with the document color profile, this causes conversion of all color values so this is not an assignment but a conversion. It is the same thing as when you force in InDesign a different color profile and explicitly choose NOT to preserve color numbers. Affinity apps do not have an option to retain current color values and change target profile at export time (that is, they do not support export time profile assignment; this kind of a change will always result in conversion, and most probably unintended color changes). UPDATE: Here's a screenshot showing color profiles of the placed images: Two of the images (on left) have embedded color profiles that conflict with the document CMYK target: they will be converted at export time and this results in TAC getting closer to the TAC limit of the document CMYK target. The ones without color profiles (on right) will keep their native color values.
  12. Sorry, I seem to be confusing things (here shows that I have not much clue on linear color modes), probably because Affinity shows this screen when I choose "Document > Assign ICC Profile": ...implying as if wsRGB were the current color profile. In Photoshop, this is shown, instead, as follows: But when I assign another profile and then assign wcsRGB (instead of wsRGB that was highlighted), I seem to get exactly the same banding and color cast that was initially shown when I open this TIFF file in Affinity Photo (Windows version). So could it be that the cause of the problem is that Affinity Photo actually assigns wcsRGB color profile on an image using linear color space? (I am not sure if my question even makes any sense...)
  13. The color cast is also removed when changing that wsRGB profile.
  14. Thanks for the explanation. I have a poor understanding of 16- and 32-bpc images so I really do understand what happens here but I noticed that simply reassigning to e.g. ProPhoto RGB removes banding. On the other hand, it causes a kind of moire... Could it be that the assigned wsRGB profile works somehow incorrectly in Affinity apps (as it does not behave similarly in other apps when viewing this image)?
  15. Thanks for the update -- beats me what is going on here but it appears to be some kind of a software glitch.
  16. I have no idea what my Windows laptop display has bits per channel but definitely nothing fancy. But I get this when placed side by side with PS: I tried if it is better in latest Photo beta but it looks just the same there.
  17. Please note that InDesign (at least CS6) by default discards embedded CMYK color profiles for imported images and assigns them the document profile: This means that if you have TAC216 and TAC330 CMYK images placed in InDesign, they will all have their original color values and document color profile assigned no matter whether the images have (conflicting) color profiles embedded, or if they do not contain profile at all: In Affinity Publisher, embedded color profiles are kept, and if they conflict with the document color profile (e.g. here ISONewspPaper and Coated Fogra 39, while the document profile is U.S. Sheetfed Coated), colors will be converted, and so you will see e.g. TAC216 become something like TAC 306 and TAC330 become TAC335 (it seems US Coated allows a bit more ink than Coated Fogra 39). The images with no profiles however will be assigned with the document color profile and so their color values are passed through. InDesign has image-specific color profile assignment routine, which Affinity Publisher does not have so you cannot make in-document changes to avoid unnecessary conversions: In addition, they do not support a policy change according to which CMYK profiles of placed images are discarded, so this means that you should save your source CMYK images without a profile to pass through their native color values.
  18. An interesting and important observation. I think what happens here is that you have a CMYK document with K100 text which you then export to RGB for digital viewing. Affinity apps seem to convert K100 to something like RGB 30 30 30 (dark gray), depending on the underlying CMYK profile, while Adobe apps will produce pure black RGB 0 0 0. It is obvious that dark gray text will look less crisp than pure black. Here are screenshots from regular and retina displays when outputting to digital use PDF from a CMYK document with K100 text: smallprintrendering_rgb_apub.pdf smallprintrendering_rgb_id.pdf
  19. I tried to but it converts to CMYK, similarly as overlay F/X with a spotcolor applied. Tried it with PDF/X-4.
  20. Here is another old test file initially created in Publisher but now loaded in Photo and it works just fine there, too. In this case a PMS ink is applied as a fill on a grayscale image that is separately (destructively) manipulated (levels ajdusted so that the PMS ink will have effect only in certain parts of the image), and then a grayscale copy of the image is overlaid with multiply blend mode and using curves and levels to adjust tones. This stays as a duotone image, while trying to adjust levels of a grayscale image with PMS ink fill will be converted to CMYK.
  21. I loaded an old test file initially created in Publisher in Photo, and it works similarly there. Viewed in Acrobat Pro Output View: So basically what you seem to look after is a monotone where tones of a grayscale image are printed in spotcolor. That would be the bottom right image where you simply just assign a PMS spotcolor as a fill color for a grayscale image (the ducks here is a linked Gray/8 TIFF image). Note that even if you can define a tint of a spotcolor it does not have an effect in the exported PDF so if you need a different tone you need to pick a different spotcolor. The image on top right simulates a duotone but it needs to be output in PDF/X4 to avoid converting to CMYK. Note that tints of the spotcolor work fine in this context. The image on top left overprints a spotcolor rectangle on top of grayscale image and has for obvious reasons little practical use. The image on bottom left shows how an image with spotcolor FX overlay will convert to a CMYK image.
  22. If you want to have non-antialiased selections, you can use e.g. the Freehand Selection tool in Polygonal mode and make sure that "Antialias" is deselected before starting to define the area (it is a toggle so you can define one area antialiased and another added/subtracted area as non-antialiased, or vice-versa). A pixel area created this way will stay non-anti-aliased when you move it as long as you have pixel alignment turned on (note that other snaps might still force alignment to fraction points, which will cause permanent antialiasing of the pixel area). Creating pixel areas with a selection tool is not as convenient as when using the Pen tool, but allows selective use of antialiasing (while also allowing modification of the current selection by redrawing the defining edge). Note that whenever antialiased selections exist, the advise given by @anon2 applies so to avoid antialias ghosting remnants, just deselect before moving.
  23. What they basically mean is that send pure sRGB, but you can send CMYK if you know what you do. Their workflow is basically non-colormanaged (https://kdp.amazon.com/en_US/help/topic/G201953020) : As mentioned above, they strip color profiles. If you have created a CMYK file, it is better to be pure CMYK (e,g, PDF/X-1a:2003, which forces CMYK-only), or "PDF (for press)" without a profile. Mixing color spaces in a non-color managed workflow where color profiles get disarded causes problems shown in this thread. EDIT: Also, if you print on uncoated paper, I'd send sRGB in a situation where a specific CMYK profile for uncoated stock is not given.
  24. In context of what is mentioned above, I think that what has happened with your cover is that you have probably produced the print PDF by using a "PDF (for print)" preset, which does not make conversions to document CMYK target so what it means is that sRGB based front cover with black defined as RGB 0, 0, 0 gets through as it is (just tagged for document CMYK target), and the CMYK based back cover will also get through but but shows dark gray in RGB context. It is difficult to say whether the difference in black would show in printed version, as well, as the CMYK conversion that will eventually be done does not produce a difference that is as radical as appears in the screenshot. But the problem could be avoided either by keeping the whole job (s)RGB based and then creating a "PDF (for print)" print PDF (which would stay pure RGB), or using e.g. PDF/X-a1:2003 export method, which would create a pure CMYK document so that mixed color spaces get resolved and would be handled similarly in print process.
  25. I had a look on this on KDP site, and this is exactly how it is. The whole workflow is purely for non-professional publishing and RGB based and only production tools mentioned are Word and Pages (macOS hobbyist page layout app). This means that the best workflow is to create an RGB document and deliver it by using the "PDF (for print)". The text should be defined as RGB 0, 0, 0 which may be converted in the process as K100, but otherwise the whole workflow is non-color managed. EDIT: What this means for color-managed CMYK-based jobs is that any print target color profile included is simply just ignored. In professional hands the conversion could be done so that a CMYK print job is properly converted to (s)RGB and the kind of anomalies shown in this post do not happen, but as it is, RGB 0, 0, 0 blacks that are tagged for CMYK targets get through and print properly but CMYK converted rich blacks (and possibly K100, as well) become dark gray.
  • 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.