tal

This is a newly disclosed plot and marks yet another alleged attempt on Trump’s life by the Iranian regime.

I use sway in Wayland, and tend to keep games on a separate workspace.

In X11, with i3, I'd frequently switch away from the game and leave it running when something was loading or progression was required, and do something else while waiting. In Wayland, pretty much every game would suspend while viewing another workspace, which drove me bananas. I assumed that this was toggleable functionality, but couldn't find where the toggle was.

Today, I finally ran across an answer to this and wanted to highlight it for anyone else who dislikes this behavior. By default, if a window is not visible, rendering will block. Setting the vk_xwayland_wait_ready=false environment variable will disable this functionality.

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

A still-life oil-on-canvas painting by Caravaggio.

The image shows a silver platter on a table. The platter has elevated lips. The silver platter has legs.

There is an éclair on the platter.

The éclair is cream-filled.

There is a banana on the platter touching the éclair.

There are two cherries side-by-side on the platter.

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

A still-life oil-on-canvas painting by Caravaggio.

The image shows a silver platter on a table. The silver platter has legs.

On the platter, from right to left, is an aubergine, a doughnut, and a glass dessert dish containing a scoop of vanilla ice cream.

The ice cream has two Maraschino cherries on top.

The doughnut is iced.

There is a Maraschino cherry on the table to the right of the platter.

[email protected] just posted asking why he couldn't see any posts on the [email protected] community.

https://lemmy.world/post/21680997

I cannot, myself, see any posts in that community when viewing it in the instance, and I don't see post deletions in the instance modlog, if I'm reading it aright.

Wanted to post this to give folks a heads up, in case there's something wrong on the instance.

EDIT: False alarm; looks like it was due to me and a few other folks not noticing that the community had been NSFW-flagged. Sorry for any time wasted!

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

The image is a photograph.

The image is in a darkened bar.

The image is high-contrast.

The image has a noir theme.

The bar's walls are paneled in dark wood. The bar's flooring is dark green marble tile.

In the center of the image, there is a singer named Jill.

Jill is singing into microphone on a boom mount. Jill is wearing a long, red, clingy, sequinned dress. Jill is w>earing black heels. Jill has shoulder-length, soft-curled, auburn hair. Jill is beautiful. Jill's eyes are closed.

Jill is the focus of the image.

A musician named Bob is in the left half of the image.

Bob is a young man. Bob is wearing a white shirt with the top button open. Bob is wearing a brown suit jacket and brown trousers. Bob is leaning against the back wall and playing a plain acoustic guitar in the background behind Jill. Bob's eyes are closed. Bob is relaxed. Bob is heavily-shadowed.

The lighting is dramatic. Jill is illuminated with stage lighting.

There are two patrons wearing dark suits sitting on chairs in the right half of the image watching Jill.

Everything other than Jill is colored in muted, low-saturation, earth tones.

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

Five people are standing on a hillside.

From left to right, the first person is a girl. The second person is a boy. The third person is a boy. The fourth person is Sailor Moon. The fifth person is Darth Vader.

The image is a silhouette.

The image is a black-and-white vector illustration.

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

The image is a Neo-Impressionist gouache knife painting.

The image is of a forest with a brook running through it.

The image is a blended composite with a progression from left to right showing winter to spring to summer to autumn.

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

The image is looking through the front window of a butcher's shop.

There are various meats on display in the window.

A mournful dog is sitting on the sidewalk in front of the shop looking in, looking into the shop.

The dog is facing away from the viewer.

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

A photograph of a white cat. The background is black. The cat has large yellow orange eyes with a reddish ring around the outer edge of the iris. The cat has an uncanny extremely wide smile with many visible pointed teeth. The cat is staring intently at the viewer. Teeth are visible all along the cat's lips. The cat is terrifying. The irises of the cat's eyes are constricted.

The theme is horror.

UI: ComfyUI

Model: STOIQNewrealityFLUXSD_F1DAlpha

A stylized vector illustration of a small 1940s fishing boat at sea in a tempest.

The image is minimalist.

The image is at night, with moonlight shining on the waves.

There are many clouds and heavy rain. There are large waves. The image is dark and shadowed.

The cabin of the boat is illuminated with a buttery yellow light.

There are shark fins in the water.

The theme is horror.

ComfyUI is a locally-run UI (i.e. you need to have a beefy local GPU) that's generally more-complicated to learn than the older, more-common Automatic1111. However, it works kind of like some professional image-processing software does, lets you create a directed acyclic graph, lets one build up complicated workflows using those. It's also got some nice features, like the ability to queue up multiple requests (though it's not the only UI to do this, it's kind of a glaring limitation in Automatic1111). ComfyUI also caches what it has generated while traversing the DAG, and only regenerates what data is necessary. It's also capable of doing Flux, which Automatic1111 is not, and while Flux is not today a full replacement for everything I have done with Stable Diffusion, it can do a lot and has a far better ability to understand natural-language descriptions of scenes and less propensity to generate mangled images. As a result, I generally use ComfyUI rather than Automatic1111 now; it's a more "serious" tool for building up complex stuff.

Automatic1111 mostly consists of a positive prompt, a negative prompt, and maybe fields for any plugins you've installed. There are entirely-decoupled features for generating an image from text (txt2img) and processing existing images (img2img). Since often one may want to generate an image and then process it, this makes image generation a multi-stage process, which requires a lot of manual involvement.

In Automatic1111, some information about how to generate the image is displayed beneath the image. You can copy this from the Web UI. It'll contain the prompt text and -- I think -- all of the settings in the txt2img panel, at least as long as any plugins used properly implement this feature. So you can let someone else see what you did and recreate the image by posting the text there, post the "source code" of your image; when I post an image generated in Automatic1111, I paste this text beneath the image. It contains stuff like the scheduler used, how many iterations were run, and so forth.

However:

• It doesn't contain system settings, some of which are necessary to recreate the image.

• Running txt2img and img2img are two different steps. So, for example, if you want to generate an image in txt2img at a lower resolution, then take the resulting image and upscale it in img2img using the SD Ultimate Upscale plugin -- something that I generally do -- then these are two different operations.

• While it's nice that it's human-readable, It's not machine-readable. Someone else can't just paste the text into their Automatic1111 setup and have it import those settings. They need to manually enter it.

In contrast, ComfyUI lets someone save their entire DAG workflow by just clicking "save". It'll generate a JSON file that anyone else can open and use (and tweak, if they want). This is much, much nicer in my book, since it lets me share the "source code" to my images with other users in a way that's trivial for them to import.

Both Automatic1111 and ComfyUI attach their text to the image in EXIF tags and indicate that the image is AI-generated (probably good practice to help avoid polluting later training data). On Linux, I can use ImageMagick, for example, to see this, run $ identify -verbose image.png. Unfortunately, Lemmy or Pictrs or whatever the image-posting functionality is for Lemmy instances, appears to strip EXIF data out of posted images, maybe to keep people from inadvertently doxxing themselves, as some cameras attach GPS EXIF data. People have inadvertently doxxed themselves in the past on Reddit and probably other platforms. So end users here don't get to actually see the embedded source to generated images, even though both Automatic1111 and ComfyUI do their best to include it. While I don't post images on civitai.com, I suspect that the way they get all of their image metadata is by inspecting that EXIF data about the generation process from posted generated images...but that's not an option here.

I've generally tried to just manually post it, which I think is good practice.

For posting ComfyUI JSON workflows, there are two issues.

• First, compared to the text that Automatic1111 provides, the JSON is quite verbose. It's pretty-printed, which makes it easier to read, but even longer. Trying to post it verbatim in the text after each image would take up a great amount of screen space for users here.

• Second, while it's readable, most of what an end user is probably often interested in is just what the prompt and maybe the model used is. Digging through a lot of JSON for that is a pain -- it's readable, but certainly not as much as Automatic1111's summary.

What I've settled on -- and what I think is a good convention, if you're using ComfyUI and want to share the "source code" to your image -- is to post the model name and prompt manually beneath the image, since this lets someone just skimming the image quickly see and understand the basic settings used to generate the image.

I then also save the workflow from ComfyUI and generate a compressed, Base64-encoded version of that text, and attach it in spoiler tags. Lemmy, mbin, and AFAIK piefed and sublinks do not have the ability to do file attachments to posts, so this is probably the closest analog presently available to embed a small file in a post.

I use xz (which does LZMA compression), as it's an open-source compressor widely-available on Linux systems; LZMA is one of the "tightest" of the mainstream compression mechanisms. While it's far from the fastest, the workflow files are tiny, so speed does not matter.

That generates binary output, which cannot be posted. I then Base64-encode them, which generates a text string using characters that can be posted here. Various mechanisms have been used for this on Usenet in the past, including uuencode and yEnc, so making use of that existing work makes sense. I think that Base64, while not as compact as yenc, is the most-widely-used today, and I know that the restrictive character set used doesn't smack into any Markdown encoding issues, so went with that.

I've written a shell script that can do this automatically for other folks using Linux. This will take an existing workflow file, xz-compress it, Base64-encode it, prefix each line with four spaces so that the text is displayed literally by Markdown and not wrapped at each line, and then wraps the text in spoiler tags, so that in the Lemmy Web UI and any other clients that support it, the text is collapsed by default, as well as labeling the text with the filename. If anyone else is interested:

# Encode a file such that it can be pasted into a Lemmy markdown comment.
# Depends on coreutils, sed, and xz-utils.
# Usage: mylemmybinaryencode.sh <filename>

filename="$@"

echo "

:::

Or, packed by itself:

On Debian-family Linux systems (most, these days), you'll need to have the xz-utils, sed, and coreutils packages installed. I suspect that pretty much all Linux systems out there already have these pre-installed, as they're very common utilties.

To decode such a file, one can do:

$ base64 -d <filename.xz.base64 | xz -d >filename

I'm sure that there are utilities on other platforms that can also handle Base64 and xz-compressed data (I've several other packages installed on my own), but that uses probably the most-widely-available utilities to do so.

Just wanted to provide at least what I do when posting images, and explain why.