gen-tests-mk: distribution of j90randomsizej80 resolutions

[swesterfeld]

I ran j90randomsizej80 on about 1000 images, and generated a histogram of the sizes. For each images in the attack, I used the minimum of width and height as value for the histogram. For instance, a 500x400 image would "count as" 400px image, because the detection algorithm problems are to be expected on the smaller dimension.

This is not what I expected to see. I thought that most images would be > 500px and practically no image would be < 400px.

I also saw that j90randomsizej80 supposedly should change the aspect ratio of the input images.

imagewmark/tests/gen-tests-mk

Line 101 in de200a2

# Generate 2D resolutions based on the resolution areas and aspect ratio range

Seems that it doesn't (which may be part of the problem why the distribution is not correct).
Seems that using convert input.jpg -resize 200x200 output.jpg (or similar) doesn't change the aspect ratio.

However what I would really like to test here is random resizing while maintaining aspect ratio, so either we should make j90randomsizej80 do this, or we should have two attacks, one with and the other without aspect ratio change.

Tools:

Find minimum size (min (width, height)) of each image:

#!/bin/bash
# shell script: min-width.sh
for i in $(find . -iname *.json)
do
  egrep '(width|height)' $i | sed 's/[":,]//g' | awk '$1 == "width" {w=$2;} $1 == "height" {h=$2;}END{if (w<h){print w;}else{print h}}'
done

Gnuplot script:

set terminal pngcairo size 800,600 enhanced font 'Verdana,10'
set output 'hist.png'
binwidth=20
bin(x,width)=width*floor(x/width)
plot '<./min-width.sh' using (bin($1,binwidth)):(1.0) smooth freq with boxes

[swesterfeld]

Btw, looking at the results of the j90randomsizej80 test suite run, I get only 14.8% failed images (85.2% match). To be honest, that is not the result I expected from the distribution of the resolutions of the test images.

I thought we would have issues for everything below 512px, but the test suite results don't seem to confirm this.

[tim-janik]

Thanks for pointing this out.
I'll change the convert -resize $SIZE command in the test suite to include a bang: convert -resize $SIZE!
That way the resize will preserve the number of pixels but change the aspect ratio, that was the original intention of the tests.

When it comes to the distribution, you need to use sqrt(w*h) as the dimension of interest, because at the end the pixel budget is what counts when it comes to measuring how large the payload+redundancy is that can "fit" into an image.

I.e. in the following three cases we want to roughly embed the same amount of information+redundancy:

Wide Image, pixel budget for 4x WM tiles, e.g. 512*128:
+-+-+-+-+
| | | | |
+-+-+-+-+
Square Image, pixel budget for 4x WM tiles, e.g. 256*256:
+-+-+
| | | 
+-+-+
| | |
+-+-+
Tall Image, pixel budget for 4x WM tiles, e.g. 128*512:
+-+
| |
+-+
| |
+-+
| |
+-+
| |
+-+

That actually still needs a fix applied here, to use the same ZOOM factor for all three cases:

src/embed.py:155: ZOOM = min (face.shape[1], face.shape[0]) / Lwsmall / dynamic_zoom