Add TF image classification example script

[amyeroberts]

What does this PR do?

Adds the TF equivalent for the PyTorch image classification example script.

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline,
  Pull Request section?
• Was this discussed/approved via a Github issue or the forum? Please add a link
  to it if that's the case.
• Did you make sure to update the documentation with your changes? Here are the
  documentation guidelines, and
  here are tips on formatting docstrings.
• Did you write any new necessary tests?

[HuggingFaceDocBuilderDev]

The documentation is not available anymore as the PR was closed or merged.

[sgugger]

Thanks a lot for working on this!
It looks like your branch is a bit old and does not contain some fixes made to make sure the example tests run when an example is modified (you can see the test examples are not running here 😅 ). Could you try a rebase on main?

[sgugger]

Still no good, I scanned the test fetcher and found a potential bug. COuld you add

            elif f.startswith("examples/tensorflow"):
                test_files_to_run.append("examples/flax/test_tensorflow_examples.py")

at the line 562 of utils/test_fetcher.py (in-between PyTorch and Flax)? I think that's what causing the issue of the tests not running.

[amyeroberts]

It looks like your branch is a bit old and does not contain some fixes made to make sure the example tests run when an example is modified (you can see the test examples are not running here 😅 ). Could you try a rebase on main?

@sgugger I've rebased from upstream main and force pushed again. If I run git log --oneline I can see these changes are applied on top of the tip of main.

270bfb056 (HEAD -> add-examples-tf-image-classification, origin/add-examples-tf-image-classification) Add tests
a2256258b Fix up
1a1594cb8 Update requirements
b6a2f1ef9 TF image classification script
9ccea7acb (upstream/main, main) Fix some doctests after PR 15775 (#20036)
a639ea9e8 Add **kwargs (#20037)
ec6878f6c Now supporting pathlike in pipelines too. (#20030)
aa39967b2 reorganize glossary (#20010)
305e8718b Show installed libraries and their versions in CI jobs (#20026)

The examples still aren't running and I can't see in the diff where I could be overriding this 😅 I'm sure there's something I'm overlooking. I'll keep digging but let me know if there's something else I should be doing. Sorry to bother.

[amyeroberts]

@sgugger - sorry late on the comment as well. I'll add your suggestion!

[sgugger]

Is there a way to make the test run in less than 30/40s? Would be nice for it to be run on the CI.

[amyeroberts]

Definitely - I'll play with the model / dataset / number of samples.

[amyeroberts]

So, this was paused for quite a while because the script was taking ages on the prepare_tf_dataset step. Thanks to the sleuthing from @Rocketknight1 and the subsequent to_tf_dataset updates and using with_format("np") things move a lot faster. Switching to a hf-internal-testing dataset and small model meant it runs < 30s.

[Rocketknight1]

This looks really clean overall! Have you tested that you get similar accuracy after fine-tuning as the PT example? I know the CI test checks this, but the tolerances on quick small tests like that have to be quite wide, so they can miss subtler performance degradation.

[Rocketknight1]

I know this is from torchvision and not your idea, but trying 10 random rolls and then giving up rather than figuring out how to constrain your randomness so it outputs valid solutions the first time is quite funny.

[Rocketknight1]

Although on reflection I suppose doing it this way gives you an unbiased sample from the space of valid target_area + aspect ratio pairs, and you'd need to handle things quite carefully to make that the case if you constrained the random rolls to always be valid.

[Rocketknight1]

I haven't looked at our image models too much, but I'm guessing that the scaling factors feature_extractor.image_mean and feature_extractor.image_std were also computed after division by 255? It seems odd to normalize the scale twice like this.

[amyeroberts]

Exactly. It's pretty standard to have the values this way in vision - most of our image_mean and image_std values are constants from e.g. imagenet. I think it comes down to being able to use floats - if I found the mean on my R pixels was 134.7 how should I take it away from the pixel values when they're still uint8?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the contributing guidelines are likely to be ignored.

[Rocketknight1]

Hey @amyeroberts, is this PR still going ahead? It looked almost ready!

[amyeroberts]

@Rocketknight1 Yes - sorry, this fell down my priority list for a bit. Code is all ready to go - I was trying to find models that make the tests run quickly c.f. this comment.

[Rocketknight1]

@amyeroberts Ah, that makes sense! It's totally okay to upload your own super-mini model and use that - it doesn't really matter if the accuracy is bad, the test will just let us detect if the outputs from this model class change suddenly

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the contributing guidelines are likely to be ignored.