Add file size target option.

[X-Ryl669]

This is incompatible with target quality option obviously. Typically, I'm streaming the picture to some web client, and and want to make sure the time to fetch the picture is known whatever the quality of the picture.

[X-Ryl669]

AppVeyor build failure is not due to my changes, seems like it's not configured correctly?

[lfos]

Hi, I am currently going through old PRs and trying to get them merged. I like the idea behind your patch and think it is a nice feature to have. Do we even need to run the comparison algorithms if we only aim for a given target file size? Are they only run to have information on how much the (visual) quality was reduced?

I did not have a detailed look at the implementation itself. I realized that with your current code, one cannot use target file size and exactly 6 bisection steps which should be fixed, though.

Thanks for working on this!

[X-Ryl669]

The algorithm I've implemented was naïve. Typically, the code set a target quality, check the resulting size, adjust the quality compared to how far we are from the expected size and loop. I've increased the maximum number of attempts to 12 (so even if after 12 attempts, it fails to reach the given size, it exits). There is obviously a range around which the software stops, and if I remember correctly, it's -10% + 10% the expected size.

[lfos]

What I was trying to say is that with you implementation, one cannot use the -l argument to manually set the number of steps to 6. Using -l 6 results in 12 steps being performed.

[X-Ryl669]

True, if you specify -l 6 it's increased to 12, but if you specify anything else it's kept as specified. From my own testing, 6 attempts are not enough but 6 being the default, I've tried to fix it (badly). I guess the code that's changing it should detect if the user used the command line and avoid modifying in that case.

[lfos]

Do you plan on working on this and addressing the issue I mentioned?