43 lines
2.7 KiB
Markdown
43 lines
2.7 KiB
Markdown
# ComfyUI_ColorMod
|
|
|
|
|
|
|
|
This repo currently has two sets of nodes - one set for editing the contrast/color of images and another set for saving images as 16 bit PNG files.
|
|
|
|
I'd recommend using it with `--fp32-vae` to get the full precision output. BF16 definitely doesn't have enough precision, FP16 might work but will NaN randomly on some VAEs.
|
|
|
|
I'm not sure it makes sense to do it like this from an implementational standpoint, but (as far as I can tell) the IMAGE inputs/outputs in ComfyUI are `torch.float32`s between 0 and 1, meaning they have a lot of precision compared to 8bit images.
|
|
|
|
The idea was to make use of this so changing the brightness / contrast / etc would happen in this high-precision space, which would hopefully lessen banding and artifacts due to rounding errors/working with `UINT8`.
|
|
|
|
## Installation
|
|
|
|
Simply clone the whole repo to your custom node folder: `git clone https://github.com/city96/ComfyUI_ColorMod ComfyUI/custom_nodes/ComfyUI_ColorMod`
|
|
|
|
The 16 bit PNG output nodes rely on `pypng`, which can be installed with `pip install pypng`. This isn't a hard requirement, it disables those nodes if it can't find it.
|
|
|
|
For the standalone comfy install, you can install it with `python_embeded\python.exe -m pip install pypng`.
|
|
|
|
# Usage
|
|
|
|
The custom nodes are in images and images/postprocessing respectively. Below is a simple graph that explains what the values do, though I'd like to add a JS widget to show these changes live eventually.
|
|
|
|
|
|
|
|
|
|
## Precision
|
|
|
|
I ran a 8 bit gradient through the UNET at 99% denoise, then decoded it using `ft-mse-840000`. After this, I saved the output as a 16 bit PNG using the node in this pack.
|
|
|
|
The graph below shows the first two decimal digits after converting the image to [0-255]. There is no point in charting INT8 images, since they all end in zero. Here's what I think these results mean:
|
|
|
|
- The synthetic gradient was 2048 wide, with each column being `(column+1)/2048`% gray. The grouping mostly makes sense here.
|
|
- The FP32 VAE adds a bunch of noise, so the distribution ends up pretty even, though it does lean towards values ending in zero (probably due to being trained on 8bit images).
|
|
- The FP16 VAE seems to be similar to the synthetic one, maybe due to the lack of precision?
|
|
- The BF16 VAE apparently only has 7 bits of precision for the mantissa, so it's a pretty bad format to store the [0-1] VAE output in.
|
|
|
|
|
|
|
|
*Or I might just be graphing weird float rounding errors. Who knows.*
|
|
|