Suppose that you have a thumbnail and the original image from which it was generated. You need to match the thumbnail to an area in the original image that represents the original selection from which that thumbnail was generated. Humans are really good at this sort of matching, but I have no idea how to go about writing an algorithm to do this automatically.
Here are my thoughts on the matter so far:
- A thumbnail is created by first cropping then scaling the original selection. Logically, some scaling is required to reverse the process.
- A thumbnail's dimensions could be greater than that of the original selection. Therefore, this algorithm should account not only for the common downscaled thumbnails, but also for cases where the cropped original selection has been upscaled to the thumbnail's intended dimensions.
- Theoretically, it is possible that a thumbnail was generated such that the entire original image was encompassed inside the original selection, akin to
background-size: containin CSS. All four corners of the original selection thus fall outside of the original image. The extra space could have been filled either with a solid color (possibly transparent) or with Photoshop's Content Aware Fill or a similar algorithm (inpainting). This is an edge case; however, an ideal reverse-thumbnail algorithm should be able to handle such cases.
- This algorithm should return the
x,ypixel coordinates of the top-left corner of the original selection as it falls on the original image, as well as the
lengthof the selection.
I've put together a sample set of 30 images from my current project for testing potential algorithms. I tried to include a variety of images to challenge any feature-recognition approach. All selections in this collection have been downscaled to the intended thumbnail size of
300x300 after cropping. I included an
info.csv, which contains
id,x,y,w,h representing the coordinates and dimensions of the original selection relative to the full-sized image. These values were obtained by applying Deep Zoom coordinates saved from the source
tiff files to the
full images. Due to floating point inaccuracy,
h differ by one pixel in three cases (
13, 17, 21). These images were included intentionally to test how your algorithm might handle accuracy concerns. A second
info_ur.csv includes unrounded values for reference.
Download test images: https://app.box.com/s/65240dlgvfvevw2grhyaqqjjc29jzv65
Finally, here's an illustration of the four cases such an algorithm might encounter: