Jump to content

Roger Simon

Members
  • Content count

    12
  • Joined

  • Last visited

Everything posted by Roger Simon

  1. @owenr Again, you’re correct. I simply had opened both preview images in ColorSync-Utility and within this app, both have sRGB assigned. But obviously, this assignment is made by ColorSync-Util itself. (lesson learned: always use PS). @owenr, @R C-R, Can verify, that AP either *assignes* or *converts* unprofiled jpgs to a) the set RGB color profile or b) sRGB, based on what the user sets in the application’s preferences. With unprofiled png however, AP *always assigns* the RGB Colour Profile set in Preferences, no matter if „Convert” is checked or not. (At least, that’s the behaviour I’m experiencing here on OSX 10.11.6). These behaviours -in my eyes- are unwanted, as the user has no chance to intervene. (And I haven’t checked the behaviour for unprofiled tifs…) Say, a jpeg file originates in AdobeRGB but does not have an embedded profile. If AP is set to sRGB (or conversion is turned off), the file would open with wrong colours, as sRGB would be assumed as the source colour space. If AP is set to convert, then the application would do this error possibly twice: first, it would wrongly assume sRGB as colour space and then would do a conversion to i.e. AdobeRGB or ProPhotoRGB based on these wrong colours. Profile Warnings btw now seem to me pretty random. During my tests, I was experiencing all sorts of combinations with/without warnings either on jpg or png. (But probably AP just does not like when preferences are switched that often, even if the application is closed in between). @ Jose A: Hardware calibration: the measured color values from the colorimeter are written into the LUT of the monitor. On OSX, you can switch between different hardware calibrated profiles either by the buttons on the monitor or via OSX System Preferences. I do not know, how this is exactly handled on Windows though. Software calibration: An icc profile is generated and used on System Level to overwrite the GPU’s color rendering. Depending on the monitor used and its capabilities (i.e. whitepoint setting, R-G-B sliders available or not), this leads to more or less good, but always reduced colour rendition (due to whitepoint setting). It’s the only way available on most displays. As far as I understood, your monitor is actually used with the default factory profiles. This cannot be seen as hardware calibrated, as long as these profiles aren’t verified with a colorimeter. At least during the next 2-3 months, colours will have changed. >>> Your issue with sRGB: I’m wondering if this is probably an actual limitation of the Windows version of AP? On OSX, it’s possible to choose any installed icc profile as the document’s colour space right from the beginning. I’m actually asking myself, if your way can result in correct colours as you are switching from a smaller to a wider colour space. If colours would already be present in the file, these colours would be desaturated that way. But I have to admit that I don’t know what actually happens to an empty file. >>> ProPhotoRGB Adobe choses that Colour Space as it is wide enough to contain every colour that a camera can produce and will ever produce in the future. This is the reason, why they left their own AdobeRGB. Working right from the beginning in ProPhoto is a good way, but one has to be aware that one most likely needs to reduce to a smaller Gamut on export, depending on the output target. If you convert a sRGB file into ProPhotoRGB, you can do more destructive work on that file. It’s similar as converting from 8-bit into 32-bit. You don’t get more information into the file, you can just destruct it more. >>> Rendering intents are especially important when converting from RGB to CMYK for print.
  2. Hello LudoE, this is something that I also had observed. Had done several compositings which ended up in AP at a file size of nearly 7,2 GB each. Out of interest, I had these redone in PS, where they ended up just at about half the size (3.48 GB). If you add a full pixel layer to a file, this usually doubles the file size. This is to expect. Adjustment layers or masks don't add that much to a file though. The Affinity file format does seem to be very wasteful. Using TIFF should keep at least the pixel layers, but everything else would be erased from the file, so effectively there is no solution except hoping for the development team to optimize the Affinity file format quite a bit.
  3. Hello Jose A, (sorry for my late reply) >> monitor Assuming, that color management on Windows is somewhat similar to OSX/macOS, using a hardware calibrated monitor should work as follows: If you calibrate the monitor with a colorimeter, this will be done right on the monitor itself, thus hardware calibration, a profile will be created and set as the default monitor profile in System Preferences (=OS level). In your case, as you haven’t done this calibration so far, there should be at least a default monitor profile that should have been installed by your monitor’s calibration software. (I’m assuming, that Benq is doing this the same way as EIZO or x-rite i.e.). Whenever you re-calibrate your monitor, this profile will then be „updated” with your newest colorimeter readings. If you calibrate for different targets, you will create new additional profiles or you will update pre-installed target profiles from the monitor’s calibration software. >> AP RGB Color Profile in AP Preferences: This will represent your main working RGB color space. Whenever you load an untagged image file, this profile will be assigned to that image. (This is a potentional source for false colours, as long as AP is not asking the user about what he/she wants to do. On my Mac, I’m never asked, no matter what I set in Preferences, AP just assigns the RGB Colour Profile and just shows a tiny window for a about one second to inform me about this assignment). If you open a tagged/profiled image in AP, this profile will be read and respected. If you are working in colour aware environment, embedding and using files with embedded profiles is key. So, if for whatever reason, AP sets its default RGB Colour Profile to sRGB, this should not influence your work, as long as you have files with profiles embedded. If you haven’t embedded profiles, sRGB will be automatically assigned. >> AdobeRGB, ProPhotoRGB, softproofing, web display working in ProPhoto does give you the maximum possible quality, as you never have to fear that the set Colour Space will clip away some of your image’s colours. For exporting, you will nevertheless mostly bring your images down to a smaller Colour Space. For print, you should be able to stay with ProPhoto or reduce to AdobeRGB. If the web is the output target, sRGB is the most secure way (eventhough the colour space is smaller) for getting comparable results. Of course, correct profiles need to be embedded with the files. Colour management in web browsers is a different topic though. >> rendering intent You’ll need to think about that whenever you reduce from a larger to a smaller Colour Space in conjunction with the output target. Gamut Mapping transforms from source to L*a*b* and then to target space. The appropriate rendering intent is needed to correctly map the colours that are outside of the target’s colour space to appropriate values depending on the output media. >> color picker This is something that I also do not understand. I think it is meant as a simplification for the user, but I do prefer the color picker in PS, which can be set to represent both 16-bit and 32-bit colour values. >> Monitor If the monitor is properly calibrated, images will be displayed according to their embedded profile (in colour aware applications). Whenever you notice these extremely saturated colours, it is very likely that the application is not colour-aware or i.e. is unable to read the embedded colour profile. The latter could be the case if i.e. an ICC v.4 profile is embedded, but the application is only able to read v.2 profiles. Btw, you did install/update the monitor’s driver to the Benq driver in Windows? >> „exp 1&2” While generating the smaller preview images for uploaded pictures, these are converted to and profiled as sRGB. That’s the reason, why both images look exactly the same even in a completely color-aware browser like Safari. The original image files do display differently and they have AdobeRGB (2) and sRGB (1) embedded. Differences can only be seen in color aware applications, such as PS, LR, AP, CaptureOne Pro etc. Web-Browser compatibility could be checked here (if you haven’t already done): http://www.color.org/version4html.xalter >> Profile conversion Just a reminder: there is actually no sense in converting an image from a smaller Gamut into a larger one (sRGB/AdobeRGB > ProPhotoRGB), as the colours of this image are already reduced. A larger Gamut does not „add” more colours. The different pixel values should originate in rounding errors and different rendering intents. (Rendering intents are not standardized, meaning that each company can do the math in slightly different ways).
  4. Hello Jose A, from re-reading your posts above, I try to recap your settings: -You have Windows set to AdobeRGB on OS level. (Wouldn’t you need to set your calibrated monitor’s profile here? This is the way it works on OSX/MacOS. The calibration software should offer this profile to the OS). -You develop in LR (using ProPhotoRGB) and then open up in AP (RGB Colour Profile set to ProPhotoRGB in Applicaton’s Prefs). From your screenshots, it seems that LR is embedding ProPhotoRGB into the exported images and AP reads that profile. (You would notice a different Profile in the document window, if i.e. AdobeRGB or sRGB would be embedded, as AP would then read one of these profiles instead appliying ProPhotoRGB). [I was wondering why you would need to download the ProPhoto profile, but this might be down to differences in Windows and OSX/MacOS colour management]. Just as an assumption: if LR would export without embedded profile, AP would automatically assign ProPhotoRGB, even if you had worked in a different colour space in LR. That would lead to false colours. ProPhotoRGB has theoretical advantages as a working colour space as it is simply extremely wide and data will never be clipped by this colour space. (In practice, you are down to AdobeRGB, just because this is about the maximum that you will ever see onscreen. A further limitation would be the colour space available i.e. within the colour settings of your camera. Most are limited to sRGB, higher quality cameras support AdobeRGB, some work with true 16-bit colour depth. But no camera is able to fully use ProPhotoRGB, and no monitor is able to represent that colour space). This is generally correct, it reflects the actual embedded colour profile of the opened file. [except: untagged file issue] (If you open an image with embedded sRGB profile, sRGB will be shown regardless of your Preference settings). Your idea with the different colour conversions is also correct, so I’m assuming that you already have verified, that your Export settings in LR match your colour settings in AP (i.e. Rendering Intent). As long as no Affinity developer joins this thread, I would advise you to send in a bug report on that issue, so that you most likely will get help directly from the development team.
  5. Hello Jose A, unfortunately, I’m no expert regarding colour management on Windows. From what you are describing and from the look of your screenshots however, it seems to me that AP might be rendering the image onscreen in sRGB, while it might render correctly in LR. Afaik, Windows has sRGB deeply integrated into the OS, so the solution could lie in the colour settings on the OS level. AP probably uses this information while LR has its own solution. If your monitor is calibrated, you need to make sure, that Windows uses this profile for onscreen display. (My only experience here was during Windows Vista, which was a true nightmare regarding colour management on OS level and very hard to understand for someone that worked on MacOS ever since). Did you verify that your file has a colour space tagged to it? Because AP automatically applies the RGB colour profile from the App’s Preferences to untagged files without enquiry. Sorry for being no big help here, but hopefully there is at least some information that gives you some input to continue to get closer to a solution.
  6. Hello Simon R, just meant that COP is by default set to use the Profile chosen in the actual Processing Recipe. I'm also using ProPhoto as editing working space, but have my Processing Recipes usually set to export with AdobeRGB (some even to sRGB). ProPhoto has theoretical advantages, but practically there is simply no monitor or camera system capable to use this colour space. Did I understand your PhaseOne support ticket correctly in that your issue is resolved by simply zooming in to 100%? Then, I was obviously just lucky by having a larger screen. Thank you for posting the solution, useful information! cheers, Roger
  7. Hello Simon R, Hello Chris_K, to probably add a little more confusion, I tried to replicate this issue here. I followed all the steps, Simon R is describing and set both applications to the same (his) preferences. Used a Nikon NEF shot in AdobeRGB colour space. As a result, I can not replicate this issue: Affinity Photo does come up with the same colors as seen in Capture One 10. This is on OSX 10.11.6, COP 10.1.2.26 (5ee1101), AP 1.5.2, hardware calibrated monitor (Eizo). The RGB Colour Profile set in AP Preferences does not seem to influence the appearance of the image, as the file is tagged in COP with ProPhoto.icc. This profile is then read by AP. (AP automatically assigns the RGB-profile from the AP-Prefs to untagged files, what can be an issue, but not in this situation here, with an embedded profile). Also, when COP is set to the default state for Proof („chosen processing preset” [sorry, German COP here], everything works as it should. Sending a file with different profiles (AdobeRGB, sRGB) also results in the same colours and pipette readings. Btw, sending to Photoshop also works as it should. One thing to note: the tif (variant) in COP read slightliy lighter then the NEF, but comparing the NEF in COP with AP or PS, both show effectively equal values. @ Simon R It might be worth checking the monitor profile set in OSX Prefs and the build nr. of Capture One Pro (probably missed an update?). Sorry for this being no solution to the problem, but at least it might indicate, that the cause of your issue might come from somewhere in your setup.
  8. Roger Simon

    RGB colour management anomalies

    Hello owenr, again, you're right: as I could verify a similar issue that I have within a 3D DCC app by simply opening the screenshots via QuickLook or Preview.app, I just used those while checking this issue here with Affinity Photo. Now, in PS the differences are there. I'm attaching a screen grab which contains my Monitor's Profile and therefore the maximum discrepancy between Image Display Area and Navigator panel, that I experience here. As one can see, all colors are way off, only the greyscale patterns are close to each other.
  9. Roger Simon

    RGB colour management anomalies

    (15 hrs later, system is up and running…) Hello owenr, can verify your issue, had downloaded your files. Though the differences on your system are pretty small, they are certainly disturbing. My monitor shows 100% of sRGB and nearly 99% of AdobeRGB, therefore the differences are much more evident here. Nevertheless, screen grabs don't show that, neither when taken via Screen Grap App nor by keyboard shortcuts. Both variations result in visually pretty close colors, no matter if sRGB or the Monitor Profile is added. OSX Digital Color Meter gives me onscreen the following native values (only for the 1st row, left=image display, right=Navigator panel), when I choose my Monitor's profile as Working RGB to maximise this issue: 255 0 0 >>> 215 61 35 0 255 0 >>> 150 244 65 0 0 255 >>> 42 66 247 255 255 255 >>> 255 255 255 On the image display area, 255-0-0 i.e. is pushed to the maximum red value of my monitor's Gamut, what is to expect. Navigator panel on the other side shows just a somewhat maximum sRGB red instead.
  10. Roger Simon

    RGB colour management anomalies

    Hello owenr, thank you for clearing up this issue with the screen grabs. Indeed, I used the grab tool for a screen grab to show off the differences between the file representation within the image area and the Navigator panel, which unfortunately resulted in equal Color in the screen grab. (Would instantly repeat this process with your solution, but out of the blue my Mac came up with a System error this morning and I'm actually trying to get the system up and running for hours now without success so far and the iPad doesn't help much in that regard). Anyway, Affinity Photo -imo- does 2 things wrong: - it automatically assigns the Working- RGB to an untagged Image file during opening and - it shows off 2 different representations of this file: with Working-RGB in the file Display area and obviosly converted to sRGB in the Navigator panel A color aware app shouldn't automatically assign profiles to files, it should at least warn the User and prompt for an appropriate action. Of course it should also show the file consistently and reliably within the app. (Excuse me when I withdraw from this thread now, writing on an iPad is just too time consuming (esp. on non-US eng devices) and I need to continue trying to fix my Mac :-| Hopefully I can re-join later)
  11. Roger Simon

    RGB colour management anomalies

    Hello owenr, Hello James Ritson, this seems an issue, that I also experienced in pro-3D apps using OCIO on Mac. It is only visible on Wide-Gamut Displays that are capable to display color spaces larger than sRGB. And it most likely has to do with the different color managements on the OS level. On Windows, an untagged image i.e. will automatically be treated as sRGB image, whereas on macOS an untagged image will be translated into the display's gamut. In example, maximum red in an untagged image on Windows will be translated into sRGB 255,0,0 and displayed as such (even on Wide Gamut displays). On a Mac with Wide Gamut display, this red will be translated into 255,0,0 of the monitor's gamut, resulting in an extremely saturated red. Actually, this seems a more correct solution, as color values only make sense in correlation with a definition of an appropriate color space. Attached is an untagged (unprofiled) png file, which can be used to verify this issue when examined on a Wide Gamut display, such as a professional color station display or a hardware calibrated proof monitor and with AF set to a larger than sRGB color space (i.e. Adobe RGB, ProPhoto RGB, eci-RGB or the actual Monitor profile). On opening, AF will automatically assign the RGB working space set in Preferences (which is not so good btw). The colors will be transferred into this gamut which will result in Affinity Photo to display colors with a more or less huge color shift (esp. in the red, green and cyan fields) between the actual document's display and i.e. the display within the Navigator panel. The larger the Working RGB the larger the difference will be. The document's display area obviously transfers this file into the Working RGB. Navigator seems to display as sRGB file. Unfortunately, a screenshot will not display the different appearances in Affinity Photo, as OSX screenshot app does apply sRGB which equalizes any differences. (This insufficient color management within AF let me actually revert to PS).
  12. Roger Simon

    PDF export: page size calculation seems faulty

    just ran into the exact same issue, except for that I don't get one single page with the desired correct size of 210 x 276 mm. Even a single blank page at x=0; y=0 exports as 210,1 x 276,1 mm (therefore refused by the print supplier), multiple pages even export with different sizes: mostly 210,1 mm wide, but some export as 210,2 mm wide (height remains constantly wrong at 276,1 mm). This remains the same, no matter if - pages are simply set up and just duplicated via the ArtBoard-tool (without altering their initial locations) - pages are manually distributed - pages are manually distributed to locations with "clean" integer x/y coordinates. When searching for a workaround, I found, that no document seems to export with correct measurements, even a default blank DinA4 page exports with 21,01 cm x 29,71 cm / 210,1 mm x 297,1 mm… Unfortunately this renders the pdf-export effectively useless and should be fixed asap. (AD 1.5.5 - OSX 10.11.6) [edit]: hopefully, this isn't an issue that originates in Apple's Quartz PDF Exporter: I just received a multi page DinA4 Document, which was created within Safari under 10.12.6 via Quartz PDFContext and this also comes as 210,1 x 279,1 mm.
×