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

    208
  • Joined

  • Last visited

Everything posted by VolkerMB

  1. Just want to report the results of a test drive: Thanks to a friend I was able to connect a Benq display to my computer. To no avail. With my friend's computer the Benq rendered decent colors (also in combination with a LG-sRGB-display next to it), but with my computer it is a different story (yes, I used a fresh icc profile I created with my X-Rite colorimeter). Therefore, I took the Eizo to my friend's place to test it with his computer. The result: decent colors. So, my conlusion is: Something is broken or misconfigured under the hood of my pc. But without a degree in computer science I might not be able to get to the core of the issue. On the surface everything looks configured correctly, but somehow it is not. At least I can roule out that the display hardware is broken. On a sidenode: If I switch off icc settings with my second display (Dell) and let Windows decide how to address colors, both monitors look very similar in terms of tonality (temperature). Still, the Eizo is way oversaturated and overly bright, but the Dell shows warmer colors now. If I go back to icc profiles for the Dell, it renders colors much cooler, darker and dull, again. Next, I will try to get hold of a different graphics adapter...
  2. @rvst At least Windows flags the sRGB IEC61966-2.1 profile as a display profile... But I am not an expert. Therefore, I did install a dedicaded profile for the Dell U2417H from TFTCentral as suggested by @v_kyr. However, my eyes don't spot a difference to the sRGB IEC61966-2.1 profile. After having looked at several test images for at least 10min I'm under the impression that there is a tiny, tiny, tiny difference in how green is rendered. But apart from that... Unfortunately the Dell display is not the troublemaker here. It is the Eizo display. So, I called some friends and get hold of a Benq wide gamut monitor which I will install later today for test purposes. I'll report back later.
  3. 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.
  4. @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.
  5. 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.
  6. 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...
  7. 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
  8. 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.
  9. 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)
  10. 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.
  11. Hmm, I'm not convinced that we really deal with a problem here. If your document is meant for printing then it is no fun at all for users to read these long URLs or even to type them in a browser to get to the ressource. A shortend ULR would serve the user better. But if the original URL is needed under all circumsdances (e.g. legal reasons) putting it in a footnote/endnote (haha, good joke ;-)) with manually set line breaks could be the better option. The average user is capabale of reading them properly (as far as my eperience goes).
  12. @Pyanepsion Hi, I can confirm this. However, is it relevant? Usually, if you want to include a hyperlink to your document you use the hyperlink panel. Here, no line break of any sort is inserted and the hyperlink does work just fine in the final PDF. So, the display of the link to the human eye is not that relevant. Indeed, it is a different story with pasting such long URLs in a document without setting a hyperlink explicitly. Then it comes down to the guesswork by any pdf reader what the correct URL might be. And - in case of Acrobat - it fails.
  13. 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
  14. Indeed, it looks like a color management issue. Has Cancon provided any ICC profiles with the printer as they usually sort out these issues?
  15. Hallo Herby, aus mir nicht bekanntem Grund ist die sog. "Umbruchkontur" weit nach rechts ausgedehnt (siehe Screenshot 2). Entweder Du nutzt den Befehl "Umbruchkontur bearbeiten" oder setzt sie mit "Umbruchkontur zur├╝cksetzen" wieder auf den Ursprungswert zur├╝ck (siehe Screenshot 1). Dann verschwindet der auf der rechten Seite entstandende Leerraum. VG, Volker
  16. Hallo Herby49, APub verh├Ąlt sich hier korrekt. In dem Dialogfenster "Textumbruch" wird der (├Ąu├čere) Abstand zu den umgebenden Elementen festgelegt. Wenn der Text im Rahmen selbst (also die Bildzeile) mehr (Innen-)Abstand bekommen soll, ist dieses im Dialog "Textrahmen" (Men├╝: Ansicht -> Studio -> Textrahmen) festzulegen. Siehe beigef├╝gten Screenshot. Viele Gr├╝├če, Volker
  17. Thanks @Pauls for looking into these files. Unfortunately your workaround doesn't work for me. No matter where the files are located, APub (.1127 + .1135) crashes while loading. However, these files open fine with APub 1.9.2. So I used the older version to replace the ressources in question and saved the files under a new name. Now, they open fine with APub .1134 Nevertheless, APub 1.10 shouldn't crash because of a missing(?) ressource. Best, Volker
  18. Hi, unfortunately roughly 3 out of 10 of my older APub documents (created with versions 1.7, 1.8 and 1.9 in the first place) do crash the current retail version (.1127) and the latest beta version (.1135) of Publisher. APubs quits while loading without an warning. Two dump files of the latest crashs are attached. Fun fact: The next time I start APub it offers me to open a recovery file - which causes APub to crash as well. In case you need the files causing the issue, please do provide me with an upload link. Best, Volker b88c0894-3c82-4a75-8f39-d5b03bfd5e9c.dmp 764c60d5-e059-40d1-81cc-7ebeed4689b9.dmp
  19. 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.
  20. A regular source for problems is the current "unpolished" hardware acceleration. You can switch it off under "preferences -> performance" and see if it improves the situation. It is strongly advised for anyone who runs Affinity on an AMD Radeon GPU.
  21. In contrast to @phil_k I do see a difference (see other post). Here are benchmarks:
  22. Good to know that the Paragraph panel is the cause of the problem. So let's hope for a quick fix. Because... running a DTP app without the Paragraph panel...?
×
×
  • 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.