https://github.com/Quackdoc/

  • 0 Posts
  • 16 Comments
Joined 2 年前
Cake day: 2023年7月20日
  • Quack Doc@lemmy.worldtoLinux@lemmy.ml•Why doesn't the Linux subreddit leave Reddit already?
    2·
    9 天前

    A few things,

    • I often find the federation to just drop posts or comments,
    • sometimes a post has been banned and doesn’t even report being banned on other servers,
    • federation itself can be rather slow in many cases, and specific servers are even slower, you replied to this 10hrs ago according to lemmy, but I only got a notification 5 minutes ago despite using it off and on throughout the day.
    • you can have the exact same community name but on a multitude of different servers which can become complicated.
    • there is no button I can click to open the post on my server, which means if someone sends me a link and I want to engage with it, it’s a massive hassle to do so.

    there are other issues I have but these are the ones off the top of my head. It’s simply a far inferior experience to reddit.

  • Quack Doc@lemmy.worldtoLinux@lemmy.ml•On brightness, and calibrating your displays
    1·
    1 个月前

    I should elaborate on why the “Peak white” stuff is wrong, they give this math here for mapping linear luminance. This can be really confusing, “what do we map the references to” well if PQ “graphics white” is 203, should we map sRGB to 203? clearly not, at least not always as implied by BT.2408.

    the question as to what we map SDR content to in an HDR space is complex, and in many cases almost certainly not some number that we can do 1:1 mapping with, which is why specifications for inverse tonemapping exist. for instance BT.2446 defines multiple tone mapping algorithms to go from SDR->HDR->SDR or HDR->SDR->HDR or any step inbetween with minimal content loss and fidelity loss.

    we cannot do a simple one size fits all function and expect everything to be hunky dory

  • Quack Doc@lemmy.worldtoLinux@lemmy.ml•On brightness, and calibrating your displays
    2·
    1 个月前

    This makes a numerous amounts of incorrect assumptions.

    For one it assumes all sRGB monitors utilize gamma2.2 for decoding images. This is bluntly put, completely wrong. A large amount of displays utilize the inverse OETF (the peicewise srgb transform) for decoding sRGB. (for some more information from a somewhat authoritative body, filmlight’s “srgb we need to talk” video on youtube goes more indepth but TLDR is 25-50% of displays use the inverse sRGB oetf)

    this is why windows HDR uses the inverse oetf. Decoding content graded on a pure 2.2 display with the inverse oetf is way better then decoding content graded on an inverse oetf display with a pure 2.2. Windows took the safe route of making sure most content looks at least OK. I would not say that windows HDR is wrong, it’s not right, but it’s not wrong either. this is just the mess that sRGB gave us.

    Another time you should be using the inverse sRGB OETF to linearize content when the original content was encoded using the sRGB oetf and you want to go back to that working data, but this applies less to compositors and more to authoring workflows.

    Another wrong assumption

    When you use Windows 11 on a desktop monitor and enable HDR, you get an “SDR content brightness” slider in the settings - treating HDR content as something completely separate that’s somehow independent of the viewing environment, and that you cannot adjust the brightness of. With laptop displays however, you get a normal brightness slider, which applies to both SDR and HDR content.

    People have been adjusting monitor brightness for ages. Sometimes manually, sometimes with DDC etc.

    Another issue that is brought up is “graphics white” BT.2408 is a suggestion, not a hard coded spec, many different specs or suggestions use a different “graphics white” value. A good example of this is JXL. 2408 also very explicitly says ‘The signal level of “HDR Reference White” is not directly related to the signal level of SDR “peak white”.’

    this is important to note because this directly contradicts the some of the seemingly core assumptions made in the article, and even some of the bullet points like “a reference luminance, also known as HDR reference white, graphics white or SDR white” and “SDR things, like user interfaces in games, should use the reference luminance too”

    if your application has some need to differentiate between “SDR” and “HDR” displays (to change the buffer format for example), you can do so by checking if the maximum mastering luminance is greater than the reference luminance

    This needs to be expanded upon that this does NOT correlate to what the general user understands HDR and SDR to be. HDR and SDR in the terms of video content is no more then a marketing term and without context it can be hard to define what it is, However it is abundantly clear from this quote here that how they are interpreting HDR and SDR (which is a very valid technically inclined way of interpreting it) does NOT fall inline with general user expectation.

    Anyone reading this article should be made aware of this.

  • Quack Doc@lemmy.worldtoLinux@lemmy.ml•We don't need more Wayland Compositors
    9·
    6 个月前

    Click baity title aside. This is actually pretty much pretty true. What the vast majority of people want when they’re writing their own composers seems to be specifically the custom window management aspects.

    And it is true that even with something like Wlroots or a Smithay, it is a lot of works right your own composer and have it be “competitive”. And he is right. There are a lot of composers out there that are just not usable for anything more than the basics. And there are tons more which are just toys that have been abandoned that aren’t really usable. That being said we saw a lot of that with window managers, But yes, writing a compositor is a lot more then writing a window manager.

    I personally don’t use hyperland, but I can see the point he’s trying to make, and I think it’s a rather good point. I think if we had more compositors that focused on having a scriptable window management, then that would be for the better.

    I don’t really see this as toxic either. I mean, if it’s toxic to call a composite or trash in one way or another, then I would argue that 90% of the Linux community is far more toxic than he is. It’s just a matter of truth. Wayland is a big complicated thing with a lot of protocols and some of it is poorly documented.

    And of course, this is him shilling his own composter. It’s his own composter, and this is the blog about him making his own composter. Of course he’s gonna put a post on it, shilling his own compositor.

    That being said, As I said earlier, I would like to see a more scriptable take for things like window management. I don’t think hyprland has to be unique in this aspect, but as it stands, it most definitely is.

    pardon my weird language, its hard to use STT.

  • Quack Doc@lemmy.worldtoLinux@lemmy.ml•COSMIC Store Prototype
    0·
    1 年前

    First impressions is I’m shocked by just how fast it is, Aside from the first boot which for some reason doesn’t propagate apps and needs a reboot, it’s extremely fast, Gnome software and Discover aren’t even within the same league of responsiveness and speed. I didn’t showcase Discover since I don’t know where the cache files are to delete them.

    Touchscreen for sure I wish was handled better. you can see I accidentally clicked an app in the last video instead of scrolling, but thats something that I assume will be fixed with time.