Improve spacing of scan code samples in docs

          1 Warning

:warning:
Please provide a changelog summary in the Pull Request description @KrauseFx

  Generated by :no_entry_sign: Danger


"Run To Cursor" does nothing in run mode

Related issue : https://github.com/OmniSharp/omnisharp-vscode/issues/1297
"Run To Cursor" context menu is available when the process is running. When invoked it does nothing.
Either it should not be displayed when the application is not in a break state or it should set a breakpoint on that line.

@rajkumar42 I agree. We are now not showing the action if debugging is not stopped.

@isidorn Thanks!


[TODO]: Prepare beta for USB upstreaming

Todo
Original text from plugwise/plugwise-beta#361
Following https://plugwise.github.io/progress/diff.html
Adding # pw-beta tags where appropriate to ease up differences
PR is also meant as a step-up to see if we can carve out a way for the Core Team to decide on embedding USB into the Core Plugwise environment. E.g. making sure the 'mammoth' that is now https://plugwise.github.io/progress/diff.html can be used as an oversight and from that we can chunk PRs in a relative quick pace to ensure we embed USB within a month between releases. As such re-breathing live into Core PR 35713
Checklist as per Progress diff core/beta beginning of March 2023: (note that all COORDINATOR relations are under coordinator.py to not re-iterate across all domains)

[x] USB plugwise/__init__.py replaces placeholders when upstreaming
[ ] Generic/USB plugwise/binary_sensor.py``dataclass structure needs conformance/decision between beta and core
[x] Generic plugwise/climate.py though mainly 'options' which won't upstream
[x] USB plugwise/config_flow.py foremost USB flow handling + some exceptions
[ ] Generic/USB plugwise/const.py const & dataclass
[ ] Generic plugwise/coordinator.py untouched, needs alignment between beta and core
[x] Generic plugwise/diagnostics.py *) except coordinator
[x] Generic plugwise/entity.py only isorted
[x] Generic plugwise/gateway.py mostly beta-only related things
[x] Generic plugwise/manifest.json no actions needed specifically
[ ] Generic plugwise/number.py needs alignment
[x] Generic plugwise/select.py *) except coordinator
[ ] Generic/USB plugwise/sensor.py dataclass structure needs conformance/decision between beta and core
[x] USB plugwise/strings.json
[x] USB plugwise/switch.py
[ ] Generic plugwise/util.py

(not in plugwise/plugwise-beta#361) This also depends on python-plugwise issue 131 to have more proper testing involved, but we might leverage community effort there as well once we have upstream in place.

See #9 and #15 - declaring this issue obsolete as per recent split.


Unable to build OS.jsv2 at makefile

I did follow the instructions but at the makefile build, i met the following error:
C:\Users\khoaa\Desktop\OS>make
rm -f dist/themes.json ||:
rm -f dist/packages.json ||:
rm -f dist-dev/packages.json ||:
rm -f dist/osjs.* ||:
rm -rf dist/packages/* ||:
rm -rf dist/themes/* ||:
\033[1;35mBuilding OS.js Configurations\033[0m
(src/tools/obt config)
undefined:83
"vfsdir": "C:\Users\khoaa\Desktop\OS/vfs/home",
^
SyntaxError: Unexpected token U
at Object.parse (native)
at generateBuildConfig (C:\Users\khoaa\Desktop\OS\src\tools\obt:132:17)
at C:\Users\khoaa\Desktop\OS\src\tools\obt:52:17
at Object. (C:\Users\khoaa\Desktop\OS\src\tools\obt:1225:3)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:501:10)
at startup (node.js:129:16)
makefile:42: recipe for target 'config' failed
make: *** [config] Error 1
please help me!

It appears you are running Windows. It is not supported at this moment (because of some of the dependencies). Sorry :/ Your best bet is a Virtual Machine to use as a server.
FYI: Support for Windows is coming. I just have been way to busy lately to make it work

Also, it tells you what is wrong. It's a syntax error in the config file at this line:

"vfsdir": "C:\Users\khoaa\Desktop\OS/vfs/home",

maybe it's the backward slash causing problems

thanks for reply :+1:

No problem. I can send you a message when the Windows support is complete if you want :)
Created an issue for it: Support for Windows Servers #94


[CT-2619] [Feature] Group and access configuration for sources

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Hi
We would like to be able to control access to sources as well as models using group access.  So private sources will only be accessible from within their assigned group.
Currently this is possible for models, seeds, snapshots, tests, analysis and metrics, but not sources.
Groups
Model Access
Describe alternatives you've considered
No response
Who will this benefit?
Anyone who wants to limit access to sources as well as models.
Are you interested in contributing this feature?
I don't know how to
Anything else?
No response

@Thrasi Thanks for opening, and sorry for the delay getting back to you!
Could you talk to me more about your use case for "private" sources? Are these source tables containing sensitive data (PII), and is your idea to prepare them (perhaps anonymize in a staging layer) before surfacing to the rest of the project / analytics universe? If so, thinking within the realm of model access: I'm wondering if these are "private" sources, or if this is really a use case for splitting out these sources & staging models into an entirely separate project, and surfacing those as public models for use in other projects?

In the initial implementation for v1.5, we didn't include sources within model/resource groups because:

We've implemented this logic for ref, but not yet for source
Sources are already "grouped" within their parent source — a loader instead of an owner, etc
My belief: Guarantees that need to be enforced on a source (contract for data shape, data quality rules, etc) are more enforceable if defined on a staging model that wraps around that source. While dbt can run introspective queries against sources, it can't actually control the shape or content of the source table.

Hi! @jtcohen6 Thanks for the response!
I think you are probably right about:

this is really a use case for splitting out these sources & staging models into an entirely separate project, and surfacing those as public models for use in other projects

One of the reasons we haven't is that we want access to the full lineage graph.
Hoping for great results from this
I can still describe the situation:
Instead we use sub directories and groups. Teams own their own sub directory and group, with their own sources and models.
Through groups they can make some models public and accessible to others and keep staging models private.
In this setup, sources in one sub directory are always accessible to models in other directories.
We can limit access to them using CI.  For this specific setup it may seem natural to extend the concept of groups to sources.
But then this setup may not be optimal to begin with.

Given that this has lingered for a little bit, I'll add my two cents.
Suppose you're working in a large (1000+++ models) project with dozens of analytics engineers across multiple distributed teams owning different parts of the DAG. Now, suppose that the project leverages groups and access to create interfaces to core marts that can be used between groups.
While we'd love for everyone to follow best practices, without group and access configurations on sources, there's no technical mechanism within dbt Core to prevent someone from referencing the source within a new model, fundamentally bypassing any dbt Core access controls in place.
flowchart LR

    classDef source fill:#60b826, stroke:#60b826, color:#fff
    classDef model fill:#0094b3, stroke:#0094b3, color:#fff

    classDef privateModel fill:#ffffff00, stroke:#0094b3, color:#0094b3

    style product fill:#ffffff00, stroke:#bbb
    style revenue fill:#ffffff00, stroke:#bbb
    style customer_success fill:#ffffff00, stroke:#bbb

    crm.deals:::source
    crm.customers:::source
    product.events:::source

    subgraph product
        stg_product__events:::privateModel
        user_events:::model
    end

    subgraph revenue
        stg_crm__deals:::privateModel
        stg_crm__customers:::privateModel
        deals:::model
    end

    subgraph customer_success
        report_product_outcomes:::model
    end

    crm.deals --> stg_crm__deals
    crm.customers --> stg_crm__customers

    product.events --> stg_product__events

    stg_crm__deals --> deals
    stg_crm__customers --> deals

    stg_product__events --> user_events

    crm.deals -- Bypass access and groups by using `source` --> report_product_outcomes
    user_events --> report_product_outcomes

Other options
Something something marcos?
I'm confident that an enterprising community member could implement a macro that runs on-run-start to check metadata on the source and raise a compilation exception if cross-group source references are being made. But, this is also a bit of a kludge fix for what (in my opinion) should be part of dbt Core's functionality.
Use multiple projects

I'm wondering if [...] this is really a use case for splitting out these sources & staging models into an entirely separate project, and surfacing those as public models for use in other projects?

My primary rebuttal to this is that there is no dbt-core-specific way to actually do this!

If we create a project to stage our staging models and import that project as a package into our main project, the sources are also defined in the upstream package. This leaves us where we started, since sources cannot be in a group and cannot have access assigned.
By your own words, proper cross-project references and multi-project deployments are wholly in the domain of dbt Labs' proprietary software and not in-scope for dbt Core. On a philosophical note, I'd rather take the plunge and purchase dbt Cloud seats and pay for Successful Model Builds because I need dbt Cloud functionality, and not because I want to skip working around gaps in dbt Core's governance functionality.

Okay, @Thrasi and @nicholasyager we buy it!
After discussing this further with @graciegoheen and @jtcohen6, we are aligned for adding support for groups + access on sources 👍
For consistency, we'll add it to exposures too so that all resource types can be grouped (see #https://github.com/dbt-labs/dbt-core/issues/8550)
We haven't seen convincing use-cases for exposures yet, so we will document as a best practice that you probably shouldn't be "exposing" a private model :slightly_smiling_face:

Acceptance criteria

group and access work for sources
group works for exposures

As described here, referencing a resource outside of its supported access should raise an error (but otherwise should not).
So a private source should not be referencable outside of its group. And a private model should be referencable by an exposure inside of its group.

Notes from technical refinement:

would allow folks to set this for the source, and also for a specific table within a source
it's a config (enabled is the only one right now https://docs.getdbt.com/reference/source-configs), may be more complicated
we could split this up into 1 ticket for group, and 1 ticket for access - but we'd need to do the group piece first
if we are going to support public for sources, then we'd need to update the plugin and publication artifact and inject source nodes (the same way we do for public models) - is there a use case for this? we could start with only supporting private and protected for source access? do we want to allow public sources? protected is the default for other resources, but we could do it differently for sources
sources can be overriden in a project, if we have public sources would we then need a 3-argument {{ source ... }} ?  if we don't need a cross-project source, then we should explicitly not support public sources?

Thanks for all of the input, I'm going to close this one in favor of an implementation ticket -> https://github.com/dbt-labs/dbt-core/issues/9339


Map dont set value on draggrable on false

When the map loads and draggrable is false, the map doesnt set value of LiveLocation

Hi @octaviogamero27
When draggable is set to false, what trigger should the liveLocation feature use to receive and share the location live? Isn't the liveLocation feature essentially meaningless without draggable?

Isnt this solved yet?

Hi
To clarify, the liveLocation function dynamically updates the location by capturing it from the map in real-time as the marker is dragged and dropped. This updated location is then sent to the Livewire component, allowing the lat and lng fields to be updated live.
Based on your description:
You need the map to be read-only, while the browser periodically (e.g: every 10 seconds) retrieves the user’s location, encodes it, and updates the lat and lng fields. Is that correct?

Hi there, thanks for the quick response!
That would be perfect!
And even if the location is obtained only at initial render it would be
enough. (plus being readonly).
If you can make location updates periodically as you say, even better!
Feel free to tell me if you want me to help in implementation, i am more
than willing!
King regards.
El El mié, 4 sept 2024 a la(s) 1:19 a. m., Hessam Taghvaei <
@.***> escribió:

Hi
To clarify, the liveLocation function dynamically updates the location by
capturing it from the map in real-time as the marker is dragged and
dropped. This updated location is then sent to the Livewire component,
allowing the lat and lng fields to be updated live.
Based on your description:
You need the map to be read-only, while the browser periodically (e.g:
every 10 seconds) retrieves the user’s location, encodes it, and updates
the lat and lng fields. Is that correct?
—
Reply to this email directly, view it on GitHub
https://github.com/dotswan/filament-map-picker/issues/26#issuecomment-2328101164,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A26OYSYO7C7AMUVXJESQJMDZU2X7XAVCNFSM6AAAAABKF7WSMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRYGEYDCMJWGQ
.
You are receiving this because you commented.Message ID:
@.***>


MAINT: optimize: refactor common linprog arguments into namedtuple

Reference issue
Partially addresses #9671
What does this implement/fix?
It refactors c, A_ub, b_ub, A_eq, b_eq, bounds, x0 into a namedtuple.
Summary

Added the proposed namedtulple into _linprog_util.py
Refactored related functions in _linprog_util.py, _linprog.py, and tests for _clean_inputs
Modified assertion on bounds in test_aliasing and test_aliasing2 (np.inf -> None and -np.inf -> None)

@Kai-Striega does this look like what you had in mind in #9671?

@zchelseal @mdhaber My thoughts on being public/private

But I think @Kai-Striega's original purpose was to simplify passing all the information around internally.

Yes, that was the idea.

Also, we didn't really discuss whether this class would be public or not, but it sounds like we're assuming it will be.

I'm not certain that it should be public (yet). We're already discussed other API changes e.g.  #10136 (Yes, I will get back to it.) or having array_like types for bounds. Maybe we could use it internally first, see how it fits, then make the major API changes within a single release?

That sounds good to me.
Internally, I'd prefer to initialize the objects with separate arguments, no dictionary.

Didn't make it all the way through. Some thoughts to start.

Thank you so much @mdhaber for your speedy response! I was able to fix most of the affected test cases offline except 6, where I was a little lost and hoped to get your insights on :)

Didn't make it all the way through. Some thoughts to start.

Thank you so much @mdhaber for your speedy response!
I was able to fix most of the affected test cases offline except 6, where I was a little lost and hoped to get your insights on :)

@zchelseal Thanks for your patience!
This got pretty big, so it will really take some time to sit down and review as it is. I'm thinking about whether there is a small adjustment we can make that will reduce the number of line changes. For instance, if _clean_inputs were to accept not only the new lp structure but also the old inputs, then we could revert many of the changes to the tests. That would make me a bit more comfortable about this, even though many of the changes are minor.
What do you think, @Kai-Striega ? Is this what you envisioned?

@mdhaber would you have the time to give this a thorough read through? I don't think there is anything to stop us merging the PR as @zchelseal work looks good.
I can fix the merge conflicts if you think it's OK.

Thanks for your patience. I'm pretty backlogged. You had some comments - did you think they needed to be fixed before merge or were you happy with it anyway?
If you think it's ready, other than merge conflicts, I'll try to take a look this weekend.

@mdhaber I had some comments but they shouldn't stop us merging. At this point, the major blocker was discussing the test changes.

trying to figure out a way to set up SciPy on my personal PC or a school Mac -- @zchelseal

What kind of computer are you using? I've been 50:50 about creating some tutorials on how I build it on Windows and Linux.

Is there a problem with the Development Environment Quickstart Guides?
@zchelseal I suggest Mac, but if you only have Windows, you can use the Docker instructions.

@mdhaber they are very good 👍. What I've wanted to add is a guide without using Anaconda and avoiding homebrew in favour of apt (that's already used to install git) and possibly an instruction video to compilment your Mac videos.
I've also been trying to build SciPy with Intel + MKL on Windows, but thats proving to be a challenge.

@kai-striega I agree. That cuts down on the number of instructions for sure. I've wanted to add that too, but first I wanted to fine out how these should all be organized. There are so many combinations of options for doing the same things. Can we set these up so they are easier to maintain than a separate file for each combination?
If you can help me merge #10461 I can help you with non-Anaconda guides.

Sure thing. It's nearly midnight here, but, I'll take a look tomorrow.
On Fri., 20 Sep. 2019, 22:49 Matt Haberland<EMAIL_ADDRESS>wrote:

@Kai-Striega https://github.com/Kai-Striega I agree. That cuts down on
the number of instructions for sure. I've wanted to add that too, but first
I wanted to fine out how these should all be organized. There are so many
combinations of options for doing the same things. Can we set these up so
they are easier to maintain than a separate file for each combination?
If you can help me merge #10461
https://github.com/scipy/scipy/pull/10461 I can help you with
non-Anaconda guides.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/10602?email_source=notifications&email_token=AHFOJNPTE4DEG5QCDAUHXF3QKTPIHA5CNFSM4IJPN3N2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7G5YZI#issuecomment-533584997,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHFOJNPGZMAXWTMC76JKOZDQKTPIHANCNFSM4IJPN3NQ
.

Oops. This sort of thing has happened to me before, but I'm not an expert at diagnosing and fixing it yet. @zchelseal do you know what caused all these other things to appear? @Kai-Striega suggestions?

@mdhaber This seems to be unintended behaviour caused by GitHub not tracking new commits to the target branch since PR opened - I found a workaround here and it should be fixed now!

Hmm weird failure for the pyflakes check. I re-ran the CI job, it's real:
scipy/optimize/tests/test__linprog_clean_inputs.py

The command "grep -rlIP '[^\x00-\x7F]' scipy | grep '\.pyx\?' | sort > unicode.out; grep -rlI '# -\*- coding: \(utf-8\|latin-1\) -\*-' scipy | grep '\.pyx\?' | sort > coding.out; comm -23 unicode.out coding.out > test_code.out; cat test_code.out;  test \! -s test_code.out

" exited with 1.

Unlike normal style checker failures, it doesn't tell you what's wrong. Perhaps you can reproduce locally?

I added a couple drive-by comments (not a full review).

@mdhaber Would you mind taking another look for any other changes I should make before merging?
I've fixed the test_aliasings to check for in-place modifications along with the other suggested changes (thanks to everyone who reviewed!) :)

I will try, but I'm traveling internationally this week so I'm not sure when I can. Thank you for working on this!

Looks like I will have to bump this to 1.5.0, but it certainly looks like some high quality work is happening here.
I bet those sphinx-theme changes just snuck in with something like git add -u after switching branches. I catch myself doing that sometimes..

@mdhaber you still have some "changes requested" are you satisfied that those changes in particular have been fixed?
@zchelseal There are some sphinx-related changes which I would like to avoid merging, do you have any ideas for how to remove them?

Well, I just approved the changes to not hold up your merge, but I think my "changes requested" was for removing the sphinx changes.

@mdhaber or @tylerjereddy there have recently been some new issues discussing possible enhancements to linprog. I would like to try to get this merged ASAP otherwise I think it will lead to major merge conflicts later.
Is there a way for me to "nicely" remove the sphinx changes myself while still giving the commit credit to @zchelseal?

Is there a way for me to "nicely" remove the sphinx changes myself while still giving the commit credit to @zchelseal?

@Kai-Striega authorship is per commit; you can just push a new commit to zchelseal:refactor_linprog_arguments that undoes the unwanted changes, and everything will be as it should be.

@rgommers thanks! I've fixed the merge conflicts - I'll let the CI run just to make sure it is all done properly then remove the sphinx changes then (hopefully) merge.

Thanks @zchelseal! If you'd like your name added to THANKS.txt, please make an entry here.

Hi @zchelseal, just thought I'd thank you again and invite you back! Let me know if you're looking for something interesting to tinker with; there are always things to do!

@mdhaber Thank you so much for the message and my apologies for the late response! Things have been a little overwhelming lately :'(
I'd love to work on more issues in scipy.optimize after my current internship - is there something I can help on starting end of May?

@zchelseal great to hear that you are still interested.  Matt has kept track of additional cleanups (#9671) and a wishlist (#9269) for linprog - if you're looking for more issues that's the best place to start.
Also, congratulations on getting an internship!

Yeah, anything on those lists. I think these two would be pretty easy:

allow bounds to be specified as Bounds objects (#10288)
automatically remove constraints with infinite upper bound (#10288)

and anything to do with sensitivity analysis. We're in the process of adding a new solver and I think those things would still be useful afterwards.


Aspsk/backports to v1.11

Backport of the following PRs:

https://github.com/cilium/cilium/pull/20711 (@aspsk)
https://github.com/cilium/cilium/pull/20859 (@aspsk)

"Check if build works for every commit" failure looks legitimate

"Check if build works for every commit" failure looks legitimate

Yes, I know the reason, will fix shortly

/test-backport-1.11

/test-backport-1.11

/test-gke

/test-1.18-4.9

/test-gke

/test-gke

/test-gke

/test-gke

/test-gke

test-gke failed for below flake

Suite-k8s-1.22.K8sDatapathConfig MonitorAggregation Checks that monitor aggregation flags send notifications


BKMC Checklist

[ ] Update SSI Definition
[ ] Add Surgeon Level field in first step (auto-generate based on the list)
[ ] Add Patient Address in the second step till the lowest level available
[ ] Add SSI Criteria in the third step
[ ] Add SSI detected field with within the fourth step and add multi-select options specified in document
[ ] In Fourth step, close the application if the answer to field 'Has SSI Been Detected is selected' as 'No'
[ ] If answer to 'Has SSI Been Detected is selected' is selected as Yes, show the field SSI Decected with radio button options shown in the document.
[ ] In fifth step, add 'Surgical Procedure Planning' filed with radio button options
[ ] In fifth step, update 'Type of SSI' filed as shown in the document
[ ] In eighth step, add 'Surgican Hand Preparation' field with its radio buttons
[ ] In eighth step, add 'Time Spent on Procedure' field with its radio buttons
[ ] In eighth step, add 'Proper Skin Preparation & Allowed to Dry' field with its radio buttons
[ ] In eighth step, add 'Surgical Skin Preparation (under sterile conditions)' field with its radio buttons
[ ] In ninth step, add 'Operation Theatre Name' and add Old OT and New OT for the BKMC hospital only
[ ] In eleventh step, add 'Post-op Antibiotic Given'. If selected Yes, show field from 2 to 5.
[ ] In eleventh step, add 'Post-op Antibiotic' field with dropbox
[ ] In eleventh step, add 'Dose per Day' for Post-op Antibiotic' fields with radio button options
[ ]  In eleventh step, add 'Duration in Days' fields with radio button options
[ ]  In eleventh step, add 'Indication for Post-op Antibiotic' fields with radio button options
[ ] Add numeric field up to 4 values, titled 'Numbers of Times Post-op Antibiotic Changed' in the eleventh step
[ ] In eleventh step, add 'Non-infectious Surgical Wound Complications' with radio button options
[ ] In twelfth step, update the order of 'Pathogen Classification' field as mentioned in the document
[ ] Replace the current 13th step with the title 'Surveillance Period' and field titled as 'Surveillance Period Completed' with radio button options
[ ] Update the current 13th field to 14th field and update the order of its field 'Pathogen Classification' field as mentioned in the document

Reference document https://docs.google.com/document/d/1Vpf5t5kgJB2NpyzEBTZws6dgoEx7Kxed76elH9-HzGU/edit?usp=sharing

https://docs.google.com/document/d/1Vpf5t5kgJB2NpyzEBTZws6dgoEx7Kxed76elH9-HzGU/edit

https://icd.who.int/en

@sohail0992 SSI Detected field is missing.

@sohail0992 please please use the same approach for Type of SSI as the SSI Criteria field

@sohail0992 please add radio button descriptions in brackets to Wound Class field (Check document).

@sohail0992 please show an editable text field if Others option is selected in Comorbid Condition field

@sohail0992 please add the content in the bracket to information icon for this field: Additional Dose During Procedure (Operation more than 4 hours or major blood loss)

@sohail0992 update Proper Skin Preparation to Proper Skin Preparation & Allowed to Dry

[ ]  SSI Detected field is missing.
[ ] please use the same approach for Type of SSI as the SSI Criteria field
[ ] please add radio button descriptions in brackets to Wound Class field (Check document).
[ ]  please show an editable text field if Others option is selected in Comorbid Condition field
[ ] please add the content in the bracket to information icon for this field: Additional Dose During Procedure (Operation more than 4 hours or major blood loss)
[ ] Surgical Hand Preparation and Time Spent on Procedure fields are missing in the step 8
[ ] update Proper Skin Preparation to Proper Skin Preparation & Allowed to Dry. Also please re-check step 8, a number of fields are missing.

Working: Step 7 Antimicrobial Prophylaxis Administered (Radio Buttons - If yes, show the Fields from 11 to 14)
Fixed (Download APK) Step 12: Pathogen Causing SSI OnPositive Growth (Show the fields from 2-6 if the second option is selected)
Working Fourth Step: Has SSI Been Detected? (Radio Buttons - If selected No, end the session)
@bushramustafa

[ ] Post-op Antibiotic (Drop-box) field is missing @sohail0992

@sohail0992

[ ] User should be able to view their entries only in the Submitted View
[ ] Add information icon with Pathogen Classification (where applicable) and add text, "Please select as per the culture report."

@sohail0992

[ ] In step 5, field Surgical Procedure Planning, remove brackets from its three fields.
[ ] In step 8, update the (under sterile conditions) to (Under Sterile Conditions)
[ ] In Step 11, when I select No, the field Number of Times Post-op Antibitoc Changed should not appear.
[ ] In Step 11, change Numbers of Times Post-op Antibitoc Changed to Number of Times Post-op Antibitoc Changed
[ ] In step 3, field SSI Criteria, add 'Other evidence of infection found on invasive procedure, gross anatomic exam, or histopathologic exam' and 'Other Signs & Symptoms' to the cascaded checkboxes of the Signs & Symptoms'
[ ] In Step 6, Other Comorbid Condition text box should only show if Others is selected in the Comorbid Condition.
[ ] In Step 11, update the bullet point of the field Indication for Post-op Antibiotic from 'Treating Suspected or Non-infection' to 'Treating Suspected or Known Infection'.


Add support for configuring Gradle Enterprise settings via system properties

The Gradle Enterprise Maven extension allows users to configure most Gradle
Enterprise configuration settings via Java system properties. This is really
nice when it comes time to run build experiments (particularly during a Gradle
Enterprise trial) because it makes it easy to change settings when running
builds on CI servers (it often avoids the need to make code changes that need
to be pushed to the git repo).
For example, it is possible to disable to local cache but enable the remote
cache through system properties when doing Maven Trial Experiment Number 3. The
user can configure just their CI configuration to make this change and they
don't have to actually edit their Gradle Enterprise configuration files.
Unfortunately, the Gradle Build Tool and Gradle Enterprise Gradle Plugin only
support configuring a small number of settings via System properties.
To afford the same convenience to Gradle users, this PR updates the Common
Custom User Data Gradle plugin to honor the same (or similar) system properties
honored by the Gradle Enterprise Maven extension.
The same property names are used to make it easy for a user familiar with the
Maven extension to also configure a Gradle build (and vice versa).

I put this PR In draft mode because:

I have not yet finished fully testing that all of this works. I've tested enough to know that the various config values show as having been properly set by inspecting build scans, but I haven't yet finished testing if they actually take affect.
Need to add some details about all of these config settings to the README.

@jthurne I'll take a look today. one thing we need to change for sure is reading the sys props (and env vars?) in a way that is config cache compatible (meaning we need to use CC APIs to read/declare them).

Pro tip for reviewers, you can add ?w=1 to the url to ignore the whitespace changes.


Include response body in HTTPError exception in Python library

The protocol includes the error message in the response body, which is not forwarded through the HTTPError exception. The exception format would be similar to how the Databricks CLI handled it.
Previously, the exception error message looks like:
requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: <redacted>
Now, the exception error message looks like:
requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: <redacted>
 Response from server:
 { 'errorCode': 'PERMISSION_DENIED',
  'message': '<redacted>'}

I think HTTPError.response.text has the body. I'm not a Python expert so I'm not sure what's the convention in Python to handle HTTPError. But it seems weird to modify HTTPError when it has already the information.

I think HTTPError.response.text has the body. I'm not a Python expert so I'm not sure what's the convention in Python to handle HTTPError. But it seems weird to modify HTTPError when it already has the information.

https://github.com/databricks/databricks-cli/blob/master/databricks_cli/sdk/api_client.py#L143
Following this. The problem is that the default message does not include the response body, so even you crash, if you don't catch the request and extract the message manually, you would not why it failed. This provides better error messaging, especially for Python shell users importing the library.

Note that the request and response fields would still be available in HTTPError for downstream exception handlers to use. It's just that the message that is modified.

Yep I understand your change. My question was more about why Python requests doesn't put the response body into HTTPError message. I guess it cannot because it doesn't know what the response body could be. For our case, it should be fine.


Thanks 🙏❤

I just wanted to say 👍 thank you to the contributors. Lolex just saved me a ton of time (no pun intended), and was trivial to set up and use in my tests.
🎉🎉 Thank you!  🎉🎉

As best I can tell from git history, @cjohansen was the original author. He extracted lolex from sinon with dbd7d17029f5b258aa14422b74798c844de8bfab in 2014. There were probably other contributors from that era that could also be considered OG.

Thank you for those nice words, @ryanwmarsh. It's stuff like that that makes people contribute :-)
P.S. I don't know about me being primary maintainer. I always regarded Morgan as the primary maintainer :-) I guess the term is a fleeting concept, based on who has time available, and currently that isn't usually me :baby:  :baby_bottle:

Thanks @cjohansen !

I just came by to say the same thing. This library is fun to use and makes my daily life easier. Thanks ❤


docs: various improvements to Python API tutorial

Summary
Several documentation improvements to the Python API tutorial
Originally started to fix the same note as #187, but noticed several other improvements that could be made
Details

additions:

add link to the Python API reference
add link to the FAQ for getting API keys

stylistic improvements:

simplifications:

"databases are databases" is redundant
"default configuration is applied by default" is redundant
also remove redundant words like "that"; state directly instead
see also k8s style guide on direct language (which I use and reference often for docs -- it's a pretty great style guide!)

remove duplications:

remove duplicate "learn more" configuration link
remove duplicate note on the demo assistant

consistency + parallelism:

use same formatting for Vector DB choices as LLM choices

i.e. bold + code backticks

for demo helpers, consistently use "Not x. Instead y. It provides a quick way [...]"

previously this had a few different formats, different conjunctions, etc
parallelism & consistency makes this easier to understand

code style:

~remove new line after !!! note~

~otherwise most markdown editors will recognize the block as a code block due to the 4 space indentation~
EDIT: reverted due to prettier per review comments, c.f. https://github.com/Quansight/ragna/pull/197#pullrequestreview-1726123408

fix various spelling and grammar errors and typos:

"it's" -> "its"

"it's" = "it is", "its" = possessive

no comma needed after "And"
comma splice in "vector database, and similar" -> split into two sentences
comma splice in "actual database, but" -> split into two sentences
"databases at can" -> "databases that can"
"in as objects" -> "as objects"
"You select the" -> "Select the"

Aaaand of course I forgot the most important part: hello @agilgur5 and welcome to the project :wave: Thanks a ton for taking the time to fix our docs. Really appreciate that!

Thanks again @agilgur5!
@pavithraes for the future: if there is nothing left other than auto-formatting, it is usually faster to just pull the PR, apply the formatting and push it again instead of waiting yet another round of the review-fix-cycle. If you don't want that, feel free to just comment something along the lines of "please apply the auto formatting so we can merge". No need to flag all instances when CI is doing the same.


Allow interpolation in label/env var names when using dict syntax

Currently, interpolation in label names only works when using the array of strings syntax, i.e. this works:
...
labels:
  - "traefik.http.services.${COMPOSE_PROJECT_NAME}.loadbalancer.server.port=8080"

But this doesn't:
...
labels:
  traefik.http.services.${COMPOSE_PROJECT_NAME}.loadbalancer.server.port: 8080

The spec is kind of vague about whether the second variation should work. It says "Values in a Compose file can be set by variables, and interpolated at runtime". Taken literally, keys to a dictionary aren't quite values. On the other hand, the keys in labels and env variables are used-defined content and not like the "normal" static keys for compose properties either.
Either way, since it is clearly useful to allow this (for labels and env variables at least) and one variation works already, I think it would be good for consistency if the other variation worked as well.

While not explicitly set by the specification, variable substitution only applies to VALUES, not yaml mapping KEYS.
Not doing so would introduce risks for duplicate keys after interpolation, which yaml parser should have detected already.
For environment variables/labels use-cases, the "list of string" syntax offers a pretty reasonable workaround, so the benefit vs risk changing this is pretty low.


Publishing on crates.io

How about we start publishing this library on crates.io? It'd be a lot easier to use this library then, especially when we introduce breaking changes. I understand that we should probably do some more work on documenting it, but aside from that, all of our dependencies are either owned by @NikVolf or are published on crates.io already.
Aside from putting tokio-named-pipes on crates.io and documenting the security attributes properly for both platforms, are there any more tasks that should be done before the crate is published?
If any of the contributors/owners are categorically opposed to this, I'm OK with that as well :slightly_smiling_face:

@NikVolf This crate is already published on crates.io - can this issue be closed now?

This is already published now, so closing


[tests-only] API tests for archiver endpoint

Description
First test to download a file using the archiver endpoint
much more to follow
Related Issue
part of #2510
Motivation and Context
test the archiver endpoint
How Has This Been Tested?
:robot:
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[x] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

@individual-it @phil-davis I don't see it the drone log. Looks like it still needs to be hooked up in the drone definition?

@phil-davis @wkloucek thank you for pointing out the drone issue, I've added the tests to drone now
also I could cut out some unneeded lines 916f0a6
and could add a test for a folder without changing any PHP c97cbf9
please review again


[rom] Reactivate ROM tests with real keys for PROD

Description
Reactivate ROM tests with real keys for the next ROM release, see discussion here: https://github.com/lowRISC/opentitan/pull/17117#issuecomment-1635253025

@timothytrippel @cfrantz

@cfrantz is going to look at enabling //sw/device/silicon_creator/rom/e2e/release:rom_e2e_self_hash_test.

Now that keys are in OTP, we should only need to reactive the ROM self hash test. The other presigned binary test serves no purpose anymore and will be removed.


new commit (added a profile of Priyanshu Indra)

Hi! I am new to this community and this is my first PR. I have added my profile as discussed on the READ.me file.

Looks good 👍 except for the package-lock.json file changes. Please revert.

I don't understand how to solve that, should I update the package ? Can you please help me ??

Looks good 👍 except for the package-lock.json file changes. Please revert.

I don't understand how to solve that, should I update the package ? Can you please help me ??

Just copy the contents from the original file from the original repository, commit, and submit your changes. 🙂


[WIP] History feature on CLI

This PR introduces the foundations of the new History feature.

[x] Create a History store to hold information about recent actions
[x] Add an Interface to navigate between past issues
[x] Preprocess actions to correctly showcase replacements

Hi, sorry for not updating this PR for so long, unfortunately, I won't be able to continue working on this feature, as I'm currently facing tight deadlines and demands both at work and in my studies. So I will have to prioritize those for some time and archive this contribution 😞 Feel free to continue ongoing works if you want or I can close the PR


Vulkan dump resources: Option to dump alpha separately

New option --dump-resources-dump-separate-alpha will force the alpha channel of dumped images to be dumped into a separate file

CI gfxreconstruct build queued with queue ID 308731.

CI gfxreconstruct build # 5376 failed.

CI gfxreconstruct build queued with queue ID 308753.

CI gfxreconstruct build # 5377 running.

CI gfxreconstruct build # 5377 passed.

CI gfxreconstruct build queued with queue ID 309676.

CI gfxreconstruct build # 5388 running.

CI gfxreconstruct build # 5388 passed.

CI gfxreconstruct build queued with queue ID 310069.

CI gfxreconstruct build # 5396 running.

CI gfxreconstruct build queued with queue ID 310963.

CI gfxreconstruct build # 5410 running.

CI gfxreconstruct build # 5410 failed.

CI gfxreconstruct build queued with queue ID 311383.

CI gfxreconstruct build # 5419 running.

CI gfxreconstruct build # 5419 passed.

Works for me :-).
Thanks for updating the attribute names.

CI gfxreconstruct build queued with queue ID 312153.

CI gfxreconstruct build queued with queue ID 312155.

CI gfxreconstruct build # 5441 running.

CI gfxreconstruct build # 5441 passed.


DistanceRGB doesn't use linear RGB

DistanceRGB should use linear RGB, as otherwise the distance doesn't really hold any meaning, because it's measuring a non-linear space.

otherwise the distance doesn't really hold any meaning, because it's measuring a non-linear space.

I don't what the aforementioned code does, but at any rate, conceptually, this is not true at all, the opposite is actually what perceptually uniform spaces strive for: producing meaningful metrics from a human observer standpoint and thus measuring distance. CIE DeltaE 2000 is happening in a highly non-linear CIE Lab space compared to an RGB space but it is a space that is trying to be linear for a human observer. It all depends on what you are trying to achieve here.

otherwise the distance doesn't really hold any meaning, because it's measuring a non-linear space.

I don't what the aforementioned code does, but at any rate, conceptually, this is not true at all, the opposite is actually what perceptually uniform spaces strive for: producing meaningful metrics from a human observer standpoint and thus measuring distance. CIE DeltaE 2000 is happening in a highly non-linear CIE Lab space compared to an RGB space but it is a space that is trying to be linear for a human observer. It all depends on what you are trying to achieve here.

My understanding is that measuring euclidean distance in a non-linear space serves no purpose, and so when you measure euclidean distance in sRGB you aren't measuring anything meaningful. Whereas in linear RGB, the euclidean distance actually represents the distance between each color. What CIE Delta E does is different.

CIE Lab space [...] is a space that is trying to be linear for a human observer

My understanding is that it is actually trying to be linear to machines in a way that matches up with human observations. So if you take euclidean distance in CIELAB, it's supposed to actually match up with how humans perceive the similarity of colors. Of course it turns out they didn't do it perfectly, and had to invent CIE DeltaE to fix that, but that's another story.

My understanding is that measuring euclidean distance in a non-linear space serves no purpose, and so when you measure euclidean distance in sRGB you aren't measuring anything meaningful. Whereas in linear RGB, the euclidean distance actually represents the distance between each color. What CIE Delta E does is different.

CIE Lab space [...] is a space that is trying to be linear for a human observer

My understanding is that it is actually trying to be linear to machines in a way that matches up with human observations. So if you take euclidean distance in CIELAB, it's supposed to actually match up with how humans perceive the similarity of colors. Of course it turns out they didn't do it perfectly, and had to invent CIE DeltaE to fix that, but that's another story.

My understanding is that measuring euclidean distance in a non-linear space serves no purpose

This is correct!

and so when you measure euclidean distance in sRGB you aren't measuring anything meaningful.

This is not correct, the reason being that while non-linearly encoded sRGB is non-linear from a photometric standpoint, it is actually more linear from a human observer standpoint, i.e. from a perceptual standpoint. If you were to compare the sRGB inverse EOTF and CIE L* used by CIE L*a*b*, you would see that while not being the same, they are closer together than a purely linear function.

Everything is a matter of reference point. With that in mind, I'm not saying that you should perform colour differences in non-linearly encoded sRGB space but if your goal is to generate perceptually smoother gradients and such things, it is better than linear sRGB.

My understanding is that measuring euclidean distance in a non-linear space serves no purpose

This is correct!

and so when you measure euclidean distance in sRGB you aren't measuring anything meaningful.

This is not correct, the reason being that while non-linearly encoded sRGB is non-linear from a photometric standpoint, it is actually more linear from a human observer standpoint, i.e. from a perceptual standpoint. If you were to compare the sRGB inverse EOTF and CIE L* used by CIE L*a*b*, you would see that while not being the same, they are closer together than a purely linear function.

Everything is a matter of reference point. With that in mind, I'm not saying that you should perform colour differences in non-linearly encoded sRGB space but if your goal is to generate perceptually smoother gradients and such things, it is better than linear sRGB.

Woah, I didn't realize that. It makes sense though, thanks for explaining.

With that in mind, I'm not saying that you should perform colour differences in non-linearly encoded sRGB space but if your goal is to generate perceptually smoother gradients and such things, it is better than linear sRGB.

I'm trying to do color quantization and dithering, and so I need to find the closest color in the palette to replace the existing one. Obviously there are many ways to do this, with CIEDE2000, etc, but I wanted to do it in RGB for some testing. But it sounds like I should be doing it in sRGB instead of linear RGB.
But wait! This post contradicts you. It shows this image for a dithered gradient in sRGB:

And this for it in linear RGB:

As you can see, and as the post notes, it's only when it's done in linear RGB that it actually looks correct, the sRGB gradient gets light too quickly.
But maybe that's because that dithered gradient is just performing image operations like adding and subtracting color values, and then just being thresholded against a black and white palette? I'm not sure.
Here look, I've done my own tests with color images.
Here is the original peppers image:

Here is it with random noise dithering, using euclidean distance in sRGB. The palette is pure red, pure green, full yellow, and black.

And here it is, using euclidean distance in linear RGB:

Perhaps the colors are better in sRGB, but the dark areas are better in RGB? Overall the linear RGB seems to look better though.
Here's another test. Same original image, but a new palette. I tried to choose this palette based on the colors in the image.
color.RGBA{188, 208, 86, 255}
color.RGBA{199, 58, 41, 255}
color.RGBA{128, 168, 80, 255}
color.Black
color.White

Here's sRGB:

Here's linear RGB:

Here's an APNG that goes between the three - original, then sRGB, then linear RGB. You can see how the linear RGB is darker, and the colors appear less washed out. I think it looks better.

Or maybe linear RGB is just being biased towards pure black, as your graphs shows. More tests then...
Here's the same palette as before, but with no white or black.
sRGB:

Linear RGB:

APNG (original, sRGB, then linear RGB):

Here I think it's actually the sRGB that does better. It keeps the dark areas darker, if you look at the middle green pepper. It's the linear RGB that appears to wash out the image a bit. However the difference is much more slight then previous examples.
I'm not quite sure what to think here. Do you have anymore mathematical insight? Do you agree or disagree about what image looks better? Thanks.

Woah, I didn't realize that. It makes sense though, thanks for explaining.

With that in mind, I'm not saying that you should perform colour differences in non-linearly encoded sRGB space but if your goal is to generate perceptually smoother gradients and such things, it is better than linear sRGB.

I'm trying to do color quantization and dithering, and so I need to find the closest color in the palette to replace the existing one. Obviously there are many ways to do this, with CIEDE2000, etc, but I wanted to do it in RGB for some testing. But it sounds like I should be doing it in sRGB instead of linear RGB.
But wait! This post contradicts you. It shows this image for a dithered gradient in sRGB:

And this for it in linear RGB:

As you can see, and as the post notes, it's only when it's done in linear RGB that it actually looks correct, the sRGB gradient gets light too quickly.
But maybe that's because that dithered gradient is just performing image operations like adding and subtracting color values, and then just being thresholded against a black and white palette? I'm not sure.
Here look, I've done my own tests with color images.
Here is the original peppers image:

Here is it with random noise dithering, using euclidean distance in sRGB. The palette is pure red, pure green, full yellow, and black.

And here it is, using euclidean distance in linear RGB:

Perhaps the colors are better in sRGB, but the dark areas are better in RGB? Overall the linear RGB seems to look better though.
Here's another test. Same original image, but a new palette. I tried to choose this palette based on the colors in the image.
color.RGBA{188, 208, 86, 255}
color.RGBA{199, 58, 41, 255}
color.RGBA{128, 168, 80, 255}
color.Black
color.White

Here's sRGB:

Here's linear RGB:

Here's an APNG that goes between the three - original, then sRGB, then linear RGB. You can see how the linear RGB is darker, and the colors appear less washed out. I think it looks better.

Or maybe linear RGB is just being biased towards pure black, as your graphs shows. More tests then...
Here's the same palette as before, but with no white or black.
sRGB:

Linear RGB:

APNG (original, sRGB, then linear RGB):

Here I think it's actually the sRGB that does better. It keeps the dark areas darker, if you look at the middle green pepper. It's the linear RGB that appears to wash out the image a bit. However the difference is much more slight then previous examples.
I'm not quite sure what to think here. Do you have anymore mathematical insight? Do you agree or disagree about what image looks better? Thanks.

I did another test with a much larger image, using the bayer 3 matrix, with an r value of the max color value (usually 255, but 65535 in Go).
Source image
Downscaled source:

Full scale linear RGB:

Full scale sRGB:

If you flip back and forth between them, it's obvious that the sRGB is better. It's more accurate to the original image, and linear RGB makes everything too dark.
This convinces me that sRGB is better than linear RGB for color images -- as a color distance function, to match image colors to a palette. Note that linear RGB is still used for all image operations, like applying the bayer matrix by adding and subtracting values.

I did another test with a much larger image, using the bayer 3 matrix, with an r value of the max color value (usually 255, but 65535 in Go).
Source image
Downscaled source:

Full scale linear RGB:

Full scale sRGB:

If you flip back and forth between them, it's obvious that the sRGB is better. It's more accurate to the original image, and linear RGB makes everything too dark.
This convinces me that sRGB is better than linear RGB for color images -- as a color distance function, to match image colors to a palette. Note that linear RGB is still used for all image operations, like applying the bayer matrix by adding and subtracting values.

The question that still remains for me is whether linear RGB or sRGB makes sense for grayscale images. Again, not for the actual operations, but for matching to a palette.

The question that still remains for me is whether linear RGB or sRGB makes sense for grayscale images. Again, not for the actual operations, but for matching to a palette.

Black and white palette.
Original image:

Quantized using linear RGB:

Quantized using sRGB:

All together:

From this it seems obvious that using euclidean distance in sRGB is better than linear RGB for finding a closest palette match, even for grayscale images. Keep in mind linear RGB is still required for modification of color values, like adding randomness to an image or something.
So it would go:

Convert from sRGB to linear
Modify color of pixel
Convert back to sRGB
Calculate euclidean distance between the color and the palette colors (palette must be sRGB too)
Set pixel to closest palette color

Sorry for dumping so much in this thread, but I hope it can be hopeful to others too.

Black and white palette.
Original image:

Quantized using linear RGB:

Quantized using sRGB:

All together:

From this it seems obvious that using euclidean distance in sRGB is better than linear RGB for finding a closest palette match, even for grayscale images. Keep in mind linear RGB is still required for modification of color values, like adding randomness to an image or something.
So it would go:

Convert from sRGB to linear
Modify color of pixel
Convert back to sRGB
Calculate euclidean distance between the color and the palette colors (palette must be sRGB too)
Set pixel to closest palette color

Sorry for dumping so much in this thread, but I hope it can be hopeful to others too.

Glad this discussion was helpful!

As you can see, and as the post notes, it's only when it's done in linear RGB that it actually looks correct, the sRGB gradient gets light too quickly.

Looking a both of them while squinting with my eyes to "blur" the signal, none look particularly great :) Which one looks closer to the reference gradient for you?

Glad this discussion was helpful!

As you can see, and as the post notes, it's only when it's done in linear RGB that it actually looks correct, the sRGB gradient gets light too quickly.

Looking a both of them while squinting with my eyes to "blur" the signal, none look particularly great :) Which one looks closer to the reference gradient for you?

Which one looks closer to the reference gradient for you?

Really not that sure, but I believe the second one.

Also, I tried to apply this newfound knowledge to other grayscale images... and it didn't work so well.
Adding randomness in linear RGB, and doing euclidean distance in linear RGB for palette matching:

Adding randomness in linear RGB, and doing euclidean distance in sRGB for palette matching:

Clearly, the sRGB one has issues, it's not even keeping pure black as black. Now, perhaps my code has issues, in which case I'll be embarassed to have drawn this all out. But maybe someone can explain whether what I'm seeing here makes sense or not?
There is one big difference between the color image randomness (the peppers above) and this grayscale randomness. With the color image, a separate random number is being applied to R, G, and B. For the grayscale image, there is only one number, effectively making it "more random". This doesn't explain why it isn't leaving the pure black alone though...

Which one looks closer to the reference gradient for you?

Really not that sure, but I believe the second one.

Also, I tried to apply this newfound knowledge to other grayscale images... and it didn't work so well.
Adding randomness in linear RGB, and doing euclidean distance in linear RGB for palette matching:

Adding randomness in linear RGB, and doing euclidean distance in sRGB for palette matching:

Clearly, the sRGB one has issues, it's not even keeping pure black as black. Now, perhaps my code has issues, in which case I'll be embarassed to have drawn this all out. But maybe someone can explain whether what I'm seeing here makes sense or not?
There is one big difference between the color image randomness (the peppers above) and this grayscale randomness. With the color image, a separate random number is being applied to R, G, and B. For the grayscale image, there is only one number, effectively making it "more random". This doesn't explain why it isn't leaving the pure black alone though...

If it helps, I'll explain a bit more. Sorry about how far off track I've gotten, but I'd appreciate any help.
Obviously, the second image above is some sort of error. These are the steps I followed, which I described earlier:

Convert from sRGB to linear
Modify color of pixel
Convert back to sRGB
Calculate euclidean distance between the color and the palette colors (palette must be sRGB too)
Set pixel to closest palette color

These steps are causing the issue. Mathematically I can see why this happening. For example, let's take the pure black at the left side of the gradient, with its value of 0. When linearized, it's still 0. Now a random number is added to it, from -0.5 to 0.5. Let's say it's 0.5. Now the final linear color is 0.5, and it needs to be converted to sRGB. Converting to sRGB roughly gives us 0.7353569831, which will be quantized to pure white. This explains why the gradient looks so wrong up there, because converting to sRGB is increasing numbers dramatically.
So when I remove that third step from the code, and don't convert back to sRGB, the gradient looks fine. So it seems I have a solution, but I'm very confused as to why that's the case. I've put it in linear RGB, why do not I need to convert it back to sRGB? Wikipedia seems to suggest you would need to, but my code does not.
Thanks.

If it helps, I'll explain a bit more. Sorry about how far off track I've gotten, but I'd appreciate any help.
Obviously, the second image above is some sort of error. These are the steps I followed, which I described earlier:

Convert from sRGB to linear
Modify color of pixel
Convert back to sRGB
Calculate euclidean distance between the color and the palette colors (palette must be sRGB too)
Set pixel to closest palette color

These steps are causing the issue. Mathematically I can see why this happening. For example, let's take the pure black at the left side of the gradient, with its value of 0. When linearized, it's still 0. Now a random number is added to it, from -0.5 to 0.5. Let's say it's 0.5. Now the final linear color is 0.5, and it needs to be converted to sRGB. Converting to sRGB roughly gives us 0.7353569831, which will be quantized to pure white. This explains why the gradient looks so wrong up there, because converting to sRGB is increasing numbers dramatically.
So when I remove that third step from the code, and don't convert back to sRGB, the gradient looks fine. So it seems I have a solution, but I'm very confused as to why that's the case. I've put it in linear RGB, why do not I need to convert it back to sRGB? Wikipedia seems to suggest you would need to, but my code does not.
Thanks.

I've discovered that if I linearize the max random value (0.5 becomes 0.2140411405) and delinearize the min random value (-0.5 becomes -0.7353569831) then the gradient is correct when I convert back to sRGB. I'm totally confused why this works, and would appreciate any insight.

I've discovered that if I linearize the max random value (0.5 becomes 0.2140411405) and delinearize the min random value (-0.5 becomes -0.7353569831) then the gradient is correct when I convert back to sRGB. I'm totally confused why this works, and would appreciate any insight.

@KelSolaar @sobotka sorry for the tag, but I'm stumped.

@KelSolaar @sobotka sorry for the tag, but I'm stumped.

I’m not sure what exactly is stumping you here, as it is unclear over the past few posts.
Thomas has followed along, and his advice is more solid than 99.95% of what you’ll find online.
My sole thought is that dithering in RGB is ultimately radiometric-like in nature, assuming one can get the plot right. If it works at the pixel level, it should also scale appropriately spatially, but perhaps I am missing something? Are your linear RGB calculations properly taking into account the spatial area?

I’m not sure what exactly is stumping you here, as it is unclear over the past few posts.
Thomas has followed along, and his advice is more solid than 99.95% of what you’ll find online.
My sole thought is that dithering in RGB is ultimately radiometric-like in nature, assuming one can get the plot right. If it works at the pixel level, it should also scale appropriately spatially, but perhaps I am missing something? Are your linear RGB calculations properly taking into account the spatial area?

@sobotka Sorry, I've been figuring things out a bit publicly, I understand why it's confusing.
What's stumping at this point is why using euclidean distance in sRGB seems to work well for color images (this comment), and worked for grayscale quantization as I showed in this comment, but failed when using random dithering, as I showed in this comment. Why is euclidean distance in sRGB not working in that case?

Are your linear RGB calculations properly taking into account the spatial area?

I'm not really sure how one would do this, I would appreciate more info. sRGB is being converted to linear RGB like this:
func linearize(v float64) float64 {
	if v <= 0.04045 {
		return v / 12.92
	}
	return math.Pow((v+0.055)/1.055, 2.4)
}

I'm then doing an operation with the output, like adding or subtracting. Then I'm converting back to sRGB:
func delinearize(v float64) float64 {
	if v <= 0.0031308 {
		return 12.92 * v
	}
	return 1.055*math.Pow(v, 1.0/2.4) - 0.055
}

For the grayscale images the RGB is converted into a single linear grayscale number, right after the conversion to linear RGB.
This is all defined by Wikipedia here.

As for negatives, they are completely bunko regarding light emissions; even black holes would be zero reflectance, not negative. Granted, I haven’t been to a black hole...

The negatives I was talking about were for the range of random values for dithering. So a random value between -x and x would be added to the linear grayscale value, before converting back to sRGB.
Thanks for the help.

@sobotka Sorry, I've been figuring things out a bit publicly, I understand why it's confusing.
What's stumping at this point is why using euclidean distance in sRGB seems to work well for color images (this comment), and worked for grayscale quantization as I showed in this comment, but failed when using random dithering, as I showed in this comment. Why is euclidean distance in sRGB not working in that case?

Are your linear RGB calculations properly taking into account the spatial area?

I'm not really sure how one would do this, I would appreciate more info. sRGB is being converted to linear RGB like this:
func linearize(v float64) float64 {
	if v <= 0.04045 {
		return v / 12.92
	}
	return math.Pow((v+0.055)/1.055, 2.4)
}

I'm then doing an operation with the output, like adding or subtracting. Then I'm converting back to sRGB:
func delinearize(v float64) float64 {
	if v <= 0.0031308 {
		return 12.92 * v
	}
	return 1.055*math.Pow(v, 1.0/2.4) - 0.055
}

For the grayscale images the RGB is converted into a single linear grayscale number, right after the conversion to linear RGB.
This is all defined by Wikipedia here.

As for negatives, they are completely bunko regarding light emissions; even black holes would be zero reflectance, not negative. Granted, I haven’t been to a black hole...

The negatives I was talking about were for the range of random values for dithering. So a random value between -x and x would be added to the linear grayscale value, before converting back to sRGB.
Thanks for the help.

distance in sRGB seems to work well for color images

I don’t see anything “working well” there. Reduce your cases to less complex entry points? Can you demonstrate with two pixels, expanded, for example? Four? Etc.

and worked for grayscale quantization as I showed in this comment,

Quantisation is about an input and an output, and I’m not sure you’ve clearly identified your input X axis and your output Y axis clearly enough here. Certainly not clearly enough for me. It also might help to outline what exactly one’s expectation or “hope” is here.

I'm not really sure how one would do this, I would appreciate more info.

Think about a simple case of four pixels. Two diagonal pixels are off, at zero emission. The other two are set to full emission. What is the net sum relationship of the four pixels with respect to overall emission? Those sorts of questions are extremely relevant when discussing dithering; we can think of that staccato pattern as being a dither of a specific value. What is it? What is the interaction when we change that target value?

The negatives I was talking about were for the range of random values for dithering. So a random value between -x and x would be added to the linear grayscale value, before converting back to sRGB.

What does a negative sum end up meaning? Don’t get stuck in the math. Focus on the display hardware first, and work backwards, perhaps?

distance in sRGB seems to work well for color images

I don’t see anything “working well” there. Reduce your cases to less complex entry points? Can you demonstrate with two pixels, expanded, for example? Four? Etc.

and worked for grayscale quantization as I showed in this comment,

Quantisation is about an input and an output, and I’m not sure you’ve clearly identified your input X axis and your output Y axis clearly enough here. Certainly not clearly enough for me. It also might help to outline what exactly one’s expectation or “hope” is here.

I'm not really sure how one would do this, I would appreciate more info.

Think about a simple case of four pixels. Two diagonal pixels are off, at zero emission. The other two are set to full emission. What is the net sum relationship of the four pixels with respect to overall emission? Those sorts of questions are extremely relevant when discussing dithering; we can think of that staccato pattern as being a dither of a specific value. What is it? What is the interaction when we change that target value?

The negatives I was talking about were for the range of random values for dithering. So a random value between -x and x would be added to the linear grayscale value, before converting back to sRGB.

What does a negative sum end up meaning? Don’t get stuck in the math. Focus on the display hardware first, and work backwards, perhaps?

@sobotka

I don’t see anything “working well” there.

For the color images, when I matched to the palette using euclidean distance in sRGB vs linear RGB, the sRGB output appeared to match the original better. My understanding is that this is proven by the graph Thomas sent here.

It also might help to outline what exactly one’s expectation or “hope” is here.

My hope for grayscale quantization is that all the pixels in the image that are darker than the middle point become black, and all the pixels that are lighter than that middle point become white. That middle point would be what humans perceive as the middle between completely dark (black) and completely light (white).
Instead of simply thresholding a value, I'm trying to use euclidean distance to do this, so that the algorithm works well for palettes with more than just two colors.
Now the question remains as to what that middle point is, and what color space for euclidean distance will create the most accurate results. Using linear RGB will result in 0.7353569831 being considered the middle point, while sRGB will result in 0.5 being considered the middle point. But using sRGB also seems to have other issues as I described here.

Think about a simple case of four pixels. Two diagonal pixels are off, at zero emission. The other two are set to full emission. What is the net sum relationship of the four pixels with respect to overall emission?

In none of my examples have I had to sum any pixel values together. All my operations have applied to each pixel independently. I have talked about quantization and random dithering so far, and for both of them the example pixels you describe would remain the same, assuming the palette used contains a full emission and zero emission "color".

The negatives I was talking about were for the range of random values for dithering. So a random value between -x and x would be added to the linear grayscale value, before converting back to sRGB.

What does a negative sum end up meaning? Don’t get stuck in the math. Focus on the display hardware first, and work backwards, perhaps?

You're asking what would happen if a negative number was added to a linear grayscale value, resulting in a negative sum? That would be clamped to 0. I'm not sure what you mean by focusing on the display hardware, how should I go about that?
I hope that clears some things up, thanks for taking the time.

@sobotka

I don’t see anything “working well” there.

For the color images, when I matched to the palette using euclidean distance in sRGB vs linear RGB, the sRGB output appeared to match the original better. My understanding is that this is proven by the graph Thomas sent here.

It also might help to outline what exactly one’s expectation or “hope” is here.

My hope for grayscale quantization is that all the pixels in the image that are darker than the middle point become black, and all the pixels that are lighter than that middle point become white. That middle point would be what humans perceive as the middle between completely dark (black) and completely light (white).
Instead of simply thresholding a value, I'm trying to use euclidean distance to do this, so that the algorithm works well for palettes with more than just two colors.
Now the question remains as to what that middle point is, and what color space for euclidean distance will create the most accurate results. Using linear RGB will result in 0.7353569831 being considered the middle point, while sRGB will result in 0.5 being considered the middle point. But using sRGB also seems to have other issues as I described here.

Think about a simple case of four pixels. Two diagonal pixels are off, at zero emission. The other two are set to full emission. What is the net sum relationship of the four pixels with respect to overall emission?

In none of my examples have I had to sum any pixel values together. All my operations have applied to each pixel independently. I have talked about quantization and random dithering so far, and for both of them the example pixels you describe would remain the same, assuming the palette used contains a full emission and zero emission "color".

The negatives I was talking about were for the range of random values for dithering. So a random value between -x and x would be added to the linear grayscale value, before converting back to sRGB.

What does a negative sum end up meaning? Don’t get stuck in the math. Focus on the display hardware first, and work backwards, perhaps?

You're asking what would happen if a negative number was added to a linear grayscale value, resulting in a negative sum? That would be clamped to 0. I'm not sure what you mean by focusing on the display hardware, how should I go about that?
I hope that clears some things up, thanks for taking the time.

Now the question remains as to what that middle point is

Reading this Wikipedia article has helped me understand the different possible middle values more:

When I look back at this comment, it's obvious that using sRGB for palette matching is leading to a middle value of 128 (or 127) as the table above shows. And using linear RGB is equivalent to the "Absolute whiteness" middle (note the 1.0 gamma value), which is 188.
If we consider 50% CIELAB brightness to be the correct human perception middle gray, then it's obvious that sRGB should be used to palette match over linear RGB, as the middle gray of sRGB is much closer to CIELAB.
But as I figured out in this comment and the one below, it's adding randomness that's the problem. Adding a random number from -0.5 to 0.5 to every pixel results in the image becoming way too bright, because the 0.5 value represents the middle in linear RGB, not sRGB. Now it would be nice if the random number could just be added to the sRGB value directly, but my understanding is that that would produce inaccurate results because of its non-linearity.
So instead I tried to offset the brightness bias, as I described here:

I've discovered that if I linearize the max random value (0.5 becomes 0.2140411405) and delinearize the min random value (-0.5 becomes -0.7353569831) then the gradient is correct when I convert back to sRGB.

This worked for the random dithering, producing a correct-looking gradient like this:

But then I wondered, can I generalize this to other types of dithering like Bayer? So I started using this algorithm:
func fixLinearValue(v float32) float32 {
	if v < 0 {
		return -delinearize(-v)
	}
	return linearize(v)
}

And here's the output with a bayer level 3 matrix.
With linear RGB palette matching:

With non-fixed sRGB palette matching - note how it's too bright:

With fixed sRGB palette matching:

Original gradient for reference:

While the fixed sRGB gradient isn't that smooth, the colors seem much more accurate. The linear RGB gets too dark, too fast. All of this can be seen more obviously when the gradients are scaled down:
Original gradient:

Linear RGB:

Fixed sRGB:

I'm sorry, I know I'm basically writing a blog post at this point. And I plan to turn this into one! I guess I've been putting stuff here as a sanity check, because I'm new to color theory, and I want to make sure I'm not totally off base with this. So does what I'm doing make sense? Have I discovered something new, or has this been written about before? Thank you.

Now the question remains as to what that middle point is

Reading this Wikipedia article has helped me understand the different possible middle values more:

When I look back at this comment, it's obvious that using sRGB for palette matching is leading to a middle value of 128 (or 127) as the table above shows. And using linear RGB is equivalent to the "Absolute whiteness" middle (note the 1.0 gamma value), which is 188.
If we consider 50% CIELAB brightness to be the correct human perception middle gray, then it's obvious that sRGB should be used to palette match over linear RGB, as the middle gray of sRGB is much closer to CIELAB.
But as I figured out in this comment and the one below, it's adding randomness that's the problem. Adding a random number from -0.5 to 0.5 to every pixel results in the image becoming way too bright, because the 0.5 value represents the middle in linear RGB, not sRGB. Now it would be nice if the random number could just be added to the sRGB value directly, but my understanding is that that would produce inaccurate results because of its non-linearity.
So instead I tried to offset the brightness bias, as I described here:

I've discovered that if I linearize the max random value (0.5 becomes 0.2140411405) and delinearize the min random value (-0.5 becomes -0.7353569831) then the gradient is correct when I convert back to sRGB.

This worked for the random dithering, producing a correct-looking gradient like this:

But then I wondered, can I generalize this to other types of dithering like Bayer? So I started using this algorithm:
func fixLinearValue(v float32) float32 {
	if v < 0 {
		return -delinearize(-v)
	}
	return linearize(v)
}

And here's the output with a bayer level 3 matrix.
With linear RGB palette matching:

With non-fixed sRGB palette matching - note how it's too bright:

With fixed sRGB palette matching:

Original gradient for reference:

While the fixed sRGB gradient isn't that smooth, the colors seem much more accurate. The linear RGB gets too dark, too fast. All of this can be seen more obviously when the gradients are scaled down:
Original gradient:

Linear RGB:

Fixed sRGB:

I'm sorry, I know I'm basically writing a blog post at this point. And I plan to turn this into one! I guess I've been putting stuff here as a sanity check, because I'm new to color theory, and I want to make sure I'm not totally off base with this. So does what I'm doing make sense? Have I discovered something new, or has this been written about before? Thank you.

I haven't touched on error diffusion dithering yet. None of this fixing can really be applied to that, I couldn't find a way that works, likely because the error diffusion matrices are designed in a specific way, rather than it being a random number.

I haven't touched on error diffusion dithering yet. None of this fixing can really be applied to that, I couldn't find a way that works, likely because the error diffusion matrices are designed in a specific way, rather than it being a random number.

After testing with CIE Delta E for palette matching as well, it appears like the general algorithm for fixing a value (called i) is as follows. Note that i represents a positive or negative number being added to a linear RGB value during a dithering operation.
Interpret i as if it's a brightness/grayscale value in the palette matching color space. Then convert that color into CIEXYZ, and get the luminance value by taking just the Y. If i is positive, return Y. If i is negative, return Y-1.
For example, if the palette matching color space is sRGB, treat i as an sRGB color of the form (i, i, i). Then convert that to CIEXYZ, etc. Or if the palette matching color space is CIELAB, treat i as the L, and the a and b as 0.
For CIE Delta E, I pretended the palette matching color space was CIELAB, as that's the closest approximation. I'm not sure how to go about getting more accurate than that.
The purpose of this fixing is to allow dithering operations to be independent of the palette matching algorithm. Applying random numbers and bayer matrices only works in linear RGB, but when the result is converted to another color space to try and find the closest palette color, it becomes too bright, because the linear RGB middle gray is higher than other color spaces (and not relevant to human vision). I believe the algorithm I described above will correct for this brightness increase. Does it make sense?

After testing with CIE Delta E for palette matching as well, it appears like the general algorithm for fixing a value (called i) is as follows. Note that i represents a positive or negative number being added to a linear RGB value during a dithering operation.
Interpret i as if it's a brightness/grayscale value in the palette matching color space. Then convert that color into CIEXYZ, and get the luminance value by taking just the Y. If i is positive, return Y. If i is negative, return Y-1.
For example, if the palette matching color space is sRGB, treat i as an sRGB color of the form (i, i, i). Then convert that to CIEXYZ, etc. Or if the palette matching color space is CIELAB, treat i as the L, and the a and b as 0.
For CIE Delta E, I pretended the palette matching color space was CIELAB, as that's the closest approximation. I'm not sure how to go about getting more accurate than that.
The purpose of this fixing is to allow dithering operations to be independent of the palette matching algorithm. Applying random numbers and bayer matrices only works in linear RGB, but when the result is converted to another color space to try and find the closest palette color, it becomes too bright, because the linear RGB middle gray is higher than other color spaces (and not relevant to human vision). I believe the algorithm I described above will correct for this brightness increase. Does it make sense?

It really feels like over complication here before the basics are well covered?
Given four pixels in a 2x2 array, how to dither the increments? What is the ground truth?

It really feels like over complication here before the basics are well covered?
Given four pixels in a 2x2 array, how to dither the increments? What is the ground truth?

I understand I wrote a lot, but did you read any of it?

Given four pixels in a 2x2 array, how to dither the increments? What is the ground truth?

I'm not sure what ground truth means. Depending on what method is being used, different modifications will be made to those four pixels, in linear RGB space, and then the final clamped value of each one will changed to a palette color, using another algorithm.
So for example, if random dithering is used, for each pixel, a random number between the defined min and max will be picked and added to the pixel's color value. Then the resulting color will be corrected to the nearest palette color.
This thread originally started by talking about whether using euclidean distance in sRGB or linear RGB was better for finding the nearest color. But in my most recent comments, I've been trying to find out what the best min and max value are instead. If we want the middle gray to be 50% black and 50% white (for a black and white palette), then how do we modify the inuitive min and max values of -0.5 and 0.5 to work around the middle gray of the color distance algorithm? That's what I've described above in earlier comments.

I understand I wrote a lot, but did you read any of it?

Given four pixels in a 2x2 array, how to dither the increments? What is the ground truth?

I'm not sure what ground truth means. Depending on what method is being used, different modifications will be made to those four pixels, in linear RGB space, and then the final clamped value of each one will changed to a palette color, using another algorithm.
So for example, if random dithering is used, for each pixel, a random number between the defined min and max will be picked and added to the pixel's color value. Then the resulting color will be corrected to the nearest palette color.
This thread originally started by talking about whether using euclidean distance in sRGB or linear RGB was better for finding the nearest color. But in my most recent comments, I've been trying to find out what the best min and max value are instead. If we want the middle gray to be 50% black and 50% white (for a black and white palette), then how do we modify the inuitive min and max values of -0.5 and 0.5 to work around the middle gray of the color distance algorithm? That's what I've described above in earlier comments.

There is only one ground truth. Again, think about two pixels at 100% and two at 0%. What does the percentage represent?
That answer might bring some clarity as to appropriate math and appropriate models?

There is only one ground truth. Again, think about two pixels at 100% and two at 0%. What does the percentage represent?
That answer might bring some clarity as to appropriate math and appropriate models?

There is only one ground truth.

I don't understand the term "ground truth" in this context. Could you explain it?

Again, think about two pixels at 100% and two at 0%. What does the percentage represent?

In my case, the linear RGB grayscale value. Often this would translated as (0, 0, 0) and (255, 255, 255).

the “dithered” result

If the palette contains the "colors" of 100% and 0%, then the dithering won't do anything, the result will be the same.

There is only one ground truth.

I don't understand the term "ground truth" in this context. Could you explain it?

Again, think about two pixels at 100% and two at 0%. What does the percentage represent?

In my case, the linear RGB grayscale value. Often this would translated as (0, 0, 0) and (255, 255, 255).

the “dithered” result

If the palette contains the "colors" of 100% and 0%, then the dithering won't do anything, the result will be the same.

What does 100% mean?

What does 100% mean?

It means the brightest possible color the hardware and software can accommodate. In my code I am limited to describing it as (255, 255, 255) and calling it a day.

It means the brightest possible color the hardware and software can accommodate. In my code I am limited to describing it as (255, 255, 255) and calling it a day.

So if it is a percentage of display emission, you should be able to dither those 2x2 pixels to any step increment using spatial increments, correct?
And if you were to try that, what is the sole model that delivers the proper emission levels?

So if it is a percentage of display emission, you should be able to dither those 2x2 pixels to any step increment using spatial increments, correct?
And if you were to try that, what is the sole model that delivers the proper emission levels?

I believe so.
If I'm trying to match display emission, I guess the correct model for the dithering incrementation would be sRGB, because that's the usual display emission model? I thought that because it's non-linear you shouldn't really do operations in that space. Would be interested in hearing whether that's incorrect.

I believe so.
If I'm trying to match display emission, I guess the correct model for the dithering incrementation would be sRGB, because that's the usual display emission model? I thought that because it's non-linear you shouldn't really do operations in that space. Would be interested in hearing whether that's incorrect.

It is all relative to display linear emissions. The encoding variation might be useful to work backwards, but ultimately it is all light emission directly relative to the display, and it can be considered a mostly physical problem.

It is all relative to display linear emissions. The encoding variation might be useful to work backwards, but ultimately it is all light emission directly relative to the display, and it can be considered a mostly physical problem.

So what does that mean for the questions that began up here?

So what does that mean for the questions that began up here?

I think I've gotten very confused because Firefox (my main browser) is displaying these images differently than Chromium, and Firefox is likely getting it wrong. So maybe the gradients I thought were bad are actually good, etc.
If anyone knows about this, I'd appreciate if they could take a look at this question I filed: https://superuser.com/questions/1620043/why-does-this-png-display-differently-in-firefox-vs-chrome

I think I've gotten very confused because Firefox (my main browser) is displaying these images differently than Chromium, and Firefox is likely getting it wrong. So maybe the gradients I thought were bad are actually good, etc.
If anyone knows about this, I'd appreciate if they could take a look at this question I filed: https://superuser.com/questions/1620043/why-does-this-png-display-differently-in-firefox-vs-chrome

I'm sorry for wasting everyone's time. Due to an issue with my Firefox configuration, I wasn't seeing these images at 100%, which distorted their brightness, and led me to all kinds of crazy conclusions, trying to solve the problems I created. Pretty much all the conclusions I've made in this thread have been false or misguided.
However, I remain unconvinced that sRGB is better than linear RGB for dithering. When I take a look back at this comment, now that I can actually see the images properly, linear RGB looks better every time.
@KelSolaar mentioned in response to that comment:

Looking a both of them [the dithered gradients] while squinting with my eyes to "blur" the signal, none look particularly great :) Which one looks closer to the reference gradient for you?

The second one now very clearly looks better to me. Here they are again for reference:
Dithered gradient in sRGB:

Linear RGB:

Source for those images: https://surma.dev/things/ditherpunk/

I'm sorry for wasting everyone's time. Due to an issue with my Firefox configuration, I wasn't seeing these images at 100%, which distorted their brightness, and led me to all kinds of crazy conclusions, trying to solve the problems I created. Pretty much all the conclusions I've made in this thread have been false or misguided.
However, I remain unconvinced that sRGB is better than linear RGB for dithering. When I take a look back at this comment, now that I can actually see the images properly, linear RGB looks better every time.
@KelSolaar mentioned in response to that comment:

Looking a both of them [the dithered gradients] while squinting with my eyes to "blur" the signal, none look particularly great :) Which one looks closer to the reference gradient for you?

The second one now very clearly looks better to me. Here they are again for reference:
Dithered gradient in sRGB:

Linear RGB:

Source for those images: https://surma.dev/things/ditherpunk/

Did it occurred to you that your preference WRT matching could be a display calibration issue?
Here is a gamma test: Generate a series of x10 96x96 checkerboard of decreasing luminance, each of them have the light colour halved from the previous one. Center those checkerboards against a 192x192 constant background with half the luminance of their respective checkerboard.
Encode that image with sRGB EOTF-1, then display it at 100%, if your display gamma is correct you should not see the checkerboards when slightly squinting, alternatively, test a Gamma 2.2 encoding. If none works, then your display is off chart!
The takeaway is that 1) it is important to make sure that your display is calibrated, 2) as you remove values, you remove the total energy arriving to your eyes so you need to increase luminance to make things appear similar.

Did it occurred to you that your preference WRT matching could be a display calibration issue?
Here is a gamma test: Generate a series of x10 96x96 checkerboard of decreasing luminance, each of them have the light colour halved from the previous one. Center those checkerboards against a 192x192 constant background with half the luminance of their respective checkerboard.
Encode that image with sRGB EOTF-1, then display it at 100%, if your display gamma is correct you should not see the checkerboards when slightly squinting, alternatively, test a Gamma 2.2 encoding. If none works, then your display is off chart!
The takeaway is that 1) it is important to make sure that your display is calibrated, 2) as you remove values, you remove the total energy arriving to your eyes so you need to increase luminance to make things appear similar.

you remove the total energy arriving to your eyes so you need to increase luminance to make things appear similar.

I would add that what Thomas has said here as perceptual facet of “luminance” is also purely calculated from emission level; it is a direct spatial to emission value.

you remove the total energy arriving to your eyes so you need to increase luminance to make things appear similar.

I would add that what Thomas has said here as perceptual facet of “luminance” is also purely calculated from emission level; it is a direct spatial to emission value.

The second one now very clearly looks better to me. Here they are again for reference:

Looking at it on a display at 100%, I concur!
I attached the two aforementioned charts:

The second one now very clearly looks better to me. Here they are again for reference:

Looking at it on a display at 100%, I concur!
I attached the two aforementioned charts:

The second one now very clearly looks better to me. Here they are again for reference:

Looking at it on a display at 100%, I concur!

@KelSolaar Glad to hear it! And thanks for the charts.
If the second one is better, wouldn't that suggest that using linear RGB distance for dithering makes more sense? When you look at the color images (at 100%) in this comment it looks like linear RGB is better for those too. I ask this because one of your earlier comments up here suggested that sRGB distance was better for human perception, but these images appear to contradict that.

The second one now very clearly looks better to me. Here they are again for reference:

Looking at it on a display at 100%, I concur!

@KelSolaar Glad to hear it! And thanks for the charts.
If the second one is better, wouldn't that suggest that using linear RGB distance for dithering makes more sense? When you look at the color images (at 100%) in this comment it looks like linear RGB is better for those too. I ask this because one of your earlier comments up here suggested that sRGB distance was better for human perception, but these images appear to contradict that.

I ask this because one of your earlier comments up here suggested that sRGB distance was better for human perception, but these images appear to contradict that.

This comment was made in reference to your the OP.
The problem in the dithering case is different though. You can factor out the observer because what you are interested in here is basically energy conservation . The idea being that for a given pool of radiant power emitters, if you remove a certain numbers of them, by how much the radiant power of the remaining ones must be increased to be the same than that of the full pool. It is really a ratio and doing those operations in a linear space is totally appropriate!

I ask this because one of your earlier comments up here suggested that sRGB distance was better for human perception, but these images appear to contradict that.

This comment was made in reference to your the OP.
The problem in the dithering case is different though. You can factor out the observer because what you are interested in here is basically energy conservation . The idea being that for a given pool of radiant power emitters, if you remove a certain numbers of them, by how much the radiant power of the remaining ones must be increased to be the same than that of the full pool. It is really a ratio and doing those operations in a linear space is totally appropriate!

That's very interesting, I hadn't thought of it in terms of energy conservation. Thanks! I will stick to linear RGB from now on.
I suppose that answers any questions about doing dithering in other color spaces like CIELAB. Because those color spaces are not linear in terms of radiant power. Right?

That's very interesting, I hadn't thought of it in terms of energy conservation. Thanks! I will stick to linear RGB from now on.
I suppose that answers any questions about doing dithering in other color spaces like CIELAB. Because those color spaces are not linear in terms of radiant power. Right?

Yes, they all model our perceptual response to luminance, so they would not be great for operations where you must manipulate energy quantities. A typical example is rendering, solving the rendering equation must be done in a linear space, especially with indirect rendering where you simulate light bouncing in a scene.

Yes, they all model our perceptual response to luminance, so they would not be great for operations where you must manipulate energy quantities. A typical example is rendering, solving the rendering equation must be done in a linear space, especially with indirect rendering where you simulate light bouncing in a scene.

Closing this, now that everything is wrapped up. Thanks again for all the help, and sorry for the confusion.

Closing this, now that everything is wrapped up. Thanks again for all the help, and sorry for the confusion.


Cannot add "incoming webhook" connector - no results from search

The Add an incoming webhook to a Teams channel section says:

Choose Connectors from the drop-down menu and search for Incoming Webhook.

But when I do that, I get...

No results for 'Incoming Webhook'

...so I cannot continue with step 3.

It seems that there is no such connector type any more? Or maybe I don't have permission to add such a Connector, in which case it would be helpful if the documentation or the product could tell me that and point me in the right direction to get that permission issue resolved?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 90ff2a84-a8bc-9259-d37d-622b102df75b
Version Independent ID: e3b53e27-2946-189c-623b-9df704ea8f12
Content: Post external requests to Microsoft Teams with incoming webhooks - Teams
Content Source: msteams-platform/webhooks-and-connectors/how-to/add-incoming-webhook.md
Product: msteams
GitHub Login: @laujan
Microsoft Alias: laujan

@daybarr Could you please check if your tenant administrator turned off access to external applications?

Please re-open if you are still facing the issue.

I also receive this on a brand new dev tenant with no restrictions on the app permission policy.