InvokeAI: REPL command returned after creating variation does not create the same image

Describe your environment

  • GPU: mps
  • VRAM: 32GB Unified Memory
  • CPU arch: arm64 M1
  • OS: macOS
  • Python: mamba env create -f environment-mac.yaml
  • Branch: development
  • Commit: i do not have a line that starts with “Merge”, but I am up to date with development

Describe the bug After generating an image, the REPL returns the command (parameters) which may be used to recreate that same image.

When variation amount is specified, the command returned does not recreate the same image.

To Reproduce

  1. Run python scripts/dream.py
  2. Generate an image using -v e.g. test -s 5 -S 0 -v 0.1, call it “Image 1”
  3. It returns a command e.g. outputs/img-samples/000070.810716037.png: "test -s 5 -W 512 -H 512 -C 7.5 -A k_lms -S 810716037 -n 1 -f 0.75 -V 810716037:0.1
  4. Copy that command and paste back into the REPL
  5. A different image is generated, call it “Image 2”

Expected behavior “Image 1” and “Image 2” are identical.

Additional context Maybe I am misunderstanding how variations work

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 27 (17 by maintainers)

Commits related to this issue

Most upvoted comments

Either I have a previous version of the file that just works

Yeah, I think this broke very recently (and probably only on the development branch), so I’m not surprised if you have an older version which still works correctly. Unfortunately I’m way behind on everything, so I can’t tell you exactly which file the issue is in.

If -S 42 -V 123:0.1 says “start at 42 and go 10% of the way to 123”, I would have guessed that -S 42 -V 123:1 says “start at 42 and go all the way to 123” instead of “start at 42 and move all the way back to 42”…

Whoops, sorry, I had a typo in my example (now fixed). It does indeed mean “go all the way to 123”.

The base seed is not being chosen correctly. Currently it is the seed passed to the image callback for the very first variant in the series.

That’s definitely a problem. It used to be the original seed. (Variations have two seeds, which are interpolated between.) So you would never have the same value in -S as -V in the output from a command with -v.

That must have gotten broken at some point.

I also thought that the variation_amount option (-v) should be set to zero, but this doesn’t help.

That is also a problem, independent of the previous thing. -v should not be specified at all in the output from the variation command. -v should be treated more like -n: it is used to determine the parameters for the output images (specifically, it is used to determine -V), rather than being a parameter itself.

That also must have gotten broken at some point; when I initially introduced this feature -v would not appear in the output at all (which was the correct behavior).

But that takes a lot of time. For example if I generate 20 images, then to generate a new one I have to specify -n21 because the first 20 images will be the same again…

That is a big downside, the question may be how often it happens in practice. If a few variations don’t work, I’d personally try changing the variation strength or the sampler or the steps or the prompt or a combination.

There are two things happening here:

  • re-running with -v will produce different images
  • using -S0 will generate a random seed, rather than using 0

The first thing is intentional: if you ask for 5 variations, then another 5 variations, you presumably don’t want the same things you got last time. (So @lstein your commenting-out of the random.seed() line here should be reverted.)

The second thing is a bug caused (I expect) by this line - in python, 0 is falsey, so this line will reset the seed. You want to use if seed is not None rather than if seed here.