Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

VolkerMB

Members
  • Posts

    206
  • Joined

  • Last visited

Profile Information

  • Location
    Hamburg, Germany

Recent Profile Visitors

1,778 profile views
  1. I made a simple test without using any photo. I just created a new document in sRGB color space in APhoto 2 and draw some rectangles on it. One in orange, one in green and one in purple. It renders completely different on both displays. Then I switched the Eizo internally to sRGB (and changed the Windows color management for the Eizo to sRGB as well) and compared both displays. Now, they are in line (almost). Which, again, leaves me to believe that something is broken here.
  2. @debraspicher Sorry for the somewhat snarky comment at night time. Apparently I didn't explain the situation well enough. So, here is my second attempt: My computer runs Windows 10 (22H2) and features a AMD Radeon RX5700XT graphics adapter. Windows own color management is configured to use a bespoke AdobeRGB color profile for my first display (EIZO) and a standard sRGB profile for my second dsiplay (DELL). The profile has been created by me using Eizo's ColorNavigator7 and the X-Rite i1 Display pro colorimeter. The color space target was AdobeRGB. The Eizo display itself is set to AdobeRGB while there is no such setting for the Dell display (it is not capable of displaying anything beyond sRGB). I am aware the the Windows UI and plenty of apps are not color managed at all. But: Lightroom, DXO Photolab and the Affinity apps are color managed. Let us focus on them - and how colors are actually rendered in these apps on my systems. One example: Affinity Photo 2 is set to AdobeRGB as the standard color space. So any new document using the standard color space will show quite powerful colors on the Eizo display and "muted" colors on the Dell display. That is expected. However: If I create a new document within the sRGB color space in Affinity, I only expect a mild difference in rendering the image on both displays. As sRGB is the much smaller color space, the color managed Eizo should be able to reproduce the colors propperly. But that is not the case. They remain unnaturally bright and powerful as if they were still in AdobeRGB. I took a laptop of mine with a sRGB display and hold it next to the Dell display. The result: very minor differences in color rendering. So, I guess the Dell renders the sRGB colors decently. With the Eizo it is a different story - no matter what I set as the color space in Affinity. Always bright and oversaturated (skin tones are a joke). The same behaviour is visible with Lightroom and Photolab. It looks as if there is no color management at all. So, I'm lost.
  3. Well, I doubt that the CS240(28990025)03AdobeRGB.icc is a standard profile shiped with the display instead of a bespoke one. And the last time I checked I was able to tell the difference between a tiny button on my monitor from an iStudio colorimeter. However, thanks for looking into the issue.
  4. I couldn't agree more. But my displays are hardware calibrated on a regular base and use that specific profile. However, the contrast in colour between the two displays is so strong, that I have a hard time to believe that everything works according to plan. @v_kyr Thanks for that link. Looks like a long read...
  5. Hi there! I've an issue with colour management on Windows 10 (22H2) that is not limited to Affinity. But in the Affinity Apps the issue is clearly visible - and drives me nuts! That is my setup: Windows 10 (22H2), AMD Radeon RX 5700 XT 1. display: EIZO CS240, runs in AdobeRGB mode 2. display: Dell U2417H, runs in sRGB mode Windows Color Management: Display 1 set to individual ICC profile (AdobeRGB, created by ColorNavigator7) Windows Color Management: Display 2 set to sRGB IEC61966-2.1 (see screenshots) One would expect that all colors that are within the sRGB range are displayed in the same way on both monitors (at least in color managed applications). But that is not the case. On the EIZO everything is saturated and bright, on the DELL all colors are dull and dimmed. As if Windows doesn't respect the ICC profiles. If I add a sRGB softproof layer in Affinity (1.10.6) in a AdobeRGB document the EIZO shows also no difference in color - which surprises me. Any ideas what I am doing wrong? Thanks, Volker
  6. I did run some tests to verify what I claimed to have discovered... Well, it is complicated... Test A Started Firefox and XnViewMP, but not Affinity. Grabbed a screenshot of the browser. Created an empty image in XnViewMP and pasted the screenshot in it. Result: Everyting is displayed correctly. Started Affinity and pasted screenshot via "new from clipboard" Result: The screenshot ist broken (by 3 pixels on the left that belong to the right side) Test B Started Firefox, XnViewMP and Affinity. Grabbed a screenshot of the browser. Created an empty image in XnViewMP and pasted the screenshot in it. Result: Everything is displayed correctly. Pasted the same screenshot in Affinity via "new from clipboard". Result: The screenshot is broken. Test C As 1 - 6 in Test B. Created an empty document of 1920 x 1080 px and pasted the screenshot in it. Result: still broken. Test D Started Firefox, XnViewMP and Affinity. Grabbed a screenshot of the browser. Created an empty image in XnViewMP and pasted the screenhot in it. Copied within XnViewMP the pasted screenshot to the clipboard. Pasted the image in Affinity via "new from clipboard". Result: Image looks fine. So, somehow Affinity treats screenshots made by Windows differently from image data transfered via clipboard from other apps.
  7. It is not just Affinity that is affected by the issue. I've just tried to paste a screenshot in a new image using XnViewMP with the same outcome: The three right-most pixel are placed on the left side of the pasted image. However, if I do a second screenshot it gets pasted correctly once in a while. Again, if I copy the incorrectly pasted image from XnViewMP and paste it in Affinity, the offset is gone... Unfortunately I can't reproduce this behaviour every single time. To me it looks very random. So it might be a issue with Windows? (in my case: Win10 22H2)
  8. It seems that all the apps have lost steam... at least on my computer (Ryzen 7 3700, 32GB RAM, 1TB SSD, RX5700XT (8GB)). I've encountered a similar problem to @4dimage with the glyph browser, too. Without having measured it precisely, I'd say all V2.0 apps run half as fast as V1.x, sometimes even slower. Currently I prefer to use the older iterations of the Affinity apps if none of the newer features are required for the job. Let's hope, V2.0.1 will fix some of the issues.
  9. Hi, today I came across an interessting behaviour of exported svg files... and I am not sure whether its a shortcoming or a bug - and who is to blame! I was creating a larger graphic with some text frames in AD. For a proper text flow I inserted manually some soft hyphens and exported the design in the svg format eventually. In order to keep the file size small, I did not convert the text to curves. Afterwards I imported the svg file to MS Word (current version). The within the imported graphic displayed an interesstion behaviour: Whenever a hyphen was needed to smoothen the text flow within the graphic Word inserted another hyphen. So I ended up with "--" instead of a simple "-" plenty of times when a line had to be wraped. It doesn't matter whether automatic hypenation ist switched on or off in Word. You'll find all files needed to recreate the issue attached. Cheers, Volker textumbruch.afdesign textumbruch.svg
  10. Indeed, it looks like a color management issue. Has Cancon provided any ICC profiles with the printer as they usually sort out these issues?
  11. I know it is my fault, however, every time I use artboards I run into this issue. And it takes some extra steps to correct it (I always exort it first before I realize something is wrong...). One example: Create two artboards of size A4 with "force pixel alignment" and "move by whole pixels" switched on. The initial position of the artboards is fine, but the size is not: 2480,3 x 3507,9 px. If you move one of the artboards for any reason and let it snap to the other one you are in trouble afterwards. When moving the artboards now, the position is never an intereger value again but a floating one. The solution is to swich off "move by whole pixels" so that the artboard position can fall back to full interger values. However, it is a bit counter-intuitive... Maybe a different default setting could help.
  12. In contrast to @phil_k I do see a difference (see other post). Here are benchmarks:
  13. @Mark Ingram We have a dedicated workstation for video editing on which the Affinity apps are installed, too. The hardware is dominated by AMD: Ryzen 7 3700X + Radeon RX 5700XT on an Gigybyte Auros B550 mainboard and 64 MB RAM. Our performance issues occur when starting either Affinity or Blackmagic Resolve: It takes pretty long to load images and clips before they get displayed. An usual JPEG image of 2MB takes roughly 8-10 seconds to load in APh, if it is the first image to be loaded during a session. The next images load in under two seconds. It doesn't matter whether the images are dragged in or opened by using the open command in the file menu. It also doesn't matter whether or not APh has been running for some time: It is always the first image that gets loaded slowly. Having OpenCL disabled doesn't make a difference. Interestingly the same happens with mpeg4 or quicktime clips in BM Resolve: The first ones take ages to get displayed in the timeline, later on they get displayed immedeately.
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.