jpeg decode tests on M1 are broken
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 17.9k
- Forks
- 7.3k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 13
Description
Following up on https://github.com/pytorch/vision/issues/8027#issuecomment-1752500876
The M1 job is failing with
FAILED test/test_image.py::test_encode_jpeg[grace_hopper_517x606.jpg] - AssertionError: The values for attribute 'shape' do not match: torch.Size([59718]) != torch.Size([59723]).
FAILED test/test_image.py::test_write_jpeg[grace_hopper_517x606.jpg] - AssertionError: The length of the sequences mismatch: 59718 != 59723
= 2 failed, 21536 passed, 16709 skipped, 1 xfailed, 300 warnings in 1684.83s (0:28:04) =
What gets confusing is that both M1 and linux jobs (which are passing) rely on libjpeg-turbo 8.0
2023-10-05T13:17:24.4351270Z torch.ops.image._jpeg_version() = 80
Perhaps the libjpeg-turbo package of M1 is... misleading? IDK. CI is garbage right now, so it's hard to assess anything.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with test/test_image.py and the failing test_encode_jpeg and test_write_jpeg cases on the M1 job. Compare their JPEG behavior with Linux, including the reported libjpeg-turbo 8.0 and torch.ops.image._jpeg_version() values. Done means the M1 JPEG tests pass consistently and the package or environment discrepancy is understood.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- computer-vision, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100