Skip to content

fix(folderparser): include .webp images in directory uploads - #577

Open
BarsamErshadi wants to merge 2 commits into
roboflow:mainfrom
BarsamErshadi:fix/folderparser-webp
Open

BarsamErshadi wants to merge 2 commits into
roboflow:mainfrom
BarsamErshadi:fix/folderparser-webp

Conversation

@BarsamErshadi

@BarsamErshadi BarsamErshadi commented Nov 4, 2026 •

Copy link
Copy Markdown

What does this PR do?

When upload_dataset uploads a directory image by image (the default, not use_zip_upload=True), it skips .webp images without a message, along with any label next to them. parsefolder filters on IMAGE_EXTENSIONS, which lists every other format in ACCEPTED_IMAGE_FORMATS from roboflow/core/project.py but not WebP, and Project.upload already accepts those files. The CLI's directory upload goes through upload_dataset too.

This adds .webp to IMAGE_EXTENSIONS.

Related Issue(s): None that I found. Open PR #575 removes a separate extension list in the CLI, but it doesn't touch this set.

Type of Change

  • Bug fix (non-breaking change that fixes an issue)

Testing

  • I have tested this change locally
  • I have added/updated tests for this change

Test details:

I added test_lists_webp_images_with_their_labels to tests/util/test_folderparser.py. It fails on the unfixed code, where the .webp image is missing from the result, and passes with the fix. python -m unittest from the repo root gives 1279 tests, OK (1 skipped).

I also called Workspace.upload_dataset on a folder with a.jpg, b.webp and c.webp, each with a label, with the project stubbed:

Before: upload_image calls: ['a.jpg']
After:  upload_image calls: ['a.jpg', 'b.webp', 'c.webp']

Not verified: I did not test against the real Roboflow API, and everything ran on macOS with Python 3.12. So I can't say a real server accepts a .webp through this path. ACCEPTED_IMAGE_FORMATS is my evidence that it should.

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code where necessary, particularly in hard-to-understand areas
  • My changes generate no new warnings or errors
  • I have updated the documentation accordingly (if applicable)

Additional Context

Behaviour to judge:

  • Same stem in two formats: with a.jpg, a.webp and one a.txt, one image now gets the label and the other goes up unlabelled, with no message. Which one depends on the order os.walk returns them, because the sort ignores the extension. Before this change, a.jpg always got the label. a.jpg with a.png already behaves this way, so I left that mapping alone.
  • Content type: rfapi.upload_image sets the part's type with mimetypes.guess_type. On Python 3.12 this depends on the system's mime tables for .webp: with no system tables it returns None, so the part would go out as application/octet-stream, while .jpg, .avif and .heic still get their image types. I don't know how the server treats that. Single-file WebP uploads already take this path.
  • Merging with fix(folderparser): take the split from directory names before substrings #576: that PR also edits folderparser.py and its test file, and adds the same ### Fixed heading to CHANGELOG.md. The source merges cleanly, but the new tests and the changelog entries land at the same spot, so whichever merges second needs a small rebase.

BarsamErshadi and others added 2 commits November 4, 2026 07:02
parsefolder filters on IMAGE_EXTENSIONS, which left out .webp, so
upload_dataset skipped those images without a message. Project.upload
accepts them, and the CLI's supported formats include WebP.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant