mirror of
https://github.com/openai/CLIP.git
synced 2026-11-05 01:37:26 +00:00
[GH-ISSUE #115] Retrieval results on COCO validation dataset #104
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
openai/CLIP#104
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mabravo641 on GitHub (Jun 9, 2021).
Original GitHub issue: https://github.com/openai/CLIP/issues/115
Thank you for the code.
I have run the different models available and tested on COCO captions 5k validation set for retrieval using the first single caption and the results are good but still not close to the reported in the paper. Which architecture was used for that experiment (Table 13.)? I am posting the implementation of this Zero-shot retrieval evaluation.
Paper CLIP (Table 13)
i2t - 'r1': 58.4, 'r5': 81.5, 'r10': 88.1
t2i - 'r1': 37.8, 'r5': 62.4, 'r10': 72.2
Code Results:
RN50
i2t - 'r1': 31.82, 'r5': 56.56, 'r10': 67.44, 'r50': 89.86, 'medr': 4.0, 'meanr': 21.4242, 'sum': 155.82
t2i - 'r1': 27.40, 'r5': 51.52, 'r10': 62.28, 'r50': 87.14, 'medr': 5.0, 'meanr': 31.1382, 'sum': 141.2
RN101
i2t - 'r1': 32.22, 'r5': 57.7, 'r10': 68.2, 'r50': 90.46, 'medr': 4.0, 'meanr': 21.0626, 'sum': 158.12
t2i - 'r1': 28.26, 'r5': 52.64, 'r10': 63.3, 'r50': 87.78, 'medr': 5.0, 'meanr': 30.8762, 'sum': 144.2
RN50x4
i2t - 'r1': 34.8, 'r5': 59.38, 'r10': 70.76, 'r50': 91.44, 'medr': 3.0, 'meanr': 19.715, 'sum': 164.94
t2i - 'r1': 30.84, 'r5': 54.76, 'r10': 65.6, 'r50': 88.98, 'medr': 4.0, 'meanr': 29.3306, 'sum': 151.2
ViT-B/32
i2t - 'r1': 32.56, 'r5': 57.98, 'r10': 68.24, 'r50': 90.48, 'medr': 4.0, 'meanr': 20.0076, 'sum': 158.78
t2i - 'r1': 28.42, 'r5': 53.1, 'r10': 64.16, 'r50': 88.3, 'medr': 5.0, 'meanr': 27.6856, 'sum': 145.68
Thanks,
MA
@jongwook commented on GitHub (Jun 30, 2021):
CLIP metrics on Table 13 (and many others) refer to the largest CLIP model of ViT-L/14 fine-tuned at 336px, following this sentence in Section 2.5:
Apologies about the models not being publicly available yet - The team is still working on the plan, but I'm hoping all models will eventually be available, like GPT-2 did.
@justlovebarbecue commented on GitHub (Jun 8, 2022):
Hi @mabravo641 @jongwook ,
Thanks for your issue and comments! I tried the updated ViT-L/14@336px for zero-shot evaluation using coco. But still get low performances which are close to what Maria posted.
I used Maria's zero-shot script with both single_caption = True and False. Both are relatively low.
Do you have any clue to reproduce the results in Tab.13?
Thanks!
@Neltherion commented on GitHub (Mar 12, 2023):
@mabravo641 Hi, I wanted to ask if the code you're using is originally written by yourself to test the Image Retrieval capabilities of CLIP or was it used from some other place?
I'm looking for an
Image Retrieval on COCOcode that is considered the standard approach and I'm not even sure if some code like that exists or every researcher in this field implements it themselves (which could add to discrepancies between results).Thanks!
@zzbuzzard commented on GitHub (Mar 26, 2023):
For what it's worth, I tested this using my own independent code and was able to (approximately) reproduce the results. I get the following values for ViT-L/14@336px on the COCO 5k val set:
text-to-image
R@1 = 36.10% (vs 37.8% in the paper)
R@5 = 60.75% (vs 62.4% in the paper)
R@10 = 70.75% (vs 72.2% in the paper)
image-to-text
R@1 = 57.48% (vs 58.4% in the paper)
R@5 = 80.32% (vs 81.5% in the paper)
R@10 = 87.60% (vs 88,1% in the paper)
The paper does state the following (page 45):
Implementing this change gave me values of 57.94 / 81.50 / 88.42 for image-to-text retrieval (even closer to the paper), but seemed to slightly reduce my text-to-image retrieval scores.
So, I would attribute the differences to either some other minor tricks like this that they used to slightly improve performance, or simply differences in implementation - it's not totally obvious how to handle the one-to-many relationship between images and captions.
(unfortunately I am not able to share my code, as it is part of an ongoing assessed project)
@Neltherion I was also hoping to find some commonly used definition, for example in the
torchmetricslibrary (for example, there seems to be a standard definition for mean average precision), but failed to find one.@Neltherion commented on GitHub (Mar 31, 2023):
@zzbuzzard Thanks. Is it possible for you to upload your own independent code for me to test?
I'm really wondering if there even is a formal code to evaluate Retrieval tasks or not?
@Neltherion commented on GitHub (Apr 1, 2023):
@zzbuzzard Oh! I just saw the part you mentioned why you can't share your code! Either way, Thanks for the info😉
@nimakasipour commented on GitHub (Apr 1, 2023):
@zzbuzzard I am looking forward to reproducing this result on coco 5k val, but still not close to text retrieval after adding the prompt "a photo of " to text description. Could you please give us some tips maybe what could be different from the code provided by @mabravo641
@zzbuzzard commented on GitHub (Apr 1, 2023):
@Neltherion @nimakasipour ok! I spent a while extracting it from the rest of my codebase (hopefully I won't get flagged by plagiarism checkers for this haha) but here's my script. I am able to run exactly this to get the following output:
I am running on 6GB GPU VRAM and this code certainly uses a decent amount of it - if you have memory issues you can try editing it (you only really need things on the GPU when evaluating CLIP, you could immediately move the result to CPU, but will need to cast to float32 as I believe CPU support for float16 is limited) or computing the whole thing on the CPU (this would be insanely slow though).
I don't have the time to compare to the code at the top of this issue, so I'm not sure why we're producing different answers, but this version seems to replicate the paper's results. It's not perfect, and I haven't properly tested it, but I hope this helps!
@nimakasipour commented on GitHub (Apr 1, 2023):
@zzbuzzard I greatly appreciate you sharing the code! It provided a straightforward and intriguing approach to evaluating the performance of CLIP. Through this evaluation, I could identify the source of my problem. It turns out that associating a single caption for each image led to poorer results in the text retrieval task. (20% less for each metric)
I had also noticed a minor decrease in performance for image retrieval tasks when I added the prompt "a photo of" to the image descriptions using my code with "ViT-L/14@336px" before adding "R@1= 33.88, RQ5=58.5, R@10 =69.32, R@50 = 90.66, and MeanR = 24.26". After adding the prompt "a photo of ", the results were "R@1 = 33.44, RQ5 = 58.36, R@10 = 69.42, R@50 = 90.58, and MeanR = 24.50". However, a slight improvement in the Text retrieval task (where each image was associated with one/first caption)
@lerogo commented on GitHub (Jun 28, 2023):
text-to-image
R@1 = 37.68% (vs 36.10% (vs 37.8% in the paper))
R@5 = 62.10% (vs 60.75% (vs 62.4% in the paper))
R@10 = 71.87% (vs 70.75% (vs 72.2% in the paper))
image-to-text
R@1 = 56.26% (vs 57.48% (vs 58.4% in the paper))
R@5 = 80.22% (vs 80.32% (vs 81.5% in the paper))
R@10 = 87.32% (vs 87.60% (vs 88,1% in the paper))