KiranWells

Thanks for the offer, but if I have to solder, I would rather do it myself. Might be able to find someone at my college that I can borrow an iron from.

I didn't even know that, that's pretty cool. I'll have to try it later

To be fair, I have seen many people confused by git (in fact, there is a relevant xkcd). So for you and anyone else that could use some help:

Git is just a version tracker. It is basically like naming a files "project_1", "project_2", "project_final", etc. It just does the hard work of remembering history for you, and only shows you the current version.

The commands are somewhat oddly named, but are fairly intuitive:

git add - adds some of the current changes to the tracker ("stages" them).

git commit - commits (i.e. saves) the currently staged changes to a new point in your history (a 'commit')

git checkout - check out, as in take a look at, another branch

And you shouldn't think about pushing and pulling as a tree; think about it as an action you take. You either pull changes in from the server or you push them up to the server.

For more complex situations, you will need to use more complex functionality. Git is built to help manage changes when working on a team, so it has the concept of creating new branches of history - like an alternate timeline - so that each individual can work on their code as if they were working alone. When they are ready to send their changes to the main (or master) version, they can merge the changes in. In the event that you want to change history, there is git amend and git rebase.

The normal work flow goes like this:

• git checkout -b new-feature: check out a new brach, based on the one you are on now
• make some changes
• git add file.txt (or -A for all): add your changes to tracking
• git commit: save the changes to a new commit (a new point in history). This will try to open an editor so you can write a short message explaining the changes; you can use -m "message" to specify a message from the command line if you prefer.
• repeat until you are done working
• git push: send your changes to the remote server (add --set-upstream origin new-feature if this is the first time for this branch)
• open a pull request or something similar so someone else on the team can review and approve your code
• merge the pull request in

If your changes fall behind the main branch, you will need to update your branch before merging it in. First, checkout the main branch and pull the new changes. Then, checkout your branch and add the changes from main. There are two ways of doing this:

git merge main - merge the changes you are missing from main, creating a new point in history for the combined changes

git rebase main - change history so that it is as if your changes started from where main is now - change the base of your branch to be the current state of main.

If there are conflicts, stay calm and take a look at your files. You should see something like this (from here:

here is some content not affected by the conflict
<<<<<<< main
this is conflicted text from main
=======
this is conflicted text from feature branch
>>>>>>> feature branch

You need to edit the file to decide which of main's code and which of your branch's code to use. Once you are done, run:

git commit: if you are doing the merge method

git rebase --continue: if you are rebasing. A rebase resolves conflicts one commit at a time, so you might be editing code from previous commits, and you might need to repeat this process for the rest of your commits until you get back up to now.

Another tip: if git complains about uncommited changes, or if you just want to save all of your changes somewhere and go back to a clean slate, you can use git stash. This will create a local stash of your current changes, and allow you to get them back later with git stash apply or git stash pop.

And you aren't expected to remember it all. That's what man git, Google, and websites like git.wtf are for. Or, you can call that one friend who understands it, and ask them for help ;)

The repository links to a list of examples, but the best way to learn is just to mess around with it. It is fairly intuitive to work with (especially if you have used another node-based UI before, like Blender).

The UI also has the ability to import/export your current setup (what I call a workflow) as a json file. If I get some time, I might share some of mine with a pastebin link or something.

The usefulness of ComfyUI is not just making one simple image. It is the ability to completely customize how that image is created.

For example, I have a workflow that generates a half-resolution preview image, then upscales the latent and puts it through two more sampling nodes. All three of the nodes have a different prompt input, with the focus slowly shifting to style instead of content.

I have also created a custom upscaling workflow, where the image is upscaled with normal upscaling, then re-encoded and put through just a few sampling steps, the re-encoded with a tiled VAE decoder (to save my VRAM). It creates much better results (more detail and control) than a direct ERSGAN upscale, and can even be put through ERSGAN afterward to get a super large image.

I would guess it's one of three things:

1. You are using Windows instead of Linux for ROCm (I don't know how much this affects performance, as I am only on Linux)
2. You are generating the batch all at the same time, instead of just doing multiple generations. This can lead to out-of-memory issues, as it is a larger image being generated.
3. You are not fully using the GPU. Does task manager say 100% utilization?

I'm also using ComfyUI. It just has the ability to do so much more than something like Automatic1111, even if it is missing a couple of features. For example, I have several workflows that do incremental changes to a photo, changing the prompt halfway through the generation, or even upscaling halfway through the generation.

I can't really imagine going back, unless there is some killer feature that Comfy is missing.

The best part is that this is written on the top part of the box, meaning you would have to open the box to read it.

When I first tried Helix, my main concern (that prevented me from getting too far into it) was not going from Vim to Helix, but the other way around. Vim (or sometimes vi) is a standard editor on almost any Linux machine, so if I am ever working on a server if a VM, I would need to know/use Vim keybinds. That made Vim a more useful tool for me to learn at the time, as I could use the skills both on my machine and anywhere else.

If I remember correctly, they are both from Unsplash. I think I used their image API with "Colorful" or something as the search term.

Just as a warning, you are on Kbin, which is a bit different from Lemmy. The two communicate just fine, but have different UIs and features. Lemmy generally has "communities" instead of "magazines", but they work in mostly the same way.

For Lemmy, generally going to the search menu in the UI allows you to search for communities, but not every one will come up (for example if the server you are on doesn't know about another new server yet). If is often better to use a third-party website like browse.feddit.de to find new communities.

Not sure how subscribing to them would work on Kbin, though.

That button is a markdown preview; it will show you how things like links will look after you post. There is an open issue about the NSFW marking here.