Jump to content

Lagarto

Members
  • Content Count

    2,377
  • Joined

  • Last visited

Everything posted by Lagarto

  1. 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.
  2. 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.)
  3. 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.
  4. 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, 1.8.5.703) and the latest Windows beta.
  5. 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).
  6. 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.
  7. 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...)
  8. The color cast is also removed when changing that wsRGB profile.
  9. 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)?
  10. Thanks for the update -- beats me what is going on here but it appears to be some kind of a software glitch.
  11. 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.
  12. 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.
  13. 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
  14. I tried to but it converts to CMYK, similarly as overlay F/X with a spotcolor applied. Tried it with PDF/X-4.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. It is "Passthrough" in English UI. Meaning that it will show the transparent parts of the pasted vector graphic.
  22. It will include the target (CMYK in this case, e.g. Coated Fogra 39) in the exported file. But this is useful only if the document has something to be converted and tagged for conversion. "PDF (for press)" however will convert everything to target CMYK (=DeviceCMYK) so the profile is not needed. It only just causes confusion. If you instead export using PDF/X-based methods, they use standards where profile handling works as expected, so they will always include the output intent profile and embed source and target profiles as needed. The plain vanilla "PDF (for press)" profile is a mixed bag that may cause automated preflight routines to reject the PDF as invalid format so therefore PDF/X-based routines are a better choice. It just includes the fonts that you have used in the document in the PDF so that it is not necessary to convert text to curves or deliver fonts with the PDF. The receiver of the file does not need to have the fonts you have used installed on their system as when the job is printed, the fonts embedded in the PDF will be used. This is a regular practice so virtually all font licenses allow this usage. UPDATE: I checked the Panda .joboptions: it is a pretty standard profile, so just use the default "PDF (for press)" and untick the "Embed ICC profile" option.That will make an export file equivalent to this: Yes, that is also a kind of a standard, so e.g. in InDesign by default K100 (object assigned with the default [Black] color swatch) will overprint (but its tints will not, so e.g. 99% black will knock out). Publisher does the same whenever this export option is checked.
  23. I could create without any problems a PDF/X-based exports so the problems might somehow be related to the linkded files (which I naturally did not have so they were ignored at export time). Try if replacing the linked files (with the originals) fixes the problem
  24. I think that the error is related to embedding an ICC profile in a print job that is pure-CMYK and accordingly a device-CMYK job (this is in error in Affinity apps; additionally, embedding a profile seems to disable overprinting instructions even when applied directly on a color swatch). Such jobs should not have an ICC profile included. If you use e.g. PDF/X-based exports, or uncheck "Integra profili", you should be able to get your print PDF through.
  25. K100 black text is overprinted by default in all CMYK PDF export methods in Publisher, but it seems there is a bug which causes overprint setting to be ignored (even if it is directly applied on swatch and not just specified as an export setting) if you embed a profile and use the default "PDF (press ready)" preset, so I'd recommend not using that but e.g. PDF/X-1a:2003. EDIT: On a second look, and when rendering the file e.g. in Photoshop, it seems that overprint attribute works ok also in a "PDF (press ready)" export with an embedded profile, it is just that overprinting fails to be shown in the Output Preview of Adobe Acrobat Pro when a color profile is embedded in a file where it is not needed and where a color profile needs to be picked manually to get correct color readings. But if you do want to base your export on "PDF (press ready)", then make sure that you do NOT embed the profile: To check overprinting, you'd unfortunately need prepress features like ones in Adobe Acrobat Pro: Here the mere C plate is previewed and it can be seen that there is no masking (knockout) for black ink (but there is for yellow ink): Verdana has regular embeddding rights in the license so you do not need to convert it to curves but can keep it as a font. Embedding a font is not same as distributing a font, but even that would be permitted use in purpose of getting a job printed.
×
×
  • 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.