Jump to content
You must now use your email address to sign in [click for more info] ×

panelson3

Members
  • Posts

    40
  • Joined

  • Last visited

Posts posted by panelson3

  1. On 6/27/2020 at 4:07 PM, rpnfan said:
    On 9/8/2020 at 4:26 AM, rpnfan said:

    Serif, are you listening? Do you care? Will we see full colormanagement enabled anytime in the not too far future?

     

    I completely agree: Full color management following the ICC specifications with an easy to understand UI. I don't understand why they are not weighing in on this.

  2. On 4/18/2020 at 5:21 PM, rpnfan said:

    Currently Affinity lacks complete colormanagement / softproof functionality.

    This is a critical need that needs to be addressed. Has anyone from Serif commented on the reason for a lack of solid color management capabilities in their apps and whether they are going to do anything about it?

  3. 13 hours ago, Dazmondo77 said:

    Yes I could always go back to Quark, Indesign, Freehand, Ilustrator to print accurate proofs but I want to use Affinity, I'm sure I've read somewhere on the forum in the past that theres no plans to fix this

    Affinity’s apps seem so capable in many ways. It’s such a let down that printing seems to have these kinds of issues, and you have to kluge together a workaround with Acrobat. It makes me wonder if there is some kind of licensing/expense issue with integrating a CMM and providing a proper in-app ICC color managed workflow - that maybe they don’t want to pay for so that they can keep there prices down.

    12 hours ago, BofG said:

    Overall it's "usable" and is worth the downsides versus paying an Adobe subscription or buying a dedicated RIP. Certainly room for improvement though.

    Yeah, I just downsized my Creative Cloud subscription to just Photoshop and Lightroom, hoping Affinity Designer and Publisher would be good (and inexpensive) replacements.

    I just sent out a book job to the printer that I put together in Publisher. The submission was exported pdf files, so I’m hoping that the color and type look alright. If not, I’m not sure what I’m going to do.

  4. 41 minutes ago, Lagarto said:

    a) Here is an actual conversion done from sRGB color profile to Canon Pro 9000 Mark II Seriers Glossy (üsing Adobe ACE; using Microsoft ICM produces more or less identical conversion):

    Adobe ACE, and Microsoft’s ICM and Apple’s ColorSync, and any other CMM created for ICC Color Managementn is going to have to adhere to the ICC’s specifications for performing a color conversion. It would stand to reason that the results you see are very similar. That being said, if you dug deep enough you might be able to find some differences, but they may be negligible.

    45 minutes ago, Lagarto said:

    b) Here are the out of gamut warnings (shown in gray) between these two profiles if using Absolute Colorimetric and Relative Colorimetric rendeing intents (no difference in color gamut warning, and offering "Black point compensation" as an option in Absolute Colorimetric is also wrong, but it does not matter as it does not have any effect anyway)

    As you know, the color gamut warning is going to indicate the out of gamut colors when comparing the source color space with the destination color space (sRGB to Canon). Because the rendering intent is a method for converting out of gamut color to in gamut color, no matter which rendering intent you choose, you will not see a change in the gamut warning. The gamut warning is simply showing you the colors that are outside the destination color space.

    There are plenty of sources online that provide definitions of rendering intents. I borrowed this from John Paul Caponigro...

    “Perceptual
    A perceptual rendering intent preserves the overall color appearance by changing all colors in the source space to fit the destination space. The perceptual rendering intent is favored for images that contain many out-of-gamut colors.“

    It compresses the colors into the destination color space to best maintain tonal and color relationships.

    “Relative Colorimetric
    A relative calorimetric rendering intent maps the white of the source space to the white of the output. It reproduces in-gamut colors exactly and clips out-of-gamut colors to the nearest reproducible color. The relative calorimetric rendering intent is a good choice for images where more of the colors are in-gamut than out-of-gamut.

    Absolute Colorimetric
    An absolute colorimetric rendering intent differs from relative colorimetric because it doesn’t map the source white to the destination white. It reproduces hues absolutely. If the source is a clean white reproduced on yellow paper the result will be a yellow white. If the source is a cool white reproduced on a warmer paper, cyan ink will be used to simulate the cool white of the source. Th absolute colorimetric rendering intent is intended for cross-rendering simulations of output condition with another.”

    This is best used for proofing.

    “Saturation
    A Saturation rendering intent converts saturated colors in the source space to saturated colors in the destination space. It favors reproducing vibrant colors and will do so at the expense of reproducing hue or luminosity accurately. The saturation rendering intent is useful for reproducing graphics with high color impact.

    Here’s the bottom line. To make the highest quality prints possible, choose either relative colorimetric or perceptual. As results vary from image to image, softproof an image to choose which rendering intent is best for it, before you print it.”

  5. @Lagarto, do you know what color conversion engine (CMM) the Affinity apps use to convert color? Do you think that they rely on the color engine provided by the operating system?

    Also, in the soft proof adjustment layer, why is Absolute Colorimetric the default? I’m assuming this is so you can see the paper white, but that doesn’t help give an accurate color rendering if your output is going to be converted using Perceptual or Relative Colorimetric.

  6. 6 hours ago, Lagarto said:

    No, they use printer color profiles when outputting to the printer, but assume typically the input to be in sRGB (which it is for the majority of customers using these kinds of services meant for general public) and probably strip off any embedded profiles (at least if there is any kind of automated delivery). So they offer their proofing profiles so that the customers can realistically see (in apps like Photoshop and Lightroom) what can be expected when they get their photos printed. So IMO the correct procedure would be to convert colors to sRGB (if that is what the service provider expects and which does not narrow down the target color space) and just see that the colors look right, rather than fiddling with off-gamut colors manually using soft proof adjustments (especially in Affinity apps where this feature does not work appropriately). If colors are not mapped as wished by the conversion, then the image can be manually adjusted within the expected input color space e.g. to bring out specific tones and color areas using manual fine tuning, but just trying to do manual color management and do something that is much better done by a profile conversion is not sensible.

    This is the way that I understand it as well.

  7. 1 hour ago, thomaso said:

    I would expect that I am allowed to "try on" the same amount of profiles as I am allowed to convert to. But "Assign" offers less than "Convert": it only offers profiles in the same space, so in RGB only RGB profiles. Whereas I get full choice when converting. Why?

    Hello @thomaso, Great question!

    If you are opening an untagged RGB file, you don’t know what RGB color space it’s in because no RGB profile was embedded with it, but you know that it’s colors are being represented by the RGB color model. One of the points of Assigning is to try to determine what color gamut your RGB (or CMYK, if the file is in the CMYK color mode) file is in or which color gamut is going to give you the most pleasing results. That’s why you only see RGB profiles for files using the RGB color model, CMYK profiles for files using the CMYK color model, etc. I hope that makes sense.

    1 hour ago, thomaso said:

    So, "Assign" as kind of "try on" forces me to convert from RGB to CMYK to be able to "try on" various CMYK profiles. That's kind of destructive "try on", isn't it?

    So, again, think of Assigning as a way to determine the color space of an untagged file that you have just opened. Once you have figured that out or found a profile that you prefer, you can then Convert to preferred color space. Let’s say it’s an RGB file, but no RGB color profile was embedded with the file. You open it and have no idea what RGB color space your file is in. So you Assign sRGB. The color shifts to something you think is accurate, ie: you like what you see, and assume that the file probably originated as an sRGB, but the sRGB profile was never embedded with it. You are happy with the color, so you now Convert, shifting the color data in the file to sRGB. The RGB file is now in the sRGB color space. Now that you have done this conversion, you wonder what the file would look like if you were going to send it to a print service that only takes CMYK. This is when you soft proof. You set up a soft proof adjustment layer with the printer’s preferred CMYK color profile, and now you can get an idea of what your sRGB color will look like when the printer outputs it on his CMYK press.

    I hope this answers the question.

  8. On 6/17/2020 at 2:22 PM, R C-R said:

    I have never been very clear about the difference between Convert & Assign in Affinity, but I think it is similar to the Assign Profile & Apply Profile choices in Apple's ColorSync Utility, as explained in the Modify image colors in ColorSync Utility on Mac support article:

    The difference between Assigning and Converting is confusing and, yet, pretty straight forward. Typically, you would Assign a profile when you open a file that does not have an embedded ICC profile, and you are unsure of what color space the image originated in. Assigning is like “trying on” a profile because it does not convert the color data in the file, but it will render to the screen the image in the Assigned color space. This gives you the opportunity to try different color profiles to see if you can either identify the unknown color of the image or find a color space that is pleasing. I usually find that the first profiles that I test are working spaces like sRGB or AdobeRGB since they are the most commonly used. If I can’t find what I like, I find a working space that looks the best, and then I Convert the image color to that color space.

    Converting, unlike Assigning, actually changes the data in the file, so this can be a bit dangerous if you aren’t careful. In my photography workflow, I put all of the color data that comes off of my camera (in a raw file) into the largest color working space I can, ProPhotoRGB. This way I am retaining as much of the color that the camera captured as I can. I edit the photo in ProPhotoRGB. When I am done editing and ready for output, I’ll convert the data depending on the output destination. If I am going to deliver the file to a printer service, I will convert down to the color space that they require. It is most often AdobeRGB. If it’s a book, I will convert to the CMYK color space that they require, like a generic US Web Coated (SWOP) or something like that. Often, CMYK printers will have a specific custom space that they want you to convert to, like blurb’s custom color space that is some kind of derivative of US Sheetfed. If I am sending my image to the web, I always convert to sRGB.

    In my case, the color workflow is always one of managing the color conversion from capture device, my camera which captures a lot of color, down to a working space so that I can work on it, to an output space. The output gamut is almost always smaller than my working space. So the color workflow is really a process of controlling how much color you are throwing away as you move through it. Once you have thrown the color away (and save the file) you can’t get it back. If you take a file that is in a large color gamut like ProPhotoRGB and convert it down to sRGB which is a much smaller color gamut, everything that was outside sRGB is converted down to sRGB. If you then convert back to ProPhoto, you will not get the colors back that were originally in ProPhoto. You will simply have the sRGB color inside the ProPhotoRGB color gamut.

  9. 2 minutes ago, Lagarto said:

    Yes, that's what I did (or at least assumed to have done), and which I assumed that the screenshots also showed?

    This discussion has gotten off track. My original post asked if anyone understood why Affinity does not provide a way to convert output color prior to printing. I don't want to convert my images using ColorSync on a Mac in the print driver. If Affinity is going to be competitive, they are going to have to compete on capability and not just price. Printer color conversion is extremely fundamental. How is Publisher going to compete with InDesign if it can't print accurate color or facilitate a hard proof? I'm planning on using Designer to do client proposals. If it can't print accurate color, it's close to worthless.

  10. 13 minutes ago, Lagarto said:

    It is in the screenshot: "Performed by Printer" (in contrast to "app"). 

    So if the conversion can happen in the app or in the printer driver, you need to tell both the app and the driver which you prefer. If the app is performing the conversion, you have to make sure to turn it off in the driver. If the app is not performing the conversion, then you have to set up the driver to handle it. You never want to have both the driver and the app perform a conversion. It's either one or the other.

  11. 41 minutes ago, Lagarto said:

    There are clearly issues with local printing within Affinity apps but the reasons for the oddly bad results that you have demonstrated in this post when printing using Adobe RGB workflow on an sRGB printer seem to be ones related to trying to pass through unconverted color data. Perhaps this is device-dependent as I did not experience similar problems printing virtually the same image.

    Whereever the color conversion is performed, on Windows versions of Affinity apps there is no need to explicity convert the colors to sRGB, so similarly as when using Photohop, I can print from a document that uses the Adobe RGB color profile, choose the rendering intent of my choice while having printer controlled color management turned off, choose a target device specific media profile from the app rather than from the printer driver, and get acceptable (even if not great) results.

    There is no such thing as an sRGB printer, and I never mentioned using sRGB for printing. So, I am confused by your post.

    sRGB is a common color space originally developed to present accurate color in a web browser. For color consistency and ease of use, sRGB has been adopted by many hardware manufacturers and software developers. It happens to have a rather small color gamut, so for printing there are better options with larger color gamuts. That's why AdobeRGB is commonly used as a working space for graphics being sent to a commercial printer.

    The process that you describe for Photoshop is exactly what I've been writing about all along. I want the same capabilities in Affinity software.

    Working Color Space (AdobeRGB) converted by Affinity to the Device Color Space (Epson P800 on Hahnemuhle Photo Rag), sent out to the printer driver which is set to No Color Management (so that the color that has already been converted passes through and is not converted again by the driver), and then sent to the printer. I have been doing this for years with very predictable results.

  12. 7 minutes ago, Lagarto said:

    I really do not know what happens under the hood, but why use this terminology (which is pretty much equivalent to one used in Photoshop):

    Icms_by_app.jpg.92500698711fb9bd76c5041aa79686d8.jpg

    This is equivalent to saying that the app has already performed the color conversion and not to perform the conversion again. In this case, the word "App" could mean any app that is sending a print job to the printer. It's not specific to Affinity. It's the same with the second image you posted, which basically says don't convert the print job that I just received. In the world of Epson and most major printers for that matter, there exists the option to turn off color management in the driver. If the "App" has already translated it, you want the translated color to pass through the driver and on to the printer without any additional color conversion.

  13. 7 minutes ago, Lagarto said:

    So I used Affinity Photo app color management in the Print Dialog box (only available in Windows versions)

    The color management is not coming from Affinity Photo. It is provided by the operating system and written into the driver by the print driver's developer. In Adobe parlance, this would be equivalent to a setting of "Printer Manages Color" vs "Application Manages Color". The CMS is provided by Windows and is translating the color after you printed from Affinity Photo. In my case, I want Affinity Photo to translate the color ("Application Manages Color") when I initiate the print job. This would provide a consistent way to color manage for output to any printer on whatever OS that Affinity supports, rather than depending on the printer manufacturer to write the color management capabilities into their driver which would be inconsistent from one printer to the next (Epson vs HP vs Canon, etc).

  14. I just thought I would post my rationale behind using the Soft Proof Adjustment Layer as a potential way to solve the color managed printing problem.

    If I have an image in a layer in A Photo and place a Curves adjustment layer above it and make some adjustments to the curve, not only will I see those adjustments in A Photo on my computer display, I should also see the results of the curve adjustment on printed output (the color may not be accurate, but I should still be able to see the results of the adjustment, ie: brighter, darker, more contrast, whatever). This should hold true of any adjustment layer that I place above my image layer in the layer stack.

    If I place a Soft Proof adjustment layer above my image layer and assign my printer profile, rendering intent, and black point compensation, then what I see on my color profiled display should be an accurate representation of what my printer will reproduce. Essentially, I'm taking my image layer, let's say it's currently in the AdobeRGB working space, and I'm having the soft proof adjustment layer translate the AdobeRGB to the printer's color space using the ICC profile defined in the adjustment layer. The adjusted color is then sent to the display by way of the display's ICC profile to render the simulated color of the print job.

    So, if I can send the soft proof to the screen, why can I not leave the soft proof adjustment layer on and send the printer translated color to the printer and achieve an accurate color print? Would this not be the same as manually converting the working space color to the printer color (using: Document > Convert Format / ICC Profile...) and printing (no color management conversion in the printer driver, since the color has already been converted)?

    Because of the lousy results, there's clearly a hole in my thinking or Affinity is doing something with the color translation that I don't understand.

    Screen Shot 2020-06-16 at 2.10.05 PM.png

  15. 13 hours ago, R C-R said:

    So just to confirm, you do not see a "Color Matching" choice for your printer & for that a choice between ColorSync & printer matching?

    Also, for your tests with an AP Soft Proof adjustment, the idea is to turn that on & use it as a guide to adjust the colors (via curves or whatever adjustments) so the image looks as close to what you want the print to like like as possible, & then to turn it off for the final export. Otherwise, there is no point in using soft proofing.

    You understand that, right?

    @R C-R, Yes, I have the "Color Matching" menu item in my printer dialog, and I see both "ColorSync" and "Epson Color Controls". The reason that I said that ColorSync is my only option is because it works within the ICC color management workflow where the Epson controls do not.

    Yes, I understand that the SP adjustment layer is for soft proofing so that I can simulate on screen what is going to come out of my printer. However, I respectfully disagree that one has to make adjustments when soft proofing to make it worth doing. I've used soft proofing to decide which rendering intent to use. I've had other occasions when I've looked at a soft proof, thought the color looked fine, and sent it to the printer without making any adjustments. If I decide I need to make adjustments, it is usually because I am printing to a printer/paper that has a color gamut much smaller than my working space, like AdobeRGB to US Web Coated (SWOP) or some variant of CMYK.

    I recently saw a YouTube video that showed how to use the gamut warning in the sp adjustment layer along with some Curve and HSL adjustments to bring the out of gamut colors into the printer's color space. While this exercise gives the user the control for how the out-of-gamut colors are brought into the printer's color space, one could also just let the color management conversion handle it. Since the printer is not going to print out-of-gamut colors because it can't, the original color is going to be reproduced by the printer as accurately as it can depending on the quality of the ICC printer profile and the rendering intent that is chosen. I don't want to have to make adjustments to my image so that I can get it close to what the printer can reproduce. That's the function of an ICC color managed workflow - let color management make the color translations so that I don't have to. That said, there's nothing wrong with making adjustments while viewing a soft proof to really fine tune the color for output, but that is not the sole purpose of soft proofing.

  16. 1 hour ago, BofG said:

    @panelson3 I'm surprised how far out the colorsync output is. Did you create the profile yourself or is it a default one?

    I can hit colours accurately now printing from Affinity Designer, using "printer manages colour", an sRGB document and Windows colour management to apply the ICC profile. It's a pain to use that way, but the colours are at least correct.

    @BofG Yes, I create my own profiles. The particular one that I was using for this test, I have used on numerous jobs when printing from Photoshop and able to obtain very accurate results. So, I know that my profile is not causing the color shift. Being a Mac user, my only choice at the moment when using Affinity apps is ColorSync. I have never set up a print job that relies on the OS or printer to manage color. Adobe has this nailed down to the point that I haven't thought about it for years. It's just been an accepted part of my workflow. I've said this numerous times in this forum. I can't believe that Affinity/Serif would leave out such a fundamental component of the graphics workflow. Do they think that every designer sends their work outside to be printed? What about doing hard proofs for a layout in Publisher? Have they just left that feature out? How could they possibly compete with InDesign?

    I think that I mentioned that I have emailed Affinity/Serif. I can't wait to hear what they say if they respond.

  17. On 6/13/2020 at 8:06 PM, thomaso said:

    This are quite the same options I can get when printing from Acrobat to my Epson, as shown in this screenshots, or when printing from Affinity to a "General PostScript Printer", as shown in that screenshots.

    So I still wonder, if ...
    1. Affinity offers the menu "Color Matching" for the virtual printer, and
    2. Acrobat offers "Color Matching" for my physical Epson,
    ... what prevents the menu "Color Matching" from appearing when printing from Affinity to the Epson?

    Affinity is not providing Color Matching for the virtual printer. The Color Matching feature is written into the driver by whoever developed the virtual printer. It has nothing to do with Affinity.

    Acrobat's Color Matching is provided by Adobe and is written into the Acrobat application. This is in essence what we want Affinity to do, to provide the ability to set up the color conversion before sending the print job to the printer. If they had this ability, it would make no difference which printer you use as long as the print manufacturer gives you the ability to turn off color management in their driver when you print to their printer.

  18. I ran a couple of print tests yesterday to see if an unhidden Soft Proof Adjustment Layer might be able to produce a print with accurate color.

    For this test, I created an X-Rite 24 patch color checker document in A Design in Lab mode using the Lab values provided by X-Rite for each color patch. I then exported the file as a 16-bit AdobeRGB bitmap that I opened in A Photo. In A Photo I created a Soft Proof Adjustment Layer and assigned my custom ICC Profile for my Epson SC P800 and Hahnemuhle Photo Rag, a Relative Colorimetric rendering intent, and turned on Black Point Compensation. (I've used my custom ICC profile many times when printing from Photoshop, so I know that it produces accurate color.) 

    For the first print that I created, I made sure that the Soft Proof Adjustment Layer was visible (as expected, the effects of the soft proof were apparent on the image on screen). When I executed the print, I made sure to turn off Color Management in the print dialog box. So, essentially, I was sending a color adjusted image (because of the adjustment layer) in the AdobeRGB color space directly to the printer hoping that the adjustment layer would provide an accurate conversion for the printer to make an accurate color print - kind of a long shot.

    The color in the resulting print was not accurate at all. To make a comparison, I decided to hide the Soft Proof Adjustment Layer and send the AdobeRGB image to the print driver and let ColorSync perform the conversion in the driver. Under Color Matching, I selecting ColorSync and selected my custom output profile. There are no options for selecting a rendering intent or black point compensation. My expectation was that this resulting print would be more accurate than my first print. The ColorSync rendition was much closer to the original, but not great.

    Below are the results of this experiment, comparing my printed output to a couple of X-Rite ColorCheckers. It is pretty clear how inaccurate the print color is, even when using ColorSync.

    I have sent an email to Affinity/Serif asking why they do not provide support for color management when printing. I will let you know when/if they reply.

    IMG_0485.jpeg

    IMG_0484.jpeg

    IMG_0483.jpeg

    IMG_0482.jpeg

  19. 9 minutes ago, thomaso said:

    Regardless how Adobe is solving it, I think Affinity should be able, too, to offer to the user access to color settings for print jobs according to the drivers capabilities, as it does for hardware related options

    Agreed! I'm solely interested in knowing that I can set up a reliable color managed workflow and wish that Affinity had a similar methodology as Adobe for setting color output. That said, I've enjoyed the discussion with you guys, directly related to the topic or not. I'll let you know when I print some tests using the soft proof adjustment layer.

  20. 11 minutes ago, R C-R said:

    Note that there is no direct equivalent for the Microsoft flags the Windows OS uses to control color conversion. 

    But is there not a "flag" or some kind of parameter that apps under the Mac OS that can send to the driver to let them know whether the app has handled the conversion or not, basically telling the driver whether it should turn off its color management and not perform a conversion - similar, but different?

×
×
  • Create New...

Important Information

Terms of Use | 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.