[bug]: "Start Move" fails with "Image has wrong mode"

[shanedk]

Is there an existing issue for this problem?

• I have searched the existing issues

Install method

Invoke's Launcher

Operating system

Windows

GPU vendor

Nvidia (CUDA)

GPU model

RTX 3060

GPU VRAM

12GB

Version number

6.14.0-rc1

Browser

No response

System Information

I tried using the Start Move command in the Settings to move existing images to their folder (I have the Date method selected).

What happened

I got this:

[2026-08-12 20:06:08,637]::[InvokeAI]::ERROR --> Image move background operation failed: move_all
Traceback (most recent call last):
  File "W:\AI\InvokeAI.venv\Lib\site-packages\invokeai\app\services\image_moves\image_moves_default.py", line 163, in _run_background_operation
    target()
  File "W:\AI\InvokeAI.venv\Lib\site-packages\invokeai\app\services\image_moves\image_moves_default.py", line 217, in move_all_images
    self.perform_filesystem_moves(job_id)
  File "W:\AI\InvokeAI.venv\Lib\site-packages\invokeai\app\services\image_moves\image_moves_default.py", line 461, in perform_filesystem_moves
    self.complete_partial_filesystem_moves(job_id)
  File "W:\AI\InvokeAI.venv\Lib\site-packages\invokeai\app\services\image_moves\image_moves_default.py", line 514, in complete_partial_filesystem_moves
    self._regenerate_thumbnail(new_path, new_thumbnail_path)
  File "W:\AI\InvokeAI.venv\Lib\site-packages\invokeai\app\services\image_moves\image_moves_default.py", line 733, in _regenerate_thumbnail
    thumbnail = make_thumbnail(image)
                ^^^^^^^^^^^^^^^^^^^^^
  File "W:\AI\InvokeAI.venv\Lib\site-packages\invokeai\app\util\thumbnails.py", line 15, in make_thumbnail
    thumbnail.thumbnail(size=(size, size))
  File "W:\AI\InvokeAI.venv\Lib\site-packages\PIL\Image.py", line 2909, in thumbnail
    im = self.resize(final_size, resample, box=box, reducing_gap=reducing_gap)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "W:\AI\InvokeAI.venv\Lib\site-packages\PIL\Image.py", line 2420, in resize
    self.reduce(factor, box=reduce_box)
  File "W:\AI\InvokeAI.venv\Lib\site-packages\PIL\Image.py", line 2473, in reduce
    return self._new(self.im.reduce(factor, box))
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: image has wrong mode

Start Move is now grayed out, with the words "Recovery needed for job 4" and "Image has wrong node" next to it. When I hit the Recover button, it says "Running recovery" for a couple of seconds, then those two messages reappear.

The console prints: [2026-08-13 07:21:26,360]::[InvokeAI]::INFO --> Image move startup recovery completed: committed=0, errors=1

The error persists across restarts.

What you expected to happen

I expected the system to move the images around to organize them in folders by date.

How to reproduce the problem

1. Have a bunch of previously unorganized images
2. Set a subfolder strategy
3. Hit Start Move
4. When it fails, hit recover.

Additional context

No response

Discord username

shanedk

[shanedk]

Apparently related to this is an error I've never seen before: "Image Upload Failed: Rejected" whenever I upload an image, regardless of whether I drag-and-drop or hit upload, regardless of whether it's a PNG or JPG, regardless of what folder I'm uploading it from, even happens when I copy and paste the image.

Nothing appeared in the console, even when I set Debug level to Trace.

SQLite Browser showed the offending image had moved, but was completely black. Changing its status to "moved" and hitting the Recover button in the Invoke settings did not fix things.

[JPPhoto]

Issue 1: Thumbnail generation rejects large 16-bit PNGs

Problem:

• make_thumbnail() preserves the source mode.
• Pillow raises ValueError: image has wrong mode when resizing large I;16 images.
• This is image-mode dependent, not Windows-specific.

Repro:

• Create or upload a 1024x1024 I;16 PNG.
• Invoke thumbnail generation.
• Full PNG is written, but thumbnail generation fails.

Need to address:

• Convert thumbnail copies to RGB or RGBA before resizing.
• Preserve transparency where applicable.
• Test large I;16, RGB, RGBA, palette, grayscale, and alpha images.
• Test dimensions above and below the resize threshold.

Issue 2: Failed saves leave orphaned database records and files

Problem:

• The image record is saved before the file.
• The full image is written before the thumbnail.
• A thumbnail failure leaves a database record and valid full PNG with no thumbnail.
• Board associations may also remain.

Repro:

• Upload a large I;16 PNG.
• Upload returns an error.
• Full image and database record still exist.
• Thumbnail is missing.

Need to address:

• Make image creation atomic across database and filesystem state.
• Stage the full image and thumbnail before publishing either.
• Roll back files, records, board links, and caches on failure.
• Add in-memory database and temporary-storage tests.
• Define cleanup for orphaned records and files already created by older failures.

Issue 3: Image move recovery repeats the same failure forever

Problem:

• The move relocates the full image before regenerating a missing thumbnail.
• If regeneration fails, the source file is gone, the destination exists, and the database still has the old subfolder.
• Recovery retries the same invalid thumbnail operation.
• The job remains active and blocks future moves and image mutations.

Repro:

• Create a database record for an I;16 image with no thumbnail.
• Start image storage maintenance.
• Full image moves successfully.
• Thumbnail regeneration raises image has wrong mode.
• Recovery and restart produce the same error.
• Job remains moving.

Need to address:

• Make each image move recoverable and consistent after thumbnail failure.
• Generate or validate the thumbnail before the irreversible move, or roll the full image move back on failure.
• Ensure filesystem state, database subfolder, item state, and job state agree.
• Prevent recovery from retrying an operation that cannot succeed unchanged.
• Preserve a clear terminal error when manual intervention is required.
• Test initial move, retry, startup recovery, and process restart with an in-memory database and temporary files.

Issue 4: Stuck maintenance reports a misleading upload failure

Problem:

• Active image maintenance intentionally returns HTTP 409 before reading uploads.
• The frontend converts this into a generic upload failure, sometimes displayed as Rejected.
• Users cannot tell that maintenance is blocking the upload.

Repro:

• Leave an image move job in the stuck state above.
• Attempt an upload.
• Server returns 409.
• Frontend displays a generic upload failure.

Need to address:

• Provide a clear maintenance-specific error message.
• Distinguish maintenance rejection from invalid image, network, and server errors.
• Direct the user to recovery or retry after maintenance completes.
• Test the backend 409 response and frontend error display.