nodes/bugltd-ComfyLab-Pack
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

new banner and better README files (#10)

Browse Source 
* set the new repo banner and icon

* improve the README files by using github md alerts
This commit is contained in:
Bug, Ltd.
2025-01-28 10:07:28 +01:00
committed by GitHub
parent 3e3983bbfc
commit 07ae7129ea
23 changed files with 193 additions and 118 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/node reference/format.md
+7 -4
View File
@@ -7,8 +7,10 @@
The `Format` nodes are very simple yet powerful nodes, that are based on the **standard Python string `format()` method**.\
They exist in 2 flavors: `String` or `Multiline`.
They are useful to create a string from a template, and **any number of inputs**.\
Inputs can be of the following ComfyUI types: `STRING`, `INT`, `FLOAT`, `BOOLEAN`.
They are useful to create a string from a template, and **any number of inputs**.
> [!NOTE]
> Inputs can be of the following ComfyUI types: `STRING`, `INT`, `FLOAT`, `BOOLEAN`.
## How to use
@@ -23,7 +25,8 @@ Given the following template: `first arg by name: {arg0}, second by index: {1}`,
Here we see that **we can reference the inputs either by their name (`argN`), or by their index (starting at 0)**.\
Straightforward, isn't it?
This way, it's **very simple to concatenate 2 strings, append text to a string, ... many operations in one single node!**
> [!TIP]
> This way, it's **very simple to concatenate 2 strings, append text to a string, pad / truncate, ... many operations in one single node!**
And last but not least: at stated above, it can take **other types than strings: integer, float, boolean** (and surely others).
@@ -32,7 +35,7 @@ And last but not least: at stated above, it can take **other types than strings:
For more details and advanced techniques, you can check:
- [the tutorials of the `Format` nodes](../tutorials/Format/)
- [a guide with different possible techniques (padding, ...)](https://pyformat.info/)
- [a guide with different techniques (padding, ...)](https://pyformat.info/)
- [format specification mini-language (python.org)](https://docs.python.org/3/library/string.html#format-specification-mini-language)
## Inputs / Widgets / Outputs
wiki/node reference/output config.md
+5 -1
View File
@@ -9,7 +9,11 @@ The `Output Config: Load` (and its backend counterpart, `Output Config: Retrieve
It opens a whole range of use cases: whether you need to standardize tests (LoRA, ...), store a collection of usual use cases, or just share your configs with others, this node can certainly prove very useful.\
**You can define any number of outputs in it, to match your specific needs**.
A config file is a simple text file in one of the following formats: **JSON, JSON5 or YAML** (and also the unofficial JSONC, aka 'json with comments').
A config file is a simple text file in one of the following formats: **JSON, JSON5 or YAML**.
> [!TIP]
> The `YAML` and `JSON5` formats allow comments, which can be very handy, especially if you need to share your configs and document them.\
> While `JSON` doesn't allow them (by design), you can also use the unofficial `JSONC` (aka "JSON with comments") with the ComfyLab `Output Config` node.
A config can be very simple:
wiki/node reference/xy plot/0 - core concepts.md
+46 -28
View File
@@ -12,36 +12,52 @@ What is processed between them (from `dim1 value` / `dim2 value` outputs of `Que
As you can see in the screenshot, there is no concept of row / column or X / Y in the `Queue` node, as in many other plot / grid implementations:
- instead, we talk about `dim1` and `dim2` (dimensions 1 & 2)
- this is intended, to improve performance: but we'll talk about that later
- just remember this rule: **for a given `dim1` value, we process all values of `dim2` before switching to the next `dim1` value**
- whether `dim1` and `dim2` are rows or columns is configured later, in the `Render` node (`direction` toggle)
- `dim1` and `dim2` (optional) **take lists as inputs**
- in ComfyUI, a LIST is a LIST, but we cannot know if it's a list of strings, numbers, images, ...
- so another important rule: **what you send is what you get**
- said differently: if you send a list of numbers, you will get number values in output
- or one could say: sh\*t in, sh\*t out...
- for the reason above, the `Queue` node cannot determine what it will get in input, so the type of the outputs is set to `"*"` (Any)
- this makes the `dim1 value` and `dim2 value` outputs very flexible, as you can basically connect them anywhere
- but it comes at a price: **you must ensure that the data in input correspond to the expected data in output**
- for example: if you connect `dim1 value` to the `cfg` input of `KSampler`, you must ensure that the input list is a list of floats. If you send strings, you will obviously get an error when running the workflow
- one of the main features of the `Queue` node is **auto-queuing**
- no need to reset a counter, or manually increase the batch size
- **the `Queue` node will take care of that for you**
- in fact, you should definitely **not set the batch size to anything else than `1`**
Instead, we talk about `dim1` and `dim2` (dimensions 1 & 2): this is intended, to improve performance: but we'll talk about that later.
> [!IMPORTANT]
> Just remember this rule: **for a given `dim1` value, we process all values of `dim2` before switching to the next `dim1` value**.\
> Whether `dim1` and `dim2` are rows or columns is configured later, in the `Render` node (with the `direction` toggle).
`dim1` and `dim2` (optional) **take lists as inputs**:
- in ComfyUI, a LIST is a LIST, but we cannot know if it's a list of strings, numbers, images, ...
- so another important rule: **what you send is what you get**
- said differently: if you send a list of numbers, you will get number values in output
- or one could say: sh\*t in, sh\*t out...
For the reason above, the `Queue` node cannot determine what it will get in input, so **the type of the outputs is set to `"*"` (Any)**.\
This makes the `dim1 value` and `dim2 value` outputs very versatile, as you can basically connect them anywhere.
But it comes ar a price:
> [!WARNING]
> You must ensure that the **data in input correspond to the expected data in output**\
> For example: if you connect `dim1 value` to the `cfg` input of `KSampler`, you must ensure that the input list is a list of floats.\
> If you send strings, you will obviously get an error when running the workflow
One of the main features of the `Queue` node is **auto-queuing**
- no need to reset a counter, or manually increase the queue size
- **the `Queue` node will take care of that for you**
- in fact, you should definitely **not set the queue size to anything else than `1`**
## XY Plot: Render
The `Render` node, in its default configuration is easier to understand:
- it takes an `image` as input, for example the result of the `KSampler` processing
- <ins>important</ins>: you are not limited to KSampler
- in fact **you can do what you want between the `Queue` node and the `Render` one**
- it could be loading the image from a folder, doing some image transformations... you decide
- it has 2 outputs:
- `image` is the single image, as received in input
- `grid` is the generated grid, when it has received enough images
- obviously, you can generate multiple grids, if you configure pagination in the `Queue` node
It takes an `image` as input, for example the result of the `KSampler` processing
> [!IMPORTANT]
> You are not limited to KSampler:
>
> - in fact **you can do what you want between the `Queue` node and the `Render` one**
> - it could be loading the image from a folder, doing some image transformations... you decide
This node has 2 outputs:
- `image` is the single image, as received in input
- `grid` is the generated grid, when it has received enough images
- obviously, you can generate multiple grids, if you configure pagination in the `Queue` node
## dim1 vs dim2, which one should I choose? (or the Performance Question)
@@ -68,6 +84,8 @@ So let's switch, connecting the list of checkpoints to `dim1`, and the list of s
- **keep** checkpoint #1, get seed #3 > _do not load checkpoint #1_ (it's in memory) > render image
- ...
By doing so, we optimize the performance as much as possible.\
So as a general rule: **if you need to vary models (checkpoint, LoRA, ...), ensure these values are connected to `dim1`**.\
(And if you vary 2 lists of models, obviously choose the slowest as `dim1`).
By doing so, we optimize the performance as much as possible.
> [!TIP]
> So as a general rule: **if you need to vary models (checkpoint, LoRA, ...), ensure these values are connected to `dim1`**.\
> (And if you vary 2 lists of models, obviously choose the slowest as `dim1`).
wiki/node reference/xy plot/1 - queue and render.md
+20 -19
View File
@@ -6,15 +6,16 @@
## XY Plot: Queue
Important notes:
- `dim` and `dim2` take lists as inputs, and sends each combination of values in outputs
- as the node cannot anticipate what is the type of input list values, the outputs are set to type Any (`"*"`)
- it means that you can connect the outputs everywhere
- but you must ensure that the type of data in input correspond to the expected in destination node
- **what you send is what you get**
- `dim1` and `dim2` are processed following the rule: **for a given `dim1` value, we process all values of `dim2` before switching to the next `dim1` value**
- the node will manage auto-queuing: ensure set **the batch size is set to 1**
> [!IMPORTANT] > `dim` and `dim2` take lists as inputs, and sends each combination of values in outputs
>
> - as the node cannot anticipate what is the type of input list values, the outputs are set to type Any (`"*"`)
> - it means that you can connect the outputs everywhere
> - but you must ensure that the type of data in input correspond to the expected in destination node
> - **what you send is what you get**
>
> `dim1` and `dim2` are processed following the rule: **for a given `dim1` value, we process all values of `dim2` before switching to the next `dim1` value**
>
> the node will manage auto-queuing: ensure set **the queue size is set to 1**
For more detailed explanations, please check the [core concepts](./0%20-%20core%20concepts.md).
@@ -44,17 +45,17 @@ For more detailed explanations, please check the [core concepts](./0%20-%20core%
## XY Plot: Render
Note:
`dim1: header format` and `dim2: header format`:
- `dim1: header format` and `dim2: header format`
- enter here a template string, following the syntax of Python string `format()` method
- the `{dim1}` and `{dim2}` placeholders will be replaced by the current dim1 / dim2 value
- very handy if you want to prefix the row / column headers, for example:
- if you have CFG values in dim1, by default the headers will be `7.5`, `8`, ...
- just change the dim1 header format to `CFG: {dim1}` and you will get: `CFG: 7.5`, `CFG: 8`, ...
- there are plenty of advanced techniques, but you will probably not use them here
- however if you want to learn more, you can check the [`Format` node reference](../format.md)
- `direction`: whether dim1 values are displayed as rows, or columns
- enter here a template string, following the syntax of Python string `format()` method
- the `{dim1}` and `{dim2}` placeholders will be replaced by the current dim1 / dim2 value
- very handy if you want to prefix the row / column headers, for example:
- if you have CFG values in dim1, by default the headers will be `7.5`, `8`, ...
- just change the dim1 header format to `CFG: {dim1}` and you will get: `CFG: 7.5`, `CFG: 8`, ...
- there are plenty of advanced techniques, but you will probably not use them here
- however if you want to learn more, you can check the [`Format` node reference](../format.md)
`direction`: whether dim1 values are displayed as rows, or columns
### Inputs / Widgets / Outputs
wiki/node reference/xy plot/2 - config nodes.md
+6 -2
View File
@@ -7,7 +7,8 @@
In addition to the standard [Queue and Render nodes](./1%20-%20queue%20and%20render.md), you can customize many visual aspects of the grid, thanks to 2 optional nodes, `Plot Config: Grid` and `Plot Config: Header/Footer`, than can be plugged into `XY Plot: Render`.\
They allow you to customize the grid, and either the page header or footer (or both), all configurable separately.
To see them in action, please refer to [tutorial #2 - pimp my grid](../../tutorials/XY%20Plot/2%20-%20pimp%20my%20grid/).
> [!TIP]
> To see them in action, please refer to [tutorial #2 - pimp my grid](../../tutorials/XY%20Plot/2%20-%20pimp%20my%20grid/).
While some configuration options are specfic, they share some similarities:
@@ -26,12 +27,15 @@ The color can expressed either as RGB hex notation (e.g. `#e9e9e9`), or by name
As for the font color, you can use either the RGB hex notation, or a color name.
In addition, you can also use the special value `transparent`:
In addition, **you can also use the special value `transparent`**:
- in the `Plot Config: Header/Footer`, it means the header / footer will use the same bg color as the grid
- while in `Plot Config: Grid`, it will make the grid RGBA
- useful if you want to add a background image
> [!TIP]
> To see how to use a custom background image, please check the [XY Plot tytorial: 2 - pimp my grid (Part 3)](../../tutorials/XY%20Plot/2%20-%20pimp%20my%20grid/)
## Plot Config: Grid
### Widgets / Outputs