Jump to content

Jimmini

Members
  • Content Count

    86
  • Joined

  • Last visited

Everything posted by Jimmini

  1. Actually I do have a question if you don't mind. Seeing that you're one of the few people who actually bothered to implement this properly, it would be very helpful if you could just briefly confirm whether I got the idea of this whole process right, so I don't base my decisions on wrong assumptions: 1) The display is roughly calibrated using OSD settings, if possible 2) Gamma curves are generated per channel that complement the prior calibration 3) A profile is created that accurately describes the transformation from CIELAB/CIEXYZ to the display's unique color space (assuming the prior calibration) 4) When the profile is installed, Windows loads the gamma curves into a table stored on the graphics card 5) Applications convert their colors to CIELAB/CIEXYZ, then to the display's color space using the transformation stored in the profile, and output it 6) The colors are automatically adjusted using the gamma table and then displayed On macOS, step 5 is done automatically system-wide. Is this somewhat correct?
  2. I have the slight feeling Microsoft wouldn't be very interested in such a bug report heh. Actually, they do seem to have added system-wide color correction already, but I think only for HDR monitors: https://docs.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range#wide-color-gamut-with-automatic-system-color-management I understand why adding an option to intentionally break your own application just to have it behave like the rest of the system isn't very appealing... And you made a good point that it would really just look "correct" on my own screen. I guess I'll just work around it how you suggested when really needed. Thanks for taking the time to clear this up.
  3. Hi, I appreciate your answer, and it seems you're right. I assumed that full color correction is done system-wide once a profile is set in the Color Management settings, but apparently only calibration curves are loaded. While that is definitely good to know, it doesn't change the fact that, as I mentioned before, colors don't match the ones in most other software, making it a pain to work with UIs, textures, screenshots, etc. So, is there a way to disable the color conversion, other than assigning my display profile to documents or disabling the profile on a system level? If not, would you consider adding such an option please? Anyway, sorry for the false alarm.
  4. I've seen that article already. It mentions an issue with default profiles, which I'm not using, and the issue of other applications not taking the color profile of image files into account, which isn't the cause either, since even single solid color outputs from standard Windows APIs without any image files involved are displayed differently. Considering colors in Windows are inherently in sRGB space, I only work with sRGB images, and Windows is already transforming colors using the active display profile, I don't see why Affinity would need to perform any additional conversions in my case. Even if there is a good reason for it and it's not considered a bug, it effectively results in colors being displayed differently compared to how the operating system displays colors, and I would like to have an option to disable it as it makes UI design a trial and error process. Also, I just figured out that colors are displayed correctly if I use my display profile for the document, but that's obviously a bad idea.
  5. This seems like a pretty major and obvious thing, so maybe I'm doing something wrong, but on both my computers in Affinity Photo and Designer 1.8.3.641 (and previous versions), colors are not displaying correctly when the color profiles I created for my monitors are enabled. Both hue and brightness are shifted compared to how the colors look in almost all other programs I've tested, including with images saved by Affinity Photo itself. I use the standard sRGB profile for documents and the color settings are at their defaults: Programs I've compared it to include Windows Explorer, Internet Explorer, Edge, Paint, Visual Studio, Blender, and VLC, all producing colors as expected. Only Chrome and Firefox seem to alter colors to different degrees. I've also compared it to various application programming interfaces by outputting a single color, i.e. Win32/GDI, WPF, OpenGL and Vulkan, again with colors showing correctly. Additionally, I tested it by taking a screenshot of a document opened in Affinity Photo and comparing it to the actual document: Here I made a gradient in Photo, made a screenshot of it and inserted it below the actual gradient. The red color (255, 0, 0) is made slightly pink (255, 8, 34) among other things. Apart from the color values, it also simply doesn't look like how I expect it. The only way I found to "fix" it is to disable the color profile altogether (i.e. use the default sRGB IEC61966-2.1 profile), or to enable it while Affinity Photo is running (but only until I restart the program). I'm using Windows 10, a Nvidia 650M with the latest drivers on my laptop and a 1080 Ti on my desktop PC. The color profiles were made with a X-Rite ColorMunki Display and DisplayCAL. It makes no difference whether I enable them with DisplayCAL or with the Windows Color Management dialog.
  6. In Affinity Photo 1.7.3.481, when switching document tab using the keyboard shortcut (Ctrl+Tab), often the wrong tab is shown. It seems like the keyboard-activated tabs are tracked separately from the ones activated with the mouse. Maybe the focus on the tab UI elements is being used to determine the next tab, which isn't being set when clicking on them?
  7. In Affinity Photo 1.7.0.367, when switching to a document with an open live filter window, the application becomes unresponsive.
  8. In Affinity Designer 1.7.0.367, when holding Ctrl+Shift when selecting a layer in the layers panel, the Shift modifier to select a range of items is ignored. It is thus not possible to select a range of items, starting from the last item that was selected with Ctrl.
  9. This may be intended but in Affinity Designer 1.6.1.93 group effects are not applied to children when exporting them using "Selection without background" as export area. This also happens when using the export persona. For example, when exporting the ellipse layer (not the group) in the attached file using "Selection without background", the circle in the exported image is green instead of blue and is missing the outline. I have a document with multiple layers on which a group effect is applied, but when using the export persona to export the individual layers, the effect is lost, so I have to apply the effect to each layer individually. Group Effects Export Bug.afdesign
  10. Sadly still the same. I don't notice any difference. The application is unusable for a few minutes, even when I manage to deselect the layer and switch tools. Even when the CPU usage drops to 0% again after some time, the application is *very* slow to use afterwards, whenever the document has to be rerendered (where CPU usage even goes to 100% on all four cores). Changing font, font size, text alignment or transforming the shape doesn't make a difference either.
  11. Sure. I'm running Windows 10 64-bit, Intel i5-7600, 16GB DDR4, NVIDIA GTX 1080 Ti. CPU usage goes to about 40%. The same happens in Affinity Photo. It only happens when holding CTRL while dragging the handles. After dragging the handles using CTRL for a bit, it's even slow without pressing any modifier keys afterwards. The amount of time the application freezes depends on for how long I dragged the handles.
  12. In Affinity Designer 1.5.3.69, when dragging either the start or end handle of the text path in the attached file, while holding the CTRL key, the application slows down significantly and ultimately becomes unresponsive. TextPathBug.afdesign Edit: I mean these orange handles which define the text's range:
  13. In Affinity Designer 1.5.3.69, when moving a compound shape into a group with custom constraints, the application crashes. (See the attached file) Group Bug.afdesign
  14. In Affinity Designer 1.5.3.69, when changing the constraints of the circle in the attached file, while the rectangle is hidden, the rectangle gets cropped to the circle's dimensions (which can be seen when enabling the visibility of the rectangle). This does not happen when the rectangle is visible while changing the circle's constraints. I could imagine this to be intentional behaviour, but I thought I'd post it anyway. If it's indeed intentional, is there someway to retroactively show the whole rectangle / undo the crop? Children Visibility Constraint Bug.afdesign
  15. In Affinity Designer 1.5.3.69, when changing the constraints of the rectangle in the attached file, it gets repositioned and stretched. This only happens when the rectangle's group has constraints set to either right, bottom, or both. Children Transform Constraint Bug.afdesign
  16. It happens if the cursor is not exactly on the pixel grid when you start drawing the selection. For example like this: It's more obvious if you zoom in a lot, like when you open the attached file. But it's really not a big issue, I'm just posting everything which I think doesn't work as intended, that catches my eye during work, so that the team knows about it. Selection.afphoto
  17. Yes, but I can't do that in certain situations, especially when dealing with raster image files. And regardless of whether or not it is needed, it's still a bug.
  18. In both Affinity Photo Beta 1.5.2.63 and Designer Beta 1.5.3.63 (with the "force pixel alignment" option activated), the sizes of pixel selections displayed in the transform panel are inaccurate while drawing them. For example, the selection's width in this screenshot is displayed as 29px, but is actually 30px: This is only the case as long as the mouse button to draw the selection is held down. I assume this happens because the selection's drawing starting point doesn't lie exactly on the pixel grid but at non-integer coordinates (as the view is zoomed in) and the size calculation doesn't consider the "force pixel alignment" option while the selection is still being drawn, thus resulting in the rounding error. As soon as I release the mouse button, the values in the transform panel get displayed correctly. It's not a major issue but a bit irritating nonetheless, as I regularly use the rectangular marquee tool to measure distances.
  19. It would be quite helpful as I often work with rather lengthy slice names and I have to "rename" them to see the full name (or resize the panel, of course).
  20. That's unfortunate, as it really limits how many nested layers you can have and how long their names can be. They seemed to work pretty well. Couldn't the space required for the scrollbars just be reserved while hidden to avoid the panel's size from changing? I know this problem from web development where I solve it by always showing the scrollbars. As this is a native application, they wouldn't have to be always visible, but only considered by the layout engine.
  21. I just tried the latest beta versions of both Designer and Photo and it doesn't happen in the layers panel anymore, but it still does in the slices panel.
  22. No, I only use one 1920x1080 monitor, no DPI scaling.
  23. Yes, I know it's only temporary. The problem is that you have to drag a handle with the mouse before using the transform panel to avoid the temporary selection box to revert to it's default state. Surely this isn't intentional? Have you tried the steps in my first post?
×
×
  • 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.