Open davidschlangen opened 5 years ago
So the upshot is: The dataframes should not use the split-into-imageID trick, but rather add split and category explicitly. (And so, it should be removed from preproc.) The feature file will still have to use it.
Problem: For ADE20k, our usual way of denoting an image through an image_id doesn't work. First, the images are inside of a nested structure, which cannot be predicted from the image id. E.g.,
ADE_train_00000994.jpg
is to be found intraining/a/abbey/
. Second, the same image ID may occur intraining/
and intesting/
.(Actually, I'm not so sure now anymore whether the imageID, which ultimately is coming from
index_ade20k.mat
, is the number in the filename. But I am fairly certain that the image_id that we used was non-unique w/o the split.)So even knowing the split (which could be encoded into the image_id, by adding a constant number so that everything beyond that is from split B) is not enough to get the image; for that you need to know the category as well.
This problem surfaces at two places. During extraction, going through a dataframe like
ade_objdf
, as it is at the moment, is not enough, because that doesn't have the image category and the split. (Actually, it does have the split, as that is encoded into the image id.) So to get the image, one would need to load a different structure that goes from image id + split to the fully qualified path.It is also a problem for our usual encoding of the image in the feature file, where we have only three numerical fields. This constraint makes it necessary to encode the split info (which minimally is needed to disambiguate the image_id) into the image id.
Possible solution:
(But the API to
get_image_filename
should be cleaned up in any way, andsplit
andcategory
should be made into keyword arguments that are passed along toget_ade_filename
.)