@@ -928,5 +928,65 @@ def test_decode_avif(decode_fun, scripted):
928
928
assert img [None ].is_contiguous (memory_format = torch .channels_last )
929
929
930
930
931
+ @pytest .mark .xfail (reason = "AVIF support not enabled yet." )
932
+ # Note: decode_image fails because some of these files have a (valid) signature
933
+ # we don't recognize. We should probably use libmagic....
934
+ # @pytest.mark.parametrize("decode_fun", (_decode_avif, decode_image))
935
+ @pytest .mark .parametrize ("decode_fun" , (_decode_avif ,))
936
+ @pytest .mark .parametrize ("scripted" , (False , True ))
937
+ @pytest .mark .parametrize (
938
+ "mode, pil_mode" ,
939
+ (
940
+ (ImageReadMode .RGB , "RGB" ),
941
+ (ImageReadMode .RGB_ALPHA , "RGBA" ),
942
+ (ImageReadMode .UNCHANGED , None ),
943
+ ),
944
+ )
945
+ @pytest .mark .parametrize ("filename" , Path ("/home/nicolashug/dev/libavif/tests/data/" ).glob ("*.avif" ))
946
+ def test_decode_avif_against_pil (decode_fun , scripted , mode , pil_mode , filename ):
947
+ if "reversed_dimg_order" in str (filename ):
948
+ # Pillow properly decodes this one, but we don't (order of parts of the
949
+ # image is wrong). This is due to a bug that was recently fixed in
950
+ # libavif. Hopefully this test will end up passing soon with a new
951
+ # libavif version https://github.com/AOMediaCodec/libavif/issues/2311
952
+ pytest .xfail ()
953
+ import pillow_avif # noqa
954
+
955
+ encoded_bytes = read_file (filename )
956
+ if scripted :
957
+ decode_fun = torch .jit .script (decode_fun )
958
+ try :
959
+ img = decode_fun (encoded_bytes , mode = mode )
960
+ except RuntimeError as e :
961
+ if any (
962
+ s in str (e )
963
+ for s in ("BMFF parsing failed" , "avifDecoderParse failed: " , "file contains more than one image" )
964
+ ):
965
+ pytest .skip (reason = "Expected failure, that's OK" )
966
+ else :
967
+ raise e
968
+ assert img [None ].is_contiguous (memory_format = torch .channels_last )
969
+ if mode == ImageReadMode .RGB :
970
+ assert img .shape [0 ] == 3
971
+ if mode == ImageReadMode .RGB_ALPHA :
972
+ assert img .shape [0 ] == 4
973
+ if img .dtype == torch .uint16 :
974
+ img = F .to_dtype (img , dtype = torch .uint8 , scale = True )
975
+
976
+ from_pil = F .pil_to_tensor (Image .open (filename ).convert (pil_mode ))
977
+ if False :
978
+ from torchvision .utils import make_grid
979
+
980
+ g = make_grid ([img , from_pil ])
981
+ F .to_pil_image (g ).save ((f"/home/nicolashug/out_images/{ filename .name } .{ pil_mode } .png" ))
982
+ if mode != ImageReadMode .RGB :
983
+ # We don't compare against PIL for RGB because results look pretty
984
+ # different on RGBA images (other images are fine). The result on
985
+ # torchvision basically just plainly ignores the alpha channel, resuting
986
+ # in transparent pixels looking dark. PIL seems to be using a sort of
987
+ # k-nn thing, looking at the output. Take a look at the resuting images.
988
+ torch .testing .assert_close (img , from_pil , rtol = 0 , atol = 3 )
989
+
990
+
931
991
if __name__ == "__main__" :
932
992
pytest .main ([__file__ ])
0 commit comments