feat: Cairo-VM Book Architecture

@enitrat  issue to design the skeleton of the Cairo-VM Book

@malatrax can you share here?

Glad to take part on this issue

@zmalatrax  do you want to add the skeleton here (as you are the one who designed it) or do you want me to do it?

Sure, here is the skeleton, it should be in the right format for mdbook:
Do you want me to open a PR or I let you handle it ? @TAdev0
# Cairo VM

[Introduction]()

[Architecture]()

- [Memory]()
  - [Non-Deterministic Read-only Memory]()
  - [Segments]()
  - [Segment Value]()
  - [Relocation]()
  - [Layout]()

- [Execution Model]()
  - [Registers]()
  - [Instructions]()
  - [Cairo Assembly]()
  - [State transition]()

- [Builtins]()
  - [Memory Communication]()
  - [List of Builtins]()

- [Hints]()
  - [Structure]()
  - [Hint runner]()
  - [List of hints]()

- [Runner]()
  - [Program]()
    - [Program Artifacts]()
    - [Program Parsing]()
  - [Runner Mode]()
    - [Proof Mode]()
  - [Output]()
    - [Cairo PIE]()
    - [Memory File]()
    - [Trace file]()
    - [AIR public input]()
    - [AIR private input]()

[Tracer]()

[Implementations]()

[Resources]()

Looks good! @zmalatrax you can open a PR

can i join in on the fun here too?
@TAdev0 @enitrat


Clarify the Medplum Project Model

This PR sets up a dedicated page to describe the Medplum project model, including the purpose of Projects, project level settings.
It also clarifies the purpose of the super admin project
Part of the fix for #2423.

coverage: 93.86% (-0.004%) from 93.864% when pulling df18072398dd3e0d66e9fc0830a98af24a833ceb on clarify-project-model into bc2d910563d8358f8a1f04fd103efe0777a34f86 on main.


Refactored boilerplate readme

Description
Refactored boilerplate readme for better understanding
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] Performed a self-review of my own code
[x] API Documentation in code was updated

Thanks for fixing the documentation 🙏🏻.
This PR is merged now. 🚀


JSDoc and TypeScript IntelliSense support for @link inline tag

Use JSDoc: {@link} defines the @link, @linkplain and @linkcode tags in JavaScript and TypeScript JSDoc-style documentation comments.
As can be seen in the screenshot below the IntelliSense tooltip does not recognize the presence of the @link tag correctly.

The following describes how the different usages of @link should be rendered:

{@link https://github.com/Microsoft/vscode}
https://github.com/Microsoft/vscode
[Microsoft/vscode]{@link https://github.com/Microsoft/vscode}
Microsoft/vscode
{@link https://github.com/Microsoft/vscode|Microsoft/vscode}
Microsoft/vscode
{@link https://github.com/Microsoft/vscode Microsoft/vscode}
Microsoft/vscode

Thus the following example from Use JSDoc: {@link}#Examples
/**
 * See {@link MyClass} and [MyClass's foo property]{@link MyClass#foo}.
 * Also, check out {@link http://www.google.com|Google} and
 * {@link https://github.com GitHub}.
 */

should render in the VS Code Intellisense tootip as:

See MyClass and MyClass's foo property. Also, check out Google and GitHub

Using the @linkplain tag instead of @link should suppress link colouring and make the link text appear as normal text.
Using the @linkcode tag instead of @link should make the link appear in a monospace font (as if the entire Link was wrapped inside an HTML  tag.
Use JSDoc: {@link} also states that the link target can be a namepath instead of a URL. Ideally, IntelliSense should suggest all known symbols in the current scope when writing the @link tag. When written, the namepath should support go-to-definition and find-all-references behaviour.

Duplicate of https://github.com/Microsoft/TypeScript/issues/16498


Decouple dmf_control_board plugin (Trac #89)

Rather than being a special case, the dmf_control_board should be decoupled from the microdrop application to behave like any other plugin. This would give us the option to use different versions of the dmf_control_board which could correspond, for example, to different hardware devices.
Perhaps it is worth writing a plugin interface for communicating with dmf_control_board objects?
Migrated from http://microfluidics.utoronto.ca/microdrop/ticket/89
{
    "status": "closed",
    "changetime": "2014-04-17T19:39:01",
    "description": "Rather than being a special case, the dmf_control_board should be decoupled from the microdrop application to behave like any other plugin. This would give us the option to use different versions of the dmf_control_board which could correspond, for example, to different hardware devices.\n\nPerhaps it is worth writing a plugin interface for communicating with dmf_control_board objects?",
    "reporter": "ryan",
    "cc": "",
    "resolution": "fixed",
    "_ts": "1397763541728826",
    "component": "microdrop",
    "summary": "Decouple dmf_control_board plugin",
    "priority": "major",
    "keywords": "",
    "version": "0.1",
    "time": "2012-04-02T16:32:50",
    "milestone": "Microdrop 1.0",
    "owner": "cfobel",
    "type": "task"
}

Trac update at 20120403T15:16:31:

ryan changed owner from "ryan" to "cfobel"
ryan changed status from "new" to "assigned"

Trac update at 20120407T05:21:07<EMAIL_ADDRESS>commented:

commit 65de479d0730698c02d58d2aa487aa9bd8cb0c35
Author: Christian Fobel<EMAIL_ADDRESS>Date:   Sat Apr 7 01:00:30 2012 -0400
[SUBMODULE] Update protocol grid on enable/disable

Protocol grid view should be updated when the dmf_control_board plugin is
enabled or disabled.

See #93.

Trac update at 20120407T05:21:11:

<EMAIL_ADDRESS>commented:

commit 77cbab42db16aa92e6439c83b21a368e03e85e8f
Author: Christian Fobel<EMAIL_ADDRESS>Date:   Wed Apr 4 19:39:52 2012 -0400
[SUBMODULE] Decouple dmf_control_board plugin

Fixes #93.
Convert DmfControlBoardPlugin to a Plugin.
Eliminate app.control_board and any references to it.
Skip updates that involve a device or experiment log if the corresponding
app attribute is not ready.

Note that the experiment log plugin and protocol controller refer to the
dmf_control_board plugin.  However, they should now run fine without the
dmf_control_board installed.

<EMAIL_ADDRESS>changed resolution from "" to "fixed"
<EMAIL_ADDRESS>changed status from "assigned" to "closed"

Trac update at 20140417T19:39:01: ryan changed component from "" to "microdrop"


Add install target to cmake build

Small change to help with packaging.

Thank you for the patch.


0009_Palindrome_Number.py

IMPORTANT: Please do not create a Pull Request without an issue.
All Submissions:

[X] I have read the CONTRIBUTING document.
[X] My code is written in Python3 and is ending with .py
[X] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
[X] I have checked that my submission does pass the test on LeetCode.com
[X] Does your filename follow the naming Conventions?
[X] Have you linked your PR to an Issue?

Closing issues
Put closes #230  in your comment to auto-close the issue that your PR fixes (if such).

Not assigned to the linked issue - please consider Contributing Guidelines


主要符号对照表编译后如何按照首字母排序

发生了什么？
现在主要符号对照表编译后的顺序与自己文档中列出的顺序是一致的，请问如何按照首字母自动排序呢？
你期望的结果
No response
问题复现的步骤（或者截图）
\begin{symbols}
\item[2D] 二维的（Two-Dimensional）
\item[3D] 三维的（Three-Dimensional）
\item[RGB] 红绿蓝三种颜色的英文缩写，代表了一个颜色模型
\item[LRW] 自然场景唇读数据集（Lip Reading in the Wild）
\item[HDTF] 高分辨率面部动画数据集（High-definition Talking Face Dataset）
\item[CREMA-D] 众包情感多模态数据集（Crowd-Sourced Emotional Multimodal Actors Dataset）
\end{symbols}

因为数量不多，要不还是自己手动排一下序吧。

↓这有个类似例子，不过我完全看不懂是怎么实现的……如果你有需要，可以考虑让LLM改改。
itemize - Sorting a list based on the length of each entry - TeX - LaTeX Stack Exchange

ChtaGLM
The LaTeX code you've provided defines a custom list environment called Itemize. This environment is designed to typeset list items with a unique layout: the widest item determines the width of all the items, and each item is right-aligned with this width. Here's a breakdown of how it works:

\def\Itemize{...}: This defines the Itemize environment, which starts a vertical box (\vbox) and sets up some local definitions for handling items.
\def\ItemizeItem{...}: This macro starts a new item. It finishes the previous item (if any) and sets up a horizontal box (\hbox) for the new item, which is initially just a \strut (for consistent line spacing) and any ignored spaces.
\def\endItemize{...}: This ends the Itemize environment by closing the vertical box that was started when the environment began.
\def\xendItemizeItem{...}: This macro finishes an item. It does the following:

Ends the horizontal box for the item.
Sets up a vertical box (\vbox) to collect any wider items.
Loops through the remaining items in the vertical box, moving any wider items to the \vbox called \box4.
Finally, it places the current item followed by the wider items that were moved to \box4.
Here's how the items will be laid out:

The widest item (in this case, "aaaaaa") determines the width for all items.
Each item is right-aligned to this width.
When you compile this LaTeX code, you'll get a list where all items are right-aligned according to the width of the longest item, "aaaaaa". The output will look something like this:

aaaaaa
 aaaaa
  aaaa
   aaa
    a
     aa

Note that there are no bullet points or other markers before the items, and there is no indentation or vertical spacing between the items. If you want to add such features, you would need to modify the \ItemizeItem and \xendItemizeItem macros accordingly.

另：给一组文本排序可能非常复杂。

如果你用 PowerShell，可以选中这堆\item代码，复制，运行Get-Clipboard | Sort-Object（缩写gcb | sort），它会获取剪贴板并排序。


Action Items from meeting

Merge two PRs
Update GKE ticket and ETA on health check yaml
Doublecheck AWS access
Status on AWS and Azure

┆Issue is synchronized with this Jira Bug by Unito

Merged the Two PR's into main.
I will do more research on how to update the Backend service health check.
Thanks @bradfordcp, for granting me the access on the Friday. I will be adding the config map configuration, and RBAC configuration and related documentation in a separate PR.
I'm debugging the ingress on AWS and Azure.


put-bucket-policy : An error message is not appropriate when an invalid JSON file is used.

Environment info

NooBaa Version: noobaa-core-5.16.0-20240229.el8.x86_64 + PR7848 patch

Actual behavior
Even if a JSON file is an invalid format, the aws output shows An error occurred (InvalidRequest) when calling the PutBucketPolicy operation: SOAP requests must be made over an HTTPS connection.
$ aws s3api --endpoint [https://localhost:443](https://localhost/) put-bucket-policy --bucket mosamu-b1 --policy [file://policy.json](file:///) --no-verify
/usr/lib/fence-agents/bundled/aws/urllib3/connectionpool.py:1020: InsecureRequestWarning: Unverified HTTPS request is being made to host 'localhost'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/1.26.x/advanced-usage.html#ssl-warnings
 InsecureRequestWarning,

An error occurred (InvalidRequest) when calling the PutBucketPolicy operation: SOAP requests must be made over an HTTPS connection.

Expected behavior
The error message should be another one like Syntax error.
Steps to reproduce
N/A
More information - Screenshots / Logs / Other output
Here is a comment from @guymguym
In addition, the error message itself is just wrong and should be fixed - https://github.com/noobaa/noobaa-core/blob/29fc24a0a8ab0c2e38ea0d9af2db3fb070fb1aee/src/endpoint/s3/s3_errors.js#L207-L211
s3_errors.js

@mosamu can you please share the logs and the attached bucket policy?
We throw MALFORMED_POLICY on several invalid policy checks, but we might missed one.

@romayalon
Because of your update message, don't I have to share the log and policy file?
Thanks,

@mosamu
Usually yes, it helps us understand the root cause of your specific scenario.
I'll add here the info of my reproduction so you will be able to compare, if you see the exact same error in logs, you don't need to share it again, if you see other errors please provide the logs and the policy.
Here is the relevant info to the reproduction of the same s3api error code -
policy file -
% cat policy.json
this is not a json policy

s3api output -
AWS_ACCESS_KEY_ID=abc AWS_SECRET_ACCESS_KEY=123 aws s3api put-bucket-policy --bucket bucket1 --policy file://policy.json
An error occurred (InvalidRequest) when calling the PutBucketPolicy operation: SOAP requests must be made over an HTTPS connection.

NooBaa logs -
Mar-10 10:05:38.693 [nsfs/92351] [ERROR] CONSOLE:: parse_request_body: JSON parse problem SyntaxError: Unexpected token h in JSON at position 1
    at JSON.parse (<anonymous>)
    at parse_request_body (noobaa-core/src/util/http_utils.js:292:29)
    at Object.read_and_parse_body (noobaa-core/src/util/http_utils.js:241:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async handle_request (noobaa-core/src/endpoint/s3/s3_rest.js:149:5)
    at async Object.s3_rest [as handler] (noobaa-core/src/endpoint/s3/s3_rest.js:65:9)
Mar-10 10:05:38.694 [nsfs/92351] [ERROR] core.endpoint.s3.s3_rest:: S3 ERROR <?xml version="1.0" encoding="UTF-8"?><Error>InvalidRequest<Message>SOAP requests must be made over an HTTPS connection.</Message><Resource>/bucket1?policy</Resource><RequestId>ltl8ce6k-6kbbgy-2i0</RequestId></Error> PUT /bucket8318?policy {"host":"localhost:6443","accept-encoding":"identity","user-agent":"aws-cli/2.13.13 Python/3.11.5 Darwin/23.0.0 source/arm64 prompt/off command/s3api.put-bucket-policy",....} Error: SOAP requests must be made over an HTTPS connection.
    at parse_request_body (noobaa-core/src/util/http_utils.js:296:19)
    at Object.read_and_parse_body (noobaa-core/src/util/http_utils.js:241:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async handle_request (noobaa-core/src/endpoint/s3/s3_rest.js:149:5)
    at async Object.s3_rest [as handler] (noobaa-core/src/endpoint/s3/s3_rest.js:65:9)

@romayalon
Thank you for your advice,
I intentionally recreated the error on my bench.
policy file -
Although this is a JSON format, but it has an syntax error.
[mosamu@tcloud001 ~]$ cat invalid.json | jq
"Statement"
parse error: Expected string key before ':' at line 3, column 14

A bracket is missing.
[mosamu@tcloud001 ~]$ cat invalid.json

  "Statement": [
      {
       "Sid": "AllowEveryoneReadOnlyAccess",
       "Effect": "Allow",
       "Principal": "*",
      "Action": [ "s3:GetObject", "s3:ListBucket" ],
      "Resource": ["arn:aws:s3:::mosamu-b1","arn:aws:s3:::mosamu-b1/*"]
        }
  ]
}

s3api output -
The error must be same.
[mosamu@tcloud001 ~]$ aws s3api put-bucket-policy --endpoint http://localhost:80  --bucket mosamu-b1 --policy file://invalid.json

An error occurred (InvalidRequest) when calling the PutBucketPolicy operation: SOAP requests must be made over an HTTPS connection.

NooBaa logs -
2024-03-11T09:06:39.425027+09:00 tcloud001 node[63763]: [nsfs/63763] [ERROR] CONSOLE:: parse_request_body: JSON parse problem SyntaxError: Unexpected non-whitespace character after JSON at position 15    at JSON.parse (<anonymous>)    at parse_request_body (/usr/local/noobaa-core/src/util/http_utils.js:291:29)    at Object.read_and_parse_body (/usr/local/noobaa-core/src/util/http_utils.js:241:11)    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)    at async handle_request (/usr/local/noobaa-core/src/endpoint/s3/s3_rest.js:149:5)    at async Object.s3_rest [as handler] (/usr/local/noobaa-core/src/endpoint/s3/s3_rest.js:65:9)
2024-03-11T09:06:39.425705+09:00 tcloud001 node[63763]: [nsfs/63763] [ERROR] core.endpoint.s3.s3_rest:: S3 ERROR <?xml version="1.0" encoding="UTF-8"?><Error>InvalidRequest<Message>SOAP requests must be made over an HTTPS connection.</Message><Resource>/mosamu-b1?policy</Resource><RequestId>ltm6o9hf-82j83a-soc</RequestId></Error> PUT /mosamu-b1?policy {"host":"localhost","accept-encoding":"identity","content-md5":"mtsTNRqnwItc/ee4EUOUzA==","user-agent":"aws-cli/1.23.2 Python/3.6.8 Linux/4.18.0-477.27.1.el8_8.x86_64 botocore/1.23.46","x-amz-date":"20240311T000639Z","x-amz-content-sha256":"504237177988f988e9ddf681c9e6081b764262bd8b4bbd05905de7598129f816","authorization":"AWS4-HMAC-SHA256 Credential=CMAgCcoZOj1wYH3yV6L9/20240311/us-east-1/s3/aws4_request, SignedHeaders=content-md5;host;x-amz-content-sha256;x-amz-date, Signature=59e3419af640340bbf86c8fa2e500c4c0e4b7d630ff04c34ad4d504817d00fd7","content-length":"264"} Error: SOAP requests must be made over an HTTPS connection.    at parse_request_body (/usr/local/noobaa-core/src/util/http_utils.js:295:19)    at Object.read_and_parse_body (/usr/local/noobaa-core/src/util/http_utils.js:241:11)    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)    at async handle_request (/usr/local/noobaa-core/src/endpoint/s3/s3_rest.js:149:5)    at async Object.s3_rest [as handler] (/usr/local/noobaa-core/src/endpoint/s3/s3_rest.js:65:9)

Thanks,

Hello, @romayalon
I still see the same error at noobaa-core-5.15.2-20240425.el8.x86_64.
Possibly noobaa-core-5.15.2-20240425.el8.x86_64 has not included this fix?
[user2@tcloud003 ~]$ myaws s3api put-bucket-policy --bucket user2-b1 --policy file:///home/policy.json

An error occurred (InvalidRequest) when calling the PutBucketPolicy operation: SOAP requests must be made over an HTTPS connection.

I used this invalid formrat JSON file.
[root@tcloud003 home]# cat policy.json | jq
"Statement"
parse error: Expected string key before ':' at line 1, column 14

Hey @mosamu
The fix was merged only yesterday, so indeed it's not in noobaa-core-5.15.2-20240425.el8.x86_64
try this one - noobaa-core-5.15.3-20240509-5.15.el8.x86_64.rpm I built it now on top of 5.15 branch.


libxslt: CVE-2019-13118 CVE-2019-13117 (release-19.03)

Motivation for this change
Fixes #64661.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

same as https://github.com/NixOS/nixpkgs/pull/64910#issuecomment-512152307

Would this be better aimed at staging-19.03 given the hugeness of the rebuild?

Done.


Run Cell not working after kernel restart

Environment data

VS Code version: 1.37.0
Extension version (available under the Extensions sidebar): 2019.8.0
Python version (& distribution if applicable, e.g. Anaconda): 3.6
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): Jupyter

Expected behaviour
After restarting a jupyter kernel, I expect to be able to re-run a cell that has already been run
Actual behaviour
After a kernel restart, if I click "run cell" on a cell that had been run in the previous kernel, nothing happens.  If I click on an alternate cell, the cell runs as expected.  The console reports some logging about a cache hit so I wonder if a cache believes a cell has already been run and doesnt need to run again, despite the kernel restart
Steps to reproduce:

Create a cell
Execute the cell against a jupyter server
Restart the jupyter kernel
Attempt to execute the same cell

@kdkavanagh. Can you post that console output here? Currently I can't repro this and I'm able to re run any cells after a restart. There might be something different about your scenario.

@kdkavanagh we couldn't repro this issue here. when you have a chance, can you share a repro along with the console output? Thanks!


Using preprocess_phi_3_new in LAVIS/open_flamingo/train/sft_data_utils.py gets labels all -100.

Hello, thank you for your wonderful work.
I have a problem re-implementing LazySupervisedDataset and am stuck at the position of retrieving training labels. All labels are -100.

Below is a screenshot of my dataset:

I completely reuse your LazySupervisedDataset. When I initialize data_path, tokenizer, image_processor, and args, it runs without any issues. However, when I check the labels it generates, the tensor is entirely -100.
I debugged this strange behavior and found that the issue occurs because of the following piece of code:

First, when the if-clause above reaches the “user round,” the cur_len is absolutely not equal to total_len, so the line target[:] = IGNORE_INDEX is always executed.

Second, the code at line 226 does not skip the bos token but instead skips the |assistant| token. I don’t understand the reasoning behind this behavior.

@mgomes @zahnster @awaterma @ekashida

Not sure if it was an oversight by the author, but I believe these two lines of code should be commented out.

Hi @JHW5981,
Thank you for trying out with our code.
In my local environment, the current code works with the latest phi3-mini model/tokenizer. The commented code in line 225-226 was working with a previous version of phi3 tokenizer (the said phi3 model update).
Could you check if your local phi3 model is up-to-date?

Hello, glad to receive your response.
Replacing the tokenizer with the newest Phi-3 tokenizer does not solve my problem.
I downloaded the weights from Salesforce/xgen-mm-phi3-mini-instruct-r-v1 and used the following code to load the tokenizer:
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("my local weight dir")

To update the tokenizer, I replaced the files 'special_tokens_map.json', 'tokenizer_config.json', 'tokenizer.json', and 'tokenizer.model' with those from microsoft/Phi-3-mini-4k-instruct. After reloading the tokenizer, the issue persists.
I wonder if lines 225-266 in the code are essential. On line 221, the <|assistant|> token is already added. If lines 225-266 are not commented out, the <|assistant|> token is not masked. I believe this behavior is not consistent with how user-defined tokens should normally be masked.

By the way, do you know why using the tokenizer to convert text to ids does not add special tokens, even when I explicitly set add_special_tokens=True?😂


Optimize GFPGAN and Improve User Experience

This PR addresses the following issues.

GFPGAN is a post processing effect. Booting it at initialization meant that the model occupied VRAM that would otherwise be used for Stable Diffusion. This was resulting in systems having to use lower resolution on SD. As of this change, GFPGAN is no longer initialized at launch but rather just called in when a user prompts for it.
Loading GFPGAN at initialization meant booting torch modules in dream.py and then reinstance them when simplet2i.py is loaded again. As a side effect of this change, GFPGAN works off the torch modules loaded for SD and takes no performance hit in comparison to it being preloaded at initialization. Virtually no difference as far as I checked.
From a user experience perspective, the user now has absolute control on when to use GFPGAN without having to compromise VRAM by having it preloaded or having to restart the script to reinitialize if they didn't want to use GFPGAN or vice versa. Users can just pass -G along with their prompt to use GFPGAN.
Because this works on prompt basis now, you can have it on some, not have it on others. Whatever you like.

NOTE: I am not on my primary system. So I actually manually updated the code on Github. Someone double check that the formatting is correct before it is merged.
Thank you.

Additionally, I'd also look into separating both GFPGAN and Real-ESRGAN. GFPGAN is for blind face restoration and Real-ESRGAN is for upscaling. I think it'd be better for users to have the option to access these individually so they can use GFPGAN with Real-ESRGAN on images with faces and use just Real-ESRGAN for images that just need upscaling.

Don't merge this yet please. I'm making some important changes.

I've made some further improvements.
Instead of running GFPGAN while still processing SD and leading to a ton of memory issues, the app now runs GFPGAN after SD's images have been generated.
While SD is running, the app generates images and previews for the user to see their progress. When the processing ends, the app rescales all of the generated images to an upscaled version using GFPGAN and Real-ESRGAN.
This way no matter how big the batch size gets or samples get, there will likely not be any memory or CUDA crashes.
I've tested it out quite a bit. Seems to be working great. Let me know if you want any changes. @lstein
Should be good to pull now if u wish.

Hi Folks, will inspect and merge this shortly. This project has grown quite a bit so I'm going to start to do formal feature branches, bugfix branches, etc. I don't want users to get frustrated.

Hi Folks, will inspect and merge this shortly. This project has grown quite a bit so I'm going to start to do formal feature branches, bugfix branches, etc. I don't want users to get frustrated.

Thank you. Will keep an eye out for it. No issues. It's the right thing to do if this repo is going to grow larger.

Unable to get this to run - each iteration says GFPGAN not initialized, it must be loaded via the --gfpgan argument  when specifying the -G argument

Also, why iterate through the images twice when it's already happening after each image is generated on line 321?

It doesn't report any error, just the message that it can't be initialized and it fails, I get the non gfpgan'd image in my output

It doesn't report any error, just the message that it can't be initialized and it fails, I get the non gfpgan'd image in my output

Unsure. It's hard to tell without more info. I just made a clean pull from github and merged with mine. Seems to be working fine.

ok, I created a new conda environment and activated that, probably a me issue from testing the installation yesterday
My time for
a man wearing a pineapple hat -n6 -S1 -G1

is now twice over as long and it outputs that it processed 12 files instead of 6:
D:\stable-diffusion\000014.1902099158.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1902099158
D:\stable-diffusion\000014.3697446297.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3697446297
D:\stable-diffusion\000014.1077098826.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1077098826
D:\stable-diffusion\000014.1212597026.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1212597026
D:\stable-diffusion\000014.3743693958.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3743693958
D:\stable-diffusion\000014.2939900369.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S2939900369
D:\stable-diffusion\000014.1902099158.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1902099158
D:\stable-diffusion\000014.3697446297.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3697446297
D:\stable-diffusion\000014.1077098826.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1077098826
D:\stable-diffusion\000014.1212597026.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1212597026
D:\stable-diffusion\000014.3743693958.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3743693958
D:\stable-diffusion\000014.2939900369.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S2939900369

So that seems to be bad, also my VRAM usage is now worse after the first run because it seems to keep it gpfgan around until the GC gets to it, so I have to wait around for it to clear.

I haven't even gotten that far. The problem I'm having with this PR is that the --gfpgan command line switch is missing from the argv parsing list. Was it intended that gfpgan be activated by specifying --gfpgan_strength when starting the script?

Ok, I think this is still a work in progress and will convert into a draft. I'm going to branch the current version (with Oceanswave second PR) into a feature branch so that people can continue to work with it.

ok, I created a new conda environment and activated that, probably a me issue from testing the installation yesterday
My time for
a man wearing a pineapple hat -n6 -S1 -G1

is now twice over as long and it outputs that it processed 12 files instead of 6:
D:\stable-diffusion\000014.1902099158.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1902099158
D:\stable-diffusion\000014.3697446297.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3697446297
D:\stable-diffusion\000014.1077098826.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1077098826
D:\stable-diffusion\000014.1212597026.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1212597026
D:\stable-diffusion\000014.3743693958.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3743693958
D:\stable-diffusion\000014.2939900369.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S2939900369
D:\stable-diffusion\000014.1902099158.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1902099158
D:\stable-diffusion\000014.3697446297.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3697446297
D:\stable-diffusion\000014.1077098826.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1077098826
D:\stable-diffusion\000014.1212597026.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S1212597026
D:\stable-diffusion\000014.3743693958.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S3743693958
D:\stable-diffusion\000014.2939900369.png: "a man wearing a pineapple hat" -s1 -b1 -W512 -H512 -C7.5 -mk_euler -G1.0 -F -S2939900369

So that seems to be bad, also my VRAM usage is now worse after the first run because it seems to keep it gfpgan around until the GC gets to it, so I have to wait around for it to clear.
This seems to be an extremely bad user experience. It gives me a TON of errors if I didn't set my gfpgan up correctly the first time (which I didn't since I switched conda environments).

The GFPGAN implementation is yours. I did nothing there. If anything, I got rid of extra user warnings that are from the obsolete GFPGAN code.
Even in your code, you were generating 12 images -- 6 from SD and 6 Upscaled. The only difference is that I am materializing them to the disk so the user has a preview.
I am not sure what issues you are facing with VRAM usage. For me the load has been far better because you are no longer running GFPGAN and SD at the same time. In your implementation,. 512x768 which easily renders on my system kept crashing because GFPGAN started to hog the memory while the SD tensors were still in loop.
The GC collection remains the same.
To be very honest, I think this is a more ideal and user friendly way to do it. Because instead of going through the hoops of setting up a bunch of starter commands, a user can just trigger and launch GFPGAN with the help of a prompt which is the most natural way to do it.
If you hate seeing the log of images being saved, it's a one line fix to do that.
Either way, I'll let @lstein decide which one he prefers. Personally I think I am staying with mine because I truly believe it consumes far less memory overload and has a much nicer way of doing upscaling through prompts.

I haven't even gotten that far. The problem I'm having with this PR is that the --gfpgan command line switch is missing from the argv parsing list. Was it intended that gfpgan be activated by specifying --gfpga

You no longer need to use --gfpgan with this method. You can use the other commands to change the locations of the GFPGAN folders but otherwise, the entire process not works directly from the prompt that depends on the value of the gfpgan_strength. It's intended.
Why have two different start up modes for the script when the base script can handle the same thing through prompts right?

Everyone, thank you all for your efforts on this. Further work on gfpgan should be done on a new branch named gfpgan-development. From the maintenance point of view, I'd like to see the majority of the gfpgan code moved into its own module located under ldm/dream/ so that it isn't cluttering the already busy dream.py and simplet2i.py modules.

So that seems to be bad, also my VRAM usage is now worse after the first run because it seems to keep it gfpgan around until the GC gets to it, so I have to wait around for it to clear.
This seems to be an extremely bad user experience. It gives me a TON of errors if I didn't set my gfpgan up correctly the first time (which I didn't since I switched conda environments).

The GFPGAN implementation is yours. I did nothing there. If anything, I got rid of extra user warnings that are from the obsolete GFPGAN code.

But we talked about this, another loop has been introduced and it's running _run_gfpgan for each image twice.

Even in your code, you were generating 12 images -- 6 from SD and 6 Upscaled. The only difference is that I am materializing them to the disk so the user has a preview.
I am not sure what issues you are facing with VRAM usage. For me the load has been far better because you are no longer running GFPGAN and SD at the same time. In your implementation,. 512x768 which easily renders on my system kept crashing because GFPGAN started to hog the memory while the SD tensors were still in loop.
The GC collection remains the same.

But it's not, since every image it loads and unloads a new instance of GFPGAN

To be very honest, I think this is a more ideal and user friendly way to do it. Because instead of going through the hoops of setting up a bunch of starter commands, a user can just trigger and launch GFPGAN with the help of a prompt which is the most natural way to do it.

I'm a big fan of failing fast - if a user started with --gfpgan, we know apriori that we should test for gfpgan dependencies before failing at runtime

You no longer need to use --gfpgan with this method. You can use the other commands to change the locations of the GFPGAN folders but otherwise, the entire process now works directly from the prompt that depends on the value of the gfpgan_strength. It's intended.

Ah, OK. The README needs to be updated because it still refers to --gfpgan on the command line. In any case, let's continue this on the new feature branch. I'm really impressed with what GFPGAN can do!

But we talked about this, another loop has been introduced and it's running _run_gfpgan for each image twice.

No it is not. It is running GFPGAN only once per image. And only when the user has particularly requested for it. You got this idea of double generation because I was saving both the SD and GFP images. They were already being generated. The only difference between your patch and mine is that they're no longer happening simultaneously coz that was leading to a multitude of memory issues.

But we talked about this, another loop has been introduced and it's running _run_gfpgan for each image twice.

No it is not. It is running GFPGAN only once per image. And only when the user has particularly requested for it. You got this idea of double generation because I was saving both the SD and GFP images. They were already being generated. The only difference between your patch and mine is that they're no longer happening simultaneously coz that was leading to a multitude of memory issues.
Particularly this issue: #112 -- I tackled this making GFPGAN perform its upscaling after SD has done its work. If you do not do this, the second iteration will crash because there is no longer enough memory for both GFPGAN and SD to run at the same time. You can try this yourself.

Ah, OK. The README needs to be updated because it still refers to --gfpgan on the command line. In any case, let's continue this on the new feature branch. I'm really impressed with what GFPGAN can do!

My PR has an updated Readme on that. Let me know if I need to expand on it.

No it is not. It is running GFPGAN only once per image. And only when the user has particularly requested for it. You got this idea of double generation because I was saving both the SD and GFP images. They were already being generated. The only difference between your patch and mine is that they're no longer happening simultaneously coz that was leading to a multitude of memory issues.
Particularly this issue: #112 -- I tackled this making GFPGAN perform its upscaling after SD has done its work. If you do not do this, the second iteration will crash because there is no longer enough memory for both GFPGAN and SD to run at the same time.

call #1: https://github.com/blessedcoolant/stable-diffusion/blob/9ff140058b0b02be47495389076de6097caeae97/ldm/simplet2i.py#L326
call #2: https://github.com/blessedcoolant/stable-diffusion/blob/9ff140058b0b02be47495389076de6097caeae97/ldm/simplet2i.py#L344

No it is not. It is running GFPGAN only once per image. And only when the user has particularly requested for it. You got this idea of double generation because I was saving both the SD and GFP images. They were already being generated. The only difference between your patch and mine is that they're no longer happening simultaneously coz that was leading to a multitude of memory issues.
Particularly this issue: #112 -- I tackled this making GFPGAN perform its upscaling after SD has done its work. If you do not do this, the second iteration will crash because there is no longer enough memory for both GFPGAN and SD to run at the same time.

call #1: https://github.com/blessedcoolant/stable-diffusion/blob/9ff140058b0b02be47495389076de6097caeae97/ldm/simplet2i.py#L326 call #2: https://github.com/blessedcoolant/stable-diffusion/blob/9ff140058b0b02be47495389076de6097caeae97/ldm/simplet2i.py#L344
hack to get the count to be correct, but the callback is still called for each image 2x
https://github.com/blessedcoolant/stable-diffusion/blob/9ff140058b0b02be47495389076de6097caeae97/ldm/simplet2i.py#L367

Fuck. Seems like I updated the wrong code. Here's how it is on my end. Let me fix it up.

@lstein @Oceanswave I made the right pull now. Hopefully that's better. Sorry for the confusion lol. Now I hope it makes more sense.

Particularly this issue: #112 -- I tackled this making GFPGAN perform its upscaling after SD has done its work. If you do not do this, the second iteration will crash because there is no longer enough memory for both GFPGAN and SD to run at the same time.

Yeah, but now I run into the OOM issue with 24GB ram after an iteration of 10, so we probably need a gc.collect() in there or a torch.cuda().empty_cache() since it's doing a bunch more memory allocations.

@lstein @Oceanswave I made the right pull now. Hopefully that's better. Sorry for the confusion lol. Now I hope it makes more sense.

cool, lemmie pull

@lstein @Oceanswave I made the right pull now. Hopefully that's better. Sorry for the confusion lol. Now I hope it makes more sense.

ah, that generated_iterations var is still messing it up

@lstein @Oceanswave I made the right pull now. Hopefully that's better. Sorry for the confusion lol. Now I hope it makes more sense.

ah, that generated_iterations var is still messing it up
oh, and it's still calling the callback twice, so the file gets bounced multiple times, this is reflected in the logs too

Messing it up in what sense?
I am calling the callback twice intentionally. Because if I don't do that, then the user has to wait until after SD to actually get an image preview.
The first callback outputs the raw SD images. So this will act as user feedback while SD finishes the job. And if the user is okay with it, they can just let it be and once SD has completed, GFPGAN will upscale and replace the older images with newer ones.
The logs only show the resulting outputs. Previously we only saved GFPGAN to disk so it only showed those. But it's an easy fix. Can just get them to stop counting the base image.
But overall the number of images actually generated (not saved to disk) but rather created by GFPGAN and SD remain the same. If you do 6 images, there will be 12 outputs because GFFGAN generates an entirely new image too.

Messing it up in what sense?

Traceback (most recent call last):
File "./scripts/dream.py", line 434, in
main()
File "./scripts/dream.py", line 36, in main
from ldm.simplet2i import T2I
File "c:\src\stable-diffusion-updream\ldm\simplet2i.py", line 313
generated_iterations = []

I am calling the callback twice intentionally. Because if I don't do that, then the user has to wait until after SD to actually get an image preview.

Yeah, but one of the sort of implicit things is to have that callback be executed a single time per requested image - in my case I have a callback that saves images into a redis cache, I don't want to invoke that network traffic twice for every image, when I know I wanted the fixed/upsampled version since I specified -G -- if I wanted to do a comparison I could just resubmit without the flag, or do the new -S-1 feature that @lstein added
plus since gfpgan takes less than a second to run without it being reloaded I mean what is really being saved here. I can't click the file and click it again in that amount of time. or stop the process

Messing it up in what sense?

Traceback (most recent call last): File "./scripts/dream.py", line 434, in main() File "./scripts/dream.py", line 36, in main from ldm.simplet2i import T2I File "c:\src\stable-diffusion-updream\ldm\simplet2i.py", line 313 generated_iterations = []

I am calling the callback twice intentionally. Because if I don't do that, then the user has to wait until after SD to actually get an image preview.

Yeah, but one of the sort of implicit things is to have that callback be executed a single time per requested image - in my case I have a callback that saves images into a redis cache, I don't want to invoke that network traffic twice for every image, when I know I wanted the fixed/upsampled version since I specified -G -- if I wanted to do a comparison I could just resubmit without the flag, or do the new -S-1 feature that @lstein added
plus since gfpgan takes less than a second to run without it being reloaded I mean what is really being saved here. I can't click the file and click it again in that amount of time. or stop the process

So do you reckon we don't have the original images and just do the callback once?

So do you reckon we don't have the original images and just do the callback once?

that's my thinking, so that commands are idempotent - following this pattern, I'd expect a gobig implementation to not bounce the resulting image n times, but rather just output the final scaled image. it sort of breaks a level of idempotency if a callback needs to be created in a way that handles the side-effects of the command

So do you reckon we don't have the original images and just do the callback once?

that's my thinking, so that commands are idempotent - following this pattern, I'd expect a gobig implementation to not bounce the resulting image n times, but rather just output the final scaled image. it sort of breaks a level of idempotency if a callback needs to be created in a way that handles the side-effects of the command

One of the reasons I went for this was because in large operations such as many iterations, there won't be any image feedback for a while. It's okay for smaller generations though coz like you said the GFPGAN thing happens almost right away. But it's only an issue when the processing takes a while in large batches.

 It's okay for smaller generations though coz like you said the GFPGAN thing happens almost right away. But it's only an issue when the processing takes a while in large batches.

well, with the orig. implementation with it happening on the first pass of the iterator, it actually happens immediately after the image is generated, thus one doesn't need to wait

I hate waiting for initialization, so I'd rather get it all over at the
beginning. It's particularly a problem on my system because its an HPC
using a shared NFS mount. So loading big models and the modules themselves
really makes me wait. In any case, I'm going to be running errands this
afternoon, but after that I'll put the new commits through their paces and
report my impressions back.
Lincoln
On Fri, Aug 26, 2022 at 12:17 PM blessedcoolant @.***>
wrote:

I haven't even gotten that far. The problem I'm having with this PR is
that the --gfpgan command line switch is missing from the argv parsing
list. Was it intended that gfpgan be activated by specifying --gfpga
You no longer need to use --gfpgan with this method. You can use the other
commands to change the locations of the GFPGAN folders but otherwise, the
entire process not works directly from the prompt that depends on the value
of the gfpgan_strength. It's intended.
Why have two different start up modes for the script when the base script
can handle the same thing through prompts right?
—
Reply to this email directly, view it on GitHub
https://github.com/lstein/stable-diffusion/pull/102#issuecomment-1228686622,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA3EVKEKKOFXEIIKG5GDHLV3DUYDANCNFSM57WGQHAQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Lincoln Stein
Head, Adaptive Oncology, OICR
Senior Principal Investigator, OICR
Professor, Department of Molecular Genetics, University of Toronto
Tel:<PHONE_NUMBER>
Cell:<PHONE_NUMBER>
@.***
E**xecutive Assistant
Michelle Xin
Tel:<PHONE_NUMBER>
@.*** @.**>
Ontario Institute for Cancer Research
MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G
0A3
@OICR_news
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Foicr_news&data=04|01|Michelle.Xin%40oicr.on.ca|9fa8636ff38b4a60ff5a08d926dd2113|9df949f8a6eb419d9caa1f8c83db674f|0|0|637583553462287559|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=PS9KzggzFoecbbt%2BZQyhkWkQo9D0hHiiujsbP7Idv4s%3D&reserved=0
| www.oicr.on.ca
Collaborate. Translate. Change lives.
This message and any attachments may contain confidential and/or privileged
information for the sole use of the intended recipient. Any review or
distribution by anyone other than the person for whom it was originally
intended is strictly prohibited. If you have received this message in
error, please contact the sender and delete all copies. Opinions,
conclusions or other information contained in this message may not be that
of the organization.

Another thing to keep in mind is that the user may hit ^C during a
long-running set of iterations. Up until the interrupt hits, you want all
the previously-generated images to be complete, processed, and logged.
Lincoln
On Fri, Aug 26, 2022 at 1:05 PM blessedcoolant @.***>
wrote:

So do you reckon we don't have the original images and just do the
callback once?
that's my thinking, so that commands are idempotent - following this
pattern, I'd expect a gobig implementation to not bounce the resulting
image n times, but rather just output the final scaled image. it sort of
breaks a level of idempotency if a callback needs to be created in a way
that handles the side-effects of the command
One of the reasons I went for this was because in large operations such as
many iterations, there won't be any image feedback for a while. It's okay
for smaller generations though coz like you said the GFPGAN thing happens
almost right away. But it's only an issue when the processing takes a while
in large batches.
—
Reply to this email directly, view it on GitHub
https://github.com/lstein/stable-diffusion/pull/102#issuecomment-1228728188,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA3EVN22F5WVCOLO54MI7DV3D2N7ANCNFSM57WGQHAQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Lincoln Stein
Head, Adaptive Oncology, OICR
Senior Principal Investigator, OICR
Professor, Department of Molecular Genetics, University of Toronto
Tel:<PHONE_NUMBER>
Cell:<PHONE_NUMBER>
@.***
E**xecutive Assistant
Michelle Xin
Tel:<PHONE_NUMBER>
@.*** @.**>
Ontario Institute for Cancer Research
MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G
0A3
@OICR_news
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Foicr_news&data=04|01|Michelle.Xin%40oicr.on.ca|9fa8636ff38b4a60ff5a08d926dd2113|9df949f8a6eb419d9caa1f8c83db674f|0|0|637583553462287559|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=PS9KzggzFoecbbt%2BZQyhkWkQo9D0hHiiujsbP7Idv4s%3D&reserved=0
| www.oicr.on.ca
Collaborate. Translate. Change lives.
This message and any attachments may contain confidential and/or privileged
information for the sole use of the intended recipient. Any review or
distribution by anyone other than the person for whom it was originally
intended is strictly prohibited. If you have received this message in
error, please contact the sender and delete all copies. Opinions,
conclusions or other information contained in this message may not be that
of the organization.

 There's a limit to that but overall it might be worth the trade off imo.

Another thing to keep in mind is that the user may hit ^C during a long-running set of iterations. Up until the interrupt hits, you want all the previously-generated images to be complete, processed, and logged. Lincoln
…
On Fri, Aug 26, 2022 at 1:05 PM blessedcoolant @.> wrote: So do you reckon we don't have the original images and just do the callback once? that's my thinking, so that commands are idempotent - following this pattern, I'd expect a gobig implementation to not bounce the resulting image n times, but rather just output the final scaled image. it sort of breaks a level of idempotency if a callback needs to be created in a way that handles the side-effects of the command One of the reasons I went for this was because in large operations such as many iterations, there won't be any image feedback for a while. It's okay for smaller generations though coz like you said the GFPGAN thing happens almost right away. But it's only an issue when the processing takes a while in large batches. — Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3EVN22F5WVCOLO54MI7DV3D2N7ANCNFSM57WGQHAQ . You are receiving this because you were mentioned.Message ID: @.>
-- Lincoln Stein Head, Adaptive Oncology, OICR Senior Principal Investigator, OICR Professor, Department of Molecular Genetics, University of Toronto Tel:<PHONE_NUMBER> Cell:<PHONE_NUMBER> @.*** E**xecutive Assistant Michelle Xin Tel:<PHONE_NUMBER> @.*** @.**> Ontario Institute for Cancer Research MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G 0A3 @OICR_news https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Foicr_news&data=04|01|Michelle.Xin%40oicr.on.ca|9fa8636ff38b4a60ff5a08d926dd2113|9df949f8a6eb419d9caa1f8c83db674f|0|0|637583553462287559|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=PS9KzggzFoecbbt%2BZQyhkWkQo9D0hHiiujsbP7Idv4s%3D&reserved=0 | www.oicr.on.ca Collaborate. Translate. Change lives. This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.

Agreed. The current implementation has all the images logged at break time. Either if its the regular SD version or the upscaled.. depending on what part of the process we're at.

 It's particularly a problem on my system because its an HPC
using a shared NFS mount. So loading big models and the modules themselves
really makes me wait. In any case, I'm going to be running errands this
afternoon, but after that I'll put the new commits through their paces and
report my impressions back.

There's virtually no different for inference of GFPGAN whether we load it initially or load it during. The only difference is the memory. Having GFPGAN in memory when not being used is not worth it imo.

One of the reasons I went for this was because in large operations such as many iterations, there won't be any image feedback for a while. It's okay for smaller generations though coz like you said the GFPGAN thing happens almost right away. But it's only an issue when the processing takes a while in large batches.

well, with the orig. implementation with it happening on the first pass of the iterator, it actually happens immediately after the image is generated, thus one doesn't need to wait

If you do try to do multiple iterations on that, it'll fail on the second as others have reported too.
I think at this stage, I've implemented the best version I think in regards to this. I'm open to ideas but of the two versions we have now, I prefer mine personally.
Not sure if there's anything else I can add to this PR for now.

Agreed. The current implementation has all the images logged at break time. Either if its the regular SD version or the upscaled.. depending on what part of the process we're at.

But if I say -n5 -G1, and I ^C after the 3rd, because I saw the first and I got want I wanted in terms of content, I don't have the upscaled version at that point, so the operation isn't really 'complete' at that point. on the main branch, if run and see an image on the file system it's done done. no takebacksies.

There's virtually no difference for inference of GFPGAN whether we load it initially or load it during. The only difference is the memory. Having GFPGAN in memory when not being used is not worth it imo.

Say I have a slow network share that my code is on, that I'm mounting. for every image it's making a call to see if gfpgan exists, loading the model (it could have changed) across the network, then getting it into VRAM. processing the image, setting gfpgan to None, which lets the GC free it on the next cycle.
Probably what I'm hitting on this PR is things are getting loaded faster than the GC is able to get to them and I eventually get an OOM

I think at this stage, I've implemented the best version I think in regards to this. I'm open to ideas but of the two versions we have now, I prefer mine personally.
Not sure if there's anything else I can add to this PR for now.

Yeah, I understand the memory allocation issue - I think there's a middle ground here, and some data needs to be gathered to really determine an approach.
We might just need to sprinkle more gc.collect() around, or, the default mode as you indicate is to unload it, but also have a mode where it keeps it - solving the perf vs mem problem depending on the scenario.

I don't have the upscaled version at that point, so the operation isn't really 'complete' at that point. on the main branch, if run and see an image on the file system it's done done. no takebacksies.

For stand out cases like that what if we provide an option to just --upscale any image they like?

Probably what I'm hitting on this PR is things are getting loaded faster than the GC is able to get to them and I eventually get an OOM

Using my method I haven't hit an OOM yet. Can you tell me what your testing parameters are for that? I'll try to replicate that and see if it gets me an OOM too. As long as I stick to this process, I'm able to generate seemingly infinite images. I just did 350 and it worked fine. Could probably leave it on for a few hours and see if it crashes at some point.

We might just need to sprinkle more gc.collect() around, or, the default mode as you indicate is to unload it, but also have a mode where it keeps it - solving the perf vs mem problem depending on the scenario.

Wish we had some easier way to get some user feedback on what people would prefer seeing.
I'm exploring some more ideas to see if they're any better than what we have at the moment. I'll hit back here if I can work something out.

Slightly off topic, but is there a way to get both GPUs going during an
iteration run on a multi-GPU system? That would be a major benefit for a
few lucky people.
I’m taking a break from code review and testing tonight, and will weigh in
on the GFPGAN controversy tomorrow.
Lincoln
On Fri, Aug 26, 2022 at 1:37 PM Sean McLellan @.***>
wrote:

Agreed. The current implementation has all the images logged at break
time. Either if its the regular SD version or the upscaled.. depending on
what part of the process we're at.
But if I say -n5 -G1, and I ^C after the 3rd, because I saw the first and
I got want I wanted in terms of content, I don't have the upscaled version
at that point, so the operation isn't really 'complete' at that point. on
the main branch, if run and see an image on the file system it's done done.
no takebacksies.
There's virtually no difference for inference of GFPGAN whether we load it
initially or load it during. The only difference is the memory. Having
GFPGAN in memory when not being used is not worth it imo.
Say I have a slow network share that my code is on, that I'm mounting. for
every image it's making a call to see if gfpgan exists, loading the model
(it could have changed) across the network, then getting it into VRAM.
processing the image, setting gfpgan to None, which lets the GC free it on
the next cycle.
Probably what I'm hitting on this PR is things are getting loaded faster
than the GC is able to get to them and I eventually get an OOM
—
Reply to this email directly, view it on GitHub
https://github.com/lstein/stable-diffusion/pull/102#issuecomment-1228753776,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA3EVPIU7XAQ3VKTFZ2Q23V3D6FZANCNFSM57WGQHAQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Written on my cell phone. Anything that seems odd is the fault of
auto-correct.

So I made some changes on my end. Here's what I settled with.
Patch 1
Both GFPGAN and Real-ESRGAN are now independent of each other. Rather than triggering both each time, users can now control them independently depending on the kind of their prompt.
To support this, I added two new prompt arguments.

-U --upscale

Supplying the -U prompt argument will trigger Real-ESRGAN Image Scaling (that was running currently with GFPGAN). This will NOT perform Face Restoration. That is the job of GFPGAN so we should let it do that.
--upscale takes two values. The first value controls the scale factor for Real-ESRGAN. I implemented the 4x version of Real-ESRGAN too. You can pass either 2 or 4 as the first value. The second value controls the intensity of the scaling. Generally these AI's really smooth out the image removing a lot of texture. With this value, you can get considerably better looking results. Ideal values of around 0.5 to 0.8.

-G --gfpgan_strength

Supplying the -G prompt argument will trigger GFPGAN. This exclusively performs face restoration. It no longer performs scaling.
--gfpgan_strength takes one value which controls the intensity of the face restoration that is being applied. Ideal values are around 0.5 to 0.8.

Users can independently call either -G or -U to either upscale or do face restoration.
Users can call both -U and -G to perform upscaling and also face restoration. When you call both, the upscaling is done first and then the face restoration. This ensures that the face restoration module has the most data to work with leading to the best results for the face quality.
-save_orig : A new prompt argument that allows you to save original images when performing upscaling or face restoration. Use this in tandem with -U or -G or both. This way you can save and compare the original SD generation with the artificially enhanced versions if need be.
Moved GFPGAN and Real_ESRGAN from the simple2ti.py to another folder - ldm/gfpgan -- Cleaned up simple2ti.py accordingly.
GFPGAN and Real-ESRGAN now log which file is being upscaled instead of the generic message so users can keep track of the progress.

Memory Issues
After trying out a ton of options, I have to once again get back to the point that my implementation of the pipeline is the most ideal one in regards to GFPGAN and Real-ESRGAN at this current point of time.
The main goal is to create beautiful images and hopefully cater to systems even with lower VRAM so the maximum number of people can use it.
With that in mind, I have to reaffirm on my feeling that to avoid any memory issues, GFPGAN and Real ESRGAN will be performed after SD has completed image generation. Performing them while SD is still in memory will inevitably crash the generation sooner than later.
I have generated over 1500 images since we last spoke with the new system while scaling all of them by 2X and performing face restoration. I have not had a single crash by OOM so far.
The big issue of a user canceling a generation to not have an upscaled result is no longer a problem. If a user cancels a generation, they will have all images generated until that point. If they like any of those images, they can just get the seed from it and repass it to the generator along with -U and -G to perform scaling and face restoration if they want to. Problem solved.

This is what I have so far. I am trying to make the whole process even better. If I come up with any more ideas, I'll post here. But if you guys agree with this, I think I might make a new PR for that in a day or two with all the changes I mentioned above and any others that I might add.

@lstein I will have a look into it. Maybe there are ways to defer them to a secondary GPU. But like you said, it'll be handy only for a lucky few .. but no reason not to implement it if we can.

@lstein @Oceanswave I've pulled the Patch 1 detailed above and all the changes that I made with it. Completed the documentation too.

Thanks for all the work on this! I am testing now after having taken a break for a family event.

Thanks for all the work on this! I am testing now after having taken a break for a family event.

No rush mate. :) Take your time. Thank you for your time and effort too.

@blessedcoolant Is there any particular reason you changed the default image height to 768?

@blessedcoolant Is there any particular reason you changed the default image height to 768?

 That's just my defaults for my own system so I don't have to keep passing it. I forgot to reset it to the before I made the push. You can just change it back.

@blessedcoolant I've run into another problem. For benchmarking I'm running 5 iterations with the same starting seed each time. What I see is five different images being generated during the stable diffusion pass, but then during the GFPGAN pass only the second image is processed -- five times! So I get five of the same image. The GFPGAN logging messages do refer to the correct seeds (the fixed starting seed followed by 4 randomly generated seeds), so the logic is off somewhere.

@blessedcoolant I've run into another problem. For benchmarking I'm running 5 iterations with the same starting seed each time. What I see is five different images being generated during the stable diffusion pass, but then during the GFPGAN pass only the second image is processed -- five times! So I get five of the same image. The GFPGAN logging messages do refer to the correct seeds (the fixed starting seed followed by 4 randomly generated seeds), so the logic is off somewhere.

Found the issue. Fixing it.

@lstein Please check now. Fixed it.

@lstein Did some minor cleanup after. The code was a bit dirty to my liking.

Hi folks. I've done a series of benchmarks on my 32G GPU, and summary is here: https://docs.google.com/spreadsheets/d/1YXRlzp9TT9gRQMvbzKXW0xRjUI4bllHgfVcil0kS4oI/edit?usp=sharing
Take home messages:

@Oceanswave PRs run about 10% faster than @Blessedcoolant 's
Blessedcoolant's VRAM memory footprint is consistently lower than oceanswave. This was harder to measure, but ranged from 10%-20% depending on the task
When I pushed the system up to 832x1024 images, Blessedcoolant's implementation handled it (using 23.9G of VRAM), and Oceanswave consistently got CUDA OOM
I could not reproduce Issue #112 on either branch. This is a report of OOM errors occuring after several -n iterations, which suggested a memory leak of some sort.
When neither upscaling nor face fixing are requested, both branches perform equivalently. However, including --gfpgan in Oceanswave's branch does increase initialization time slightly and adds about 0.5G of VRAM utilization.

I think that users who want high quality faces and upscaling would rather trade off 10% runtime increase for 10% VRAM utilisation decrease. So my inclination is to bring in @blessedcoolant 's implementation and acknowledge both contributors for contributing the code to this working. I am so impressed with the improvements one can achieve with the combo of GFPGAN and Real-ESGAN!
I'll just wait for the afternoon (~4h) for any comments on the benchmarking and conclusions before hitting the merge button.

Hi folks. I've done a series of benchmarks on my 32G GPU, and summary is here: https://docs.google.com/spreadsheets/d/1YXRlzp9TT9gRQMvbzKXW0xRjUI4bllHgfVcil0kS4oI/edit?usp=sharing
Take home messages:

@Oceanswave PRs run about 10% faster than @blessedcoolant 's
Blessedcoolant's VRAM memory footprint is consistently lower than oceanswave. This was harder to measure, but ranged from 10%-20% depending on the task
When I pushed the system up to 832x1024 images, Blessedcoolant's implementation handled it (using 23.9G of VRAM), and Oceanswave consistently got CUDA OOM
I could not reproduce Issue GFPGAN executing fine for 1 image at a time, but OOM when using -n parameter, is there method to clear memory in between ? #112 on either branch. This is a report of OOM errors occuring after several -n iterations, which suggested a memory leak of some sort.
When neither upscaling nor face fixing are requested, both branches perform equivalently. However, including --gfpgan in Oceanswave's branch does increase initialization time slightly and adds about 0.5G of VRAM utilization.

I think that users who want high quality faces and upscaling would rather trade off 10% runtime increase for 10% VRAM utilisation decrease. So my inclination is to bring in @blessedcoolant 's implementation and acknowledge both contributors for contributing the code to this working. I am so impressed with the improvements one can achieve with the combo of GFPGAN and Real-ESGAN!
I'll just wait for the afternoon (~4h) for any comments on the benchmarking and conclusions before hitting the merge button.

Thank you so much for taking the time to do this testing. Looking forward to the merge.

@blessedcoolant; I apologize profusely for coming into this so late, but this PR really needs to have a git rebase -i run on it. The commit history for the repo as a whole is going to be messy and confusing if this is merged as is.
OTOH, the final merge decision is, as always, up to @lstein.

@blessedcoolant; I apologize profusely for coming into this so late, but this PR really needs to have a git rebase -i run on it. The commit history for the repo as a whole is going to be messy and confusing if this is merged as is.
OTOH, the final merge decision is, as always, up to @lstein.

I agree. It had a lot of changes made. I should have kept it cleaner but I was focused on the optimization. Sorry.
If @lstein wishes to, he can rebase this and pull it. If not, I can do a fresh PR with a cleaner commit history. Either works fine with you.
You could rebase it and make a PR that I can pull too if you have the time. I just popped out and won't be back for a few hours and don't want to hold up @lstein if he wishes to merge it before that.

You could rebase it

I really did consider this, but I'd be starting from 0 in understanding what's going on in here, which is, eh, "sub-optimal" at best when doing aggressive rebasing 😆

You could rebase it

I really did consider this, but I'd be starting from 0 in understanding what's going on in here, which is, eh, "sub-optimal" at best when doing aggressive rebasing 😆

Here's all the list of changed files.
ldm\dream\pngwriter.py
ldm\gfpgan\gfpgan_tools.py
ldm\simplet2i.py
scripts\dream.py
scripts\preload_models.py
README.md

Yes, I'm definitely going to rebase.

@blessedcoolant I'm actually having a difficult time getting this to rebase cleanly. I wonder if you could rebase your commits and generate a clean PR against main? Thanks.

@blessedcoolant I'm actually having a difficult time getting this to rebase cleanly. I wonder if you could rebase your commits and generate a clean PR against main? Thanks.

Yep. I'm closing this PR. I'll raise a new clean one.

Thanks so much.

Picked up in #162


Cannot connect with connection string

I'm trying to connect to my Notification Hub using the version 4.0.91 and some other earlier versions but everything that I got is:
<14:27:40> The application is now connected to the sb://ns-push-monkeyhub-app.servicebus.windows.net/ service bus namespace.
<14:27:40> MessagingFactory successfully created
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 1 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 2 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 3 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 4 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 5 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 6 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 7 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 8 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 9 of 10.
<14:34:36> Exception: Um ou mais erros.. Method <GetRelays>b__211_0: retry 10 of 10.
<14:34:36> Exception: Um ou mais erros.
<14:34:36> InnerException: O servidor remoto retornou um erro: (500) Erro Interno do Servidor. TrackingId:b1bec10e-ef0c-4286-b98e-e3d5a5ff4515, SystemTracker:NoSystemTracker, Timestamp:18/06/2017 17:34:36

I'm setting up with DefaultFullSharedAccessSignature connection string.
Maybe isn't important but my account is a DreamSpark Subscription so it's a free subscription and it's located at Brazil South.

@paolosalvatori do you know if DreamSpart subscriptions require anything special?

Mmm... @filipebezerra @SeanFeldman, I don't know DreamSpart subscriptions, hence I can't answer your question :(

Thanks @paolosalvatori. Can you indicate someone related to Microsoft to help with this? How can I submit an issue to the team related with Dreamspark subscriptions?

@filipebezerra can you raise an issue on the Azure portal?

Yep, I will. Thanks

What was the outcome of this @filipebezerra? Can this be closed?

yes, it wasn't solved but can be closed

Sorry to hear that - If we can help you in any other way, feel free to re-open it or create a new issue


core-rx and core-rx2 have class name collision when used in same project

Surprising as it may sound, I have a project with RxJava1/Grox Rx1 in one module, and RxJava2/Grox Rx2 in another. They work fine on their own, but when bringing them together, there's a collision as grox-core-rx and grox-core-rx2 use the same package and class name.
Most libraries solve this evolution problem by namespacing the Rx related classes under rx1 or rx2. Would this be something Grox would be willing to support?

@alin-turcu any idea when this will be available in a release?

@chenthorne Grox 1.1.2 has been released


[BUG]: QA| CMO | Localisation issue for button

https://jam.dev/c/0b43b6fd-2e22-4ed0-8176-9e1a603e163e
https://jam.dev/c/97fa8664-c5bb-45bf-9644-ef9c533c98a3

Its working fine in UAT env.


UWP support

Hi, can you make an UWP version of libtorrent-net?

I wanted to dig into it, but this is a hard task. I don't know when I will be able to do it.
If you want to move forward, first build Boost for UWP using  https://github.com/wpbest/Boost and try building libtorrent for UWP (x86, arm).
Then, the hard part, you will have to re-create a wrapper in C++/CX (not using C++/CLI like this project).

There is another lib, Monotorrent, that can implement bittorrent for UWP app. I tried to run this project https://github.com/haroldma/Universal.Torrent but it cannot connect to any peer. I also tried to telnet to peer but failed. Have you ever tried it before? Do you have any suggestions to fix it?

I have tried MonoTorrent in the past, but had a poor experience with it. I also could not be able to connect to any peer, which led me to fork libtorrent-net

Do you know any way that can implement BitTorrent protocol for UWP?

No I don't


EmrServerlessStartJobOperator does not raise airflow exception

Hi! I am testing the Operator and I found that airflow is marking a task as SUCCESS even though the EMR job state is FAILED.
I think the problem is in the EmrServerlessHook, this condition:
if state in failure_states:
    raise AirflowException(
        f"{object_type.title()} reached failure state {state}."
    )

should be at the end in the while loop.
Thanks!

Thanks @EzuA - I'll look into this today!

I think it is because this line (https://github.com/aws-samples/emr-serverless-samples/blob/main/airflow/emr_serverless/operators/emr.py#L220) has the 'desired_state' set to 'EmrServerlessJobSensor.TERMINAL_STATES', while I think it should have 'EmrServerlessJobSensor.SUCCESS_STATES':
                desired_state=EmrServerlessJobSensor.SUCCESS_STATES,

Franco

Yep, I think you're right, thank you!. :) Was just tracing the logic to verify.

Yes, I have tested both options and they are working in my local environment. I think the option proposed by Franco is the best.

Testing this locally now as well - should have an updated release by end of day. Thanks to both of you!

Thanks again - fixed in v1.0.1.


Carthage fixes

Carthage only looks at the .xcodeproj to look for the scheme to build, but said scheme in BetterSegmentedControl was looking at the target framework built in the Pods.xcodeproj.
So if you were using the .xcworkspace, you wouldn't notice anything, but if you opened the .xcodeproj in Xcode, you wouldn't be able to build the framework.
This adds a new target in the main xcodeproj that builds the framework, and the main schema now looks at that instead.
Closes #105

Hold up, I had looked wrong at the project architecture. This is going to need some more changes.


Bug Fix - Grammer mistake in Changelog page.

crowd.dev edition
Community (self hosted)
Version
No response
What happened?
I have spotted a grammer mistake in Changelog page. Below I have attached the snip of it, you can see , there is double comma after the word "Currently". I want to fix it.

Command / Request
I want to fix it , please assign this issue to me.

Relevant log output
No response

I want to fix it , please assign this issue to me.

I want to fix it , please assign this issue to me.

Hi , can you be more specific as to which file are you pointing to ?

I want to fix it , please assign this issue to me.

@joanagmaia  Kindly review the pr and consider merging under hacktoberfest

@vinfinity7 already tagged someone from the team to review it

@joanagmaia but that repo doesn't count under hacktoberfest ?


Support spsdk 1.7.0

According to mypy, the subset of spsdk that we use in this crate did not
change with the 1.7.0 release so we can relax the version requirement in
pyproject.toml to allow spsdk 1.7.0.
Changes

Relax spsdk version requirement to allow 1.7.0.

Checklist

[x] tested with Python3.9
[x] run make check or make fix for the formatting check
[x] signed commits
[ ] updated documentation (e.g. parameter description, inline doc, docs.nitrokey)
[ ] added labels

Test Environment and Execution

OS: Debian 11
device's model: -
device's firmware version: -

I’ve added some more changes to fix the CI for newer click versions.

spsdk is now packaged for Arch Linux and I think we don’t have any other packagers, so I’ll update this PR to require spsdk 1.7.0.  This allows us to forbid old click and black versions, avoiding potential version conflicts.


fix(sdk): solves barberry issue by updating the sdk

Closes #376
Update the cosmos sdk version to v0.47.3.

:tada: This PR is included in version 5.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


ACF Support: Country code with Country name for Select Field

I recently used this project within Advanced Custom Fields, allowing a client to choose a flag from a <select> box, which displays on the front end. I Pulled all the countries into the format that is needed for flag-icon-css to work.
The only thing that is needed is the country code to be lowercase, but easier to do when working within a project.
Country codes and their respective countries.
AF : Afghanistan
AX : Åland Islands
AL : Albania
DZ : Algeria
AS : American Samoa
AD : Andorra
AO : Angola
AI : Anguilla
AQ : Antarctica
AG : Antigua and Barbuda
AR : Argentina
AM : Armenia
AW : Aruba
AU : Australia
AT : Austria
AZ : Azerbaijan
BS : Bahamas (the)
BH : Bahrain
BD : Bangladesh
BB : Barbados
BY : Belarus
BE : Belgium
BZ : Belize
BJ : Benin
BM : Bermuda
BT : Bhutan
BO : Bolivia (Plurinational State of)
BQ : Bonaire, Sint Eustatius and Saba
BA : Bosnia and Herzegovina
BW : Botswana
BV : Bouvet Island
BR : Brazil
IO : British Indian Ocean Territory (the)
BN : Brunei Darussalam
BG : Bulgaria
BF : Burkina Faso
BI : Burundi
CV : Cabo Verde
KH : Cambodia
CM : Cameroon
CA : Canada
KY : Cayman Islands (the)
CF : Central African Republic (the)
TD : Chad
CL : Chile
CN : China
CX : Christmas Island
CC : Cocos (Keeling) Islands (the)
CO : Colombia
KM : Comoros (the)
CD : Congo (the Democratic Republic of the)
CG : Congo (the)
CK : Cook Islands (the)
CR : Costa Rica
CI : Côte d'Ivoire
HR : Croatia
CU : Cuba
CW : Curaçao
CY : Cyprus
CZ : Czech Republic (the)
DK : Denmark
DJ : Djibouti
DM : Dominica
DO : Dominican Republic (the)
EC : Ecuador
EG : Egypt
SV : El Salvador
GQ : Equatorial Guinea
ER : Eritrea
EE : Estonia
ET : Ethiopia
FK : Falkland Islands (the) [Malvinas]
FO : Faroe Islands (the)
FJ : Fiji
FI : Finland
FR : France
GF : French Guiana
PF : French Polynesia
TF : French Southern Territories (the)
GA : Gabon
GM : Gambia (the)
GE : Georgia
DE : Germany
GH : Ghana
GI : Gibraltar
GR : Greece
GL : Greenland
GD : Grenada
GP : Guadeloupe
GU : Guam
GT : Guatemala
GG : Guernsey
GN : Guinea
GW : Guinea-Bissau
GY : Guyana
HT : Haiti
HM : Heard Island and McDonald Islands
VA : Holy See (the)
HN : Honduras
HK : Hong Kong
HU : Hungary
IS : Iceland
IN : India
ID : Indonesia
IR : Iran (Islamic Republic of)
IQ : Iraq
IE : Ireland
IM : Isle of Man
IL : Israel
IT : Italy
JM : Jamaica
JP : Japan
JE : Jersey
JO : Jordan
KZ : Kazakhstan
KE : Kenya
KI : Kiribati
KP : Korea (the Democratic People's Republic of)
KR : Korea (the Republic of)
KW : Kuwait
KG : Kyrgyzstan
LA : Lao People's Democratic Republic (the)
LV : Latvia
LB : Lebanon
LS : Lesotho
LR : Liberia
LY : Libya
LI : Liechtenstein
LT : Lithuania
LU : Luxembourg
MO : Macao
MK : Macedonia (the former Yugoslav Republic of)
MG : Madagascar
MW : Malawi
MY : Malaysia
MV : Maldives
ML : Mali
MT : Malta
MH : Marshall Islands (the)
MQ : Martinique
MR : Mauritania
MU : Mauritius
YT : Mayotte
MX : Mexico
FM : Micronesia (Federated States of)
MD : Moldova (the Republic of)
MC : Monaco
MN : Mongolia
ME : Montenegro
MS : Montserrat
MA : Morocco
MZ : Mozambique
MM : Myanmar
NA : Namibia
NR : Nauru
NP : Nepal
NL : Netherlands (the)
NC : New Caledonia
NZ : New Zealand
NI : Nicaragua
NE : Niger (the)
NG : Nigeria
NU : Niue
NF : Norfolk Island
MP : Northern Mariana Islands (the)
NO : Norway
OM : Oman
PK : Pakistan
PW : Palau
PS : Palestine, State of
PA : Panama
PG : Papua New Guinea
PY : Paraguay
PE : Peru
PH : Philippines (the)
PN : Pitcairn
PL : Poland
PT : Portugal
PR : Puerto Rico
QA : Qatar
RE : Réunion
RO : Romania
RU : Russian Federation (the)
RW : Rwanda
BL : Saint Barthélemy
SH : Saint Helena, Ascension and Tristan da Cunha
KN : Saint Kitts and Nevis
LC : Saint Lucia
MF : Saint Martin (French part)
PM : Saint Pierre and Miquelon
VC : Saint Vincent and the Grenadines
WS : Samoa
SM : San Marino
ST : Sao Tome and Principe
SA : Saudi Arabia
SN : Senegal
RS : Serbia
SC : Seychelles
SL : Sierra Leone
SG : Singapore
SX : Sint Maarten (Dutch part)
SK : Slovakia
SI : Slovenia
SB : Solomon Islands
SO : Somalia
ZA : South Africa
GS : South Georgia and the South Sandwich Islands
SS : South Sudan
ES : Spain
LK : Sri Lanka
SD : Sudan (the)
SR : Suriname
SJ : Svalbard and Jan Mayen
SZ : Swaziland
SE : Sweden
CH : Switzerland
SY : Syrian Arab Republic
TW : Taiwan (Province of China)
TJ : Tajikistan
TZ : Tanzania, United Republic of
TH : Thailand
TL : Timor-Leste
TG : Togo
TK : Tokelau
TO : Tonga
TT : Trinidad and Tobago
TN : Tunisia
TR : Turkey
TM : Turkmenistan
TC : Turks and Caicos Islands (the)
TV : Tuvalu
UG : Uganda
UA : Ukraine
AE : United Arab Emirates (the)
GB : United Kingdom of Great Britain and Northern Ireland (the)
UM : United States Minor Outlying Islands (the)
US : United States of America (the)
UY : Uruguay
UZ : Uzbekistan
VU : Vanuatu
VE : Venezuela (Bolivarian Republic of)
VN : Viet Nam
VG : Virgin Islands (British)
VI : Virgin Islands (U.S.)
WF : Wallis and Futuna
EH : Western Sahara*
YE : Yemen
ZM : Zambia
ZW : Zimbabwe

this my list in array already. maybe useful.
$countries = array("AF" => "Afghanistan",
                    "AX" => "Åland Islands",
                    "AL" => "Albania",
                    "DZ" => "Algeria",
                    "AS" => "American Samoa",
                    "AD" => "Andorra",
                    "AO" => "Angola",
                    "AI" => "Anguilla",
                    "AQ" => "Antarctica",
                    "AG" => "Antigua and Barbuda",
                    "AR" => "Argentina",
                    "AM" => "Armenia",
                    "AW" => "Aruba",
                    "AU" => "Australia",
                    "AT" => "Austria",
                    "AZ" => "Azerbaijan",
                    "BS" => "Bahamas",
                    "BH" => "Bahrain",
                    "BD" => "Bangladesh",
                    "BB" => "Barbados",
                    "BY" => "Belarus",
                    "BE" => "Belgium",
                    "BZ" => "Belize",
                    "BJ" => "Benin",
                    "BM" => "Bermuda",
                    "BT" => "Bhutan",
                    "BO" => "Bolivia",
                    "BA" => "Bosnia and Herzegovina",
                    "BW" => "Botswana",
                    "BV" => "Bouvet Island",
                    "BR" => "Brazil",
                    "IO" => "British Indian Ocean Territory",
                    "BN" => "Brunei Darussalam",
                    "BG" => "Bulgaria",
                    "BF" => "Burkina Faso",
                    "BI" => "Burundi",
                    "KH" => "Cambodia",
                    "CM" => "Cameroon",
                    "CA" => "Canada",
                    "CV" => "Cape Verde",
                    "KY" => "Cayman Islands",
                    "CF" => "Central African Republic",
                    "TD" => "Chad",
                    "CL" => "Chile",
                    "CN" => "China",
                    "CX" => "Christmas Island",
                    "CC" => "Cocos (Keeling) Islands",
                    "CO" => "Colombia",
                    "KM" => "Comoros",
                    "CG" => "Congo",
                    "CD" => "Congo, The Democratic Republic of The",
                    "CK" => "Cook Islands",
                    "CR" => "Costa Rica",
                    "CI" => "Cote D'ivoire",
                    "HR" => "Croatia",
                    "CU" => "Cuba",
                    "CY" => "Cyprus",
                    "CZ" => "Czech Republic",
                    "DK" => "Denmark",
                    "DJ" => "Djibouti",
                    "DM" => "Dominica",
                    "DO" => "Dominican Republic",
                    "EC" => "Ecuador",
                    "EG" => "Egypt",
                    "SV" => "El Salvador",
                    "GQ" => "Equatorial Guinea",
                    "ER" => "Eritrea",
                    "EE" => "Estonia",
                    "ET" => "Ethiopia",
                    "FK" => "Falkland Islands (Malvinas)",
                    "FO" => "Faroe Islands",
                    "FJ" => "Fiji",
                    "FI" => "Finland",
                    "FR" => "France",
                    "GF" => "French Guiana",
                    "PF" => "French Polynesia",
                    "TF" => "French Southern Territories",
                    "GA" => "Gabon",
                    "GM" => "Gambia",
                    "GE" => "Georgia",
                    "DE" => "Germany",
                    "GH" => "Ghana",
                    "GI" => "Gibraltar",
                    "GR" => "Greece",
                    "GL" => "Greenland",
                    "GD" => "Grenada",
                    "GP" => "Guadeloupe",
                    "GU" => "Guam",
                    "GT" => "Guatemala",
                    "GG" => "Guernsey",
                    "GN" => "Guinea",
                    "GW" => "Guinea-bissau",
                    "GY" => "Guyana",
                    "HT" => "Haiti",
                    "HM" => "Heard Island and Mcdonald Islands",
                    "VA" => "Holy See (Vatican City State)",
                    "HN" => "Honduras",
                    "HK" => "Hong Kong",
                    "HU" => "Hungary",
                    "IS" => "Iceland",
                    "IN" => "India",
                    "ID" => "Indonesia",
                    "IR" => "Iran, Islamic Republic of",
                    "IQ" => "Iraq",
                    "IE" => "Ireland",
                    "IM" => "Isle of Man",
                    "IL" => "Israel",
                    "IT" => "Italy",
                    "JM" => "Jamaica",
                    "JP" => "Japan",
                    "JE" => "Jersey",
                    "JO" => "Jordan",
                    "KZ" => "Kazakhstan",
                    "KE" => "Kenya",
                    "KI" => "Kiribati",
                    "KP" => "Korea, Democratic People's Republic of",
                    "KR" => "Korea, Republic of",
                    "KW" => "Kuwait",
                    "KG" => "Kyrgyzstan",
                    "LA" => "Lao People's Democratic Republic",
                    "LV" => "Latvia",
                    "LB" => "Lebanon",
                    "LS" => "Lesotho",
                    "LR" => "Liberia",
                    "LY" => "Libyan Arab Jamahiriya",
                    "LI" => "Liechtenstein",
                    "LT" => "Lithuania",
                    "LU" => "Luxembourg",
                    "MO" => "Macao",
                    "MK" => "Macedonia, The Former Yugoslav Republic of",
                    "MG" => "Madagascar",
                    "MW" => "Malawi",
                    "MY" => "Malaysia",
                    "MV" => "Maldives",
                    "ML" => "Mali",
                    "MT" => "Malta",
                    "MH" => "Marshall Islands",
                    "MQ" => "Martinique",
                    "MR" => "Mauritania",
                    "MU" => "Mauritius",
                    "YT" => "Mayotte",
                    "MX" => "Mexico",
                    "FM" => "Micronesia, Federated States of",
                    "MD" => "Moldova, Republic of",
                    "MC" => "Monaco",
                    "MN" => "Mongolia",
                    "ME" => "Montenegro",
                    "MS" => "Montserrat",
                    "MA" => "Morocco",
                    "MZ" => "Mozambique",
                    "MM" => "Myanmar",
                    "NA" => "Namibia",
                    "NR" => "Nauru",
                    "NP" => "Nepal",
                    "NL" => "Netherlands",
                    "AN" => "Netherlands Antilles",
                    "NC" => "New Caledonia",
                    "NZ" => "New Zealand",
                    "NI" => "Nicaragua",
                    "NE" => "Niger",
                    "NG" => "Nigeria",
                    "NU" => "Niue",
                    "NF" => "Norfolk Island",
                    "MP" => "Northern Mariana Islands",
                    "NO" => "Norway",
                    "OM" => "Oman",
                    "PK" => "Pakistan",
                    "PW" => "Palau",
                    "PS" => "Palestinian Territory, Occupied",
                    "PA" => "Panama",
                    "PG" => "Papua New Guinea",
                    "PY" => "Paraguay",
                    "PE" => "Peru",
                    "PH" => "Philippines",
                    "PN" => "Pitcairn",
                    "PL" => "Poland",
                    "PT" => "Portugal",
                    "PR" => "Puerto Rico",
                    "QA" => "Qatar",
                    "RE" => "Reunion",
                    "RO" => "Romania",
                    "RU" => "Russian Federation",
                    "RW" => "Rwanda",
                    "SH" => "Saint Helena",
                    "KN" => "Saint Kitts and Nevis",
                    "LC" => "Saint Lucia",
                    "PM" => "Saint Pierre and Miquelon",
                    "VC" => "Saint Vincent and The Grenadines",
                    "WS" => "Samoa",
                    "SM" => "San Marino",
                    "ST" => "Sao Tome and Principe",
                    "SA" => "Saudi Arabia",
                    "SN" => "Senegal",
                    "RS" => "Serbia",
                    "SC" => "Seychelles",
                    "SL" => "Sierra Leone",
                    "SG" => "Singapore",
                    "SK" => "Slovakia",
                    "SI" => "Slovenia",
                    "SB" => "Solomon Islands",
                    "SO" => "Somalia",
                    "ZA" => "South Africa",
                    "GS" => "South Georgia and The South Sandwich Islands",
                    "ES" => "Spain",
                    "LK" => "Sri Lanka",
                    "SD" => "Sudan",
                    "SR" => "Suriname",
                    "SJ" => "Svalbard and Jan Mayen",
                    "SZ" => "Swaziland",
                    "SE" => "Sweden",
                    "CH" => "Switzerland",
                    "SY" => "Syrian Arab Republic",
                    "TW" => "Taiwan, Province of China",
                    "TJ" => "Tajikistan",
                    "TZ" => "Tanzania, United Republic of",
                    "TH" => "Thailand",
                    "TL" => "Timor-leste",
                    "TG" => "Togo",
                    "TK" => "Tokelau",
                    "TO" => "Tonga",
                    "TT" => "Trinidad and Tobago",
                    "TN" => "Tunisia",
                    "TR" => "Turkey",
                    "TM" => "Turkmenistan",
                    "TC" => "Turks and Caicos Islands",
                    "TV" => "Tuvalu",
                    "UG" => "Uganda",
                    "UA" => "Ukraine",
                    "AE" => "United Arab Emirates",
                    "GB" => "United Kingdom",
                    "US" => "United States",
                    "UM" => "United States Minor Outlying Islands",
                    "UY" => "Uruguay",
                    "UZ" => "Uzbekistan",
                    "VU" => "Vanuatu",
                    "VE" => "Venezuela",
                    "VN" => "Viet Nam",
                    "VG" => "Virgin Islands, British",
                    "VI" => "Virgin Islands, U.S.",
                    "WF" => "Wallis and Futuna",
                    "EH" => "Western Sahara",
                    "YE" => "Yemen",
                    "ZM" => "Zambia",
                    "ZW" => "Zimbabwe");

@semplon Thank you, saved me some time :+1:

Really don't understand how this issue relates to the project.

Less of an issue, more of a helper for projects where all flags can be used.
Having to manually type this list can be time consuming, so it's been done
twice here. Ideally, this should be attached on a document or a gist
On Fri, 22 Jan 2016 at 12:27, Ilya Breev<EMAIL_ADDRESS>wrote:

Really don't understand how this issue relates to the project.
—
Reply to this email directly or view it on GitHub
https://github.com/lipis/flag-icon-css/issues/80#issuecomment-173888438.

--
Cheers,
Common sense advocate,
Andrew Smith

@yratof Thanks for this! I was trying to find a good solution for a country field for ACF. I just created a select field and added your list as options. Saved me tons of time!

You can also check this (undocumented) thingy: http://flag-icon-css.lip.is/api/v1/country/  you have all the data there.. so basically do whatever you want..


Swap resume to CV on home page

Updated resume on homepage to CV, since the resume was already two pages.

Also updated dependencies.


Update README.md

moved the contributing section to the beginning of the readme file

I would like some assistance


Repo/package name

I think this should be called something more clear to novice users, something like ember-legacy-controllers or even ember-controllers or ember-controller-support

ember-legacy-controllers

:+1:


Request for scanning

Trying to figure out how to scan such that all of the spawn points are picked up.  On the weekends I sent the scanner to 150 and let it run all weekend.  Still not picking up some spawns. Assuming the start time is not sufficiently offset to pick them all up.  Is there any way to offset the start of each progressive scan at a set time from the previous in order to mark all of the spawn points?  It would be great if you could just type in the nearest scheduled scan ie. :00, :12, :24, :36, :48.  That would in theory, capture every spawn point.  Another useful thing would be able to see how many scans have been completed from a location since it was started and the time each one started.  Currently there is no way to know how long a single scan will take.  Another useful thing would be to have a ghost image showing the area that will be scanned with the current settings when you move the pin so you can make sure it's covering the areas you want it to cover.  New to all of this so apologies if this isn't the right place to put suggestions.

go into options  > marker and turn on scanned locations. I think you'll answer some of your own questions by visualizing the way the tool works. BTW, 150 radius is way too much for this tool in my experience - especially if you are only using 1 account.
Start out with a radius of 5 to 7 and see what's happening, and then you can experiment with multiple accounts. I've settled on a radius of 8 with 12 accounts, for example, just to make sure I see all spawns I can get to in less than 10 mins.

I guess I am using this tool a little different than most.  I am not using it to located spawns.  I am using it to map spawn points and times.  I am using multiple accounts.  radius 150 works well when I am using it to map spawn points for a region and I am leaving it up on my work computer to scan for an entire weekend.  The problem is that I have no way of knowing where the outer limits of the scan will fall so it's basically it's trial and error.  It would be great if the pin graphic included an outline of the outer limits of a complete scan. As I tried to describe in my first post, the other issue when doing region scans is that the scan cycle is well over an hour.  If the start of subsequent scans is close to the first you will not end up getting all of the spawns.

https://github.com/TBTerra/spawnScan

I've noticed that it doesn't display every gym anymore, along with spawn points, past a certain distance from places you've placed the pin. So I'd suggest moving the pin around to map out the spawn points. The information does stay for a while but I know it deletes after a while.


tweepy.error.TweepError: Twitter error response: status code = 401

Traceback (most recent call last):
  File "twitter_media_downloader.py", line 36, in <module>
    medias = get_medias(auth, user_id, args.retweets, args.image_size, args.since, args.since_id, args.until, args.until_id, args.likes)
  File "/root/twitter_media_downloader-master/src/parser.py", line 94, in get_medias
    for tweet in tweepy.Cursor(capi, id=user_id, include_rts=include_retweets, include_entities=True, tweet_mode='extended', since_id=since_id, max_id=until_id).items():
  File "/usr/local/lib/python2.7/dist-packages/tweepy/cursor.py", line 243, in next
    self.current_page = self.page_iterator.next()
  File "/usr/local/lib/python2.7/dist-packages/tweepy/cursor.py", line 132, in next
    data = self.method(max_id=self.max_id, parser=RawParser(), *self.args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/tweepy/binder.py", line 253, in _call
    return method.execute()
  File "/usr/local/lib/python2.7/dist-packages/tweepy/binder.py", line 234, in execute
    raise TweepError(error_msg, resp, api_code=api_error_code)
tweepy.error.TweepError: Twitter error response: status code = 401

Similar issue but status code = 400

Check your key and secret key. The README was a little bit confusing. I ended up with 401 too when I tried it first.
Basically, use API token and API secret key instead of the Access token and secret key.

I have tried the API token and API secret key and I keep getting that 401 error :'(

@nikos3194
I added access_token and access_token_secret to tweepy library and it work.
https://github.com/kittinan/twitter_media_downloader/commit/28ee8abfaa95da7e78f69f239d8b8568d05e0a0b

Indeed, It would seem that a proper access token is required to access protected accounts. Thanks @kittinan. I just pushed a fix for that, sorry for the delay 👍
An invalid key can also cause this issue on public accounts, so I renamed the "consumer token" to "consumer key" to prevent confusion (also because that's the official name now).


[Doc] Update maintainer doc

https://github.com/opensearch-project/dashboards-desktop/blob/main/MAINTAINERS.md

nominate @sichend per
https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#becoming-a-maintainer