Max Ehrlich
Max Ehrlich
Yes I was able to get a correct implementation of both without needing the extra dependency
I would say [0, 1] is the most common thing although I have seen [-1, 1] in the context of GANs
I buy that argument The only issue I can think of is that it would break backwards compatibility if it stopped accepting images in [0, 255] There's nothing about generation...
Is this procedure too fancy: * If the image has dtype torch.byte then assume [0, 255] * If the image has dtype any float type *and* normalize is false, assume...
The more I think about it the more I think that no one in their right mind is trying to evaluate their GANs using byte images. Also you're allowed to...
Actually now that I think about it why is the implementation even using something that was trained in byte inputs? Was there any justification for it by the original implementer?...
Ah, the answer is that it immediately converts them to float images in [-1, 1] https://github.com/toshas/torch-fidelity/blob/master/torch_fidelity/feature_extractor_inceptionv3.py#L96 That's not great, if it's going to do that why bother forcing byte inputs...
> I think we should be able to install vmaf as an python library based on the description here Yes we could try that but how do we specify it...
let me see if that works, and as long as you're ok with having a git dependency
Alright then I'll give this a go and get back to you