Work around jpegtran to get correct rotated crops.

[ConradHughes]

Hi Jeff, so — seem to have cracked this without modifying libjpeg-turbo: even though jpegtran doesn't seem to quite understand what it's doing, using an additional 'f' specifier on dimensions in the crop strings allows production of correctly sized rotated cropped images that (over a few manual tests) are identical to what you can produce using a pipeline of '-perfect' invocations of jpegtran. This minor change means cropgtk supports the full range of behaviour that you'd expect from the standard: no matter how the input image is rotated, perfect and correctly-sized outputs are generated with ICMU-aligned top-left corners and arbitrary bottom right corners. Yay!

Thanks again..

[ConradHughes]

Notes for future changelog:

* Add key controls:
  - q to quit
  - n for next image
  - s to save current crop but remain on this image
* Improved output filename handling (particularly for 's' above).
* Overwrite confirmation.
* Correct crop edge rounding vs rotation.

[jepler]

Thanks! Are you interested in having collaborator access on this repo?

[ConradHughes]

Are you interested in having collaborator access on this repo?

Sure, thanks — I've largely scratched my itch with these patches, but I use cropgui all the time, so am certainly up for helping keep it going if I can..

[howff]

You mention cropgtk -- does the non-GTK gui need to be modified as well?

Also I notice some calls to thumbnail.thumbnail((drag.w/scale, drag.h/scale)) use only a single slash, should they use a double slash for python3 to get correct divide behaviour?

[ConradHughes]

Hi Howff, interesting question. On my machine the GTK one is what gets installed, so I'm unfamiliar with the non-GTK one. Not sure whether the control loop I modified is GTK only, but I suspect it is. I'll try to take a look at this, and at the thumbnail issue..

I also owe a bug fix, as the latest master misbehaves when invoked on non-JPG images due to jpegtran-specific switches.

[howff]

Thanks. I sent a PR to fix the non-JPG issue accidentally as part of the Preserve Previous Crop PR!

…

On Mon, 30 Nov 2020 at 11:03, ConradHughes ***@***.***> wrote: Hi Howff, interesting question. On my machine the GTK one is what gets installed, so I'm unfamiliar with the non-GTK one. Not sure whether the control loop I modified is GTK only, but I suspect it is. I'll try to take a look at this, and at the thumbnail issue.. I also owe a bug fix, as the latest master misbehaves when invoked on non-JPG images due to jpegtran-specific switches. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXMD7DXQ3TCUFEM535DEQ3SSN3WJANCNFSM4TTPE2FA> .

[howff]

Is ConradHughes getting committer access to approve pull requests?

[ConradHughes]

Hi Howff, I believe I have permission to do that — I'm sorry I've not got around to looking at your pull request yet, and thank you very much for submitting it! It's high on my to-do list now (I'm sure I'm at least as annoyed by the bug as you are) but the last couple of weeks have been a bit hectic.