Mathematically, you can consider a file of bytes to be a Base 256 encoding of an integer. For example if the file contained just the bytes 241 217 (decimal) then that could be considered to mathematically be a representation of 241*256+217... whatever that number happens to work out as.
The unary representation of a number requires taking that many copies of a symbol in a row. For example if the value is 19 then the unary would be 19 copies of a symbol. Like ::::::::::::::::::: or 1111111111111111111. The end of the number is marked by the sequence stopping. The value represented is determined by counting the number of symbols.
Pure unary is only able to represent one number per universe. To represent two different numbers you would need to mark the boundary between the unary sequences, which requires a second symbol.
The smallest input image file you can have is one byte, which could represent a single grayscale pixel with intensity 0 to 255. (Or could represent a single pixel rgb image with 3 bits of red information, three green, and two bits of blue.)
You cannot write out less than 8 bits to a file, so input bytes in the range 1 to 8 require at least a single byte of output, and input bytes of value 9 and up require more output bytes when represented in unary. Therefore you cannot compress anything using a unary encoder.
Exception: if your input image consisted of a single pixel with value 0, then the unary encoding of it would be the empty file, which is indeed smaller. This is the only case that you can compress using unary.