JPEGCrops - Suggestions

I won't make any significant changes to JPEGCrops. Instead I'm working on its successor, which will (probably) be named RoboCrop. It will be a complete rewrite, in order to make it possible to do things like red-eye removal and image resize. It will also be freeware and the interface will be roughly the same as JPEGCrops.

Feel free to make suggestions for RoboCrop features or report bugs for JPEGCrops. If you want an answer to a specific problem, send me an email at darkwing@daimi.au.dk.

Please take a look at the future page before posting. What you want might be on the wish-list already. You might also want to view the old suggestions.

Toke Eskildsen

2011-10-06 09:16

Synchronize Crops is (much too) picky: It requires all images to be of the exact same width and height in pixels.

David-Paul

2011-10-06 23:38

Aha... Ok, that's why
isn't there any workaround to save the selection area??

Toke Eskildsen

2011-10-07 07:33

Only by doing an initial cropping round to a pixel-defined static crop size. It is a bit of a blocker for real solutions that I do not use Windows anymore. I would like to get the development IDE (Delphi) up and running again, but it is not-trivial so no ETA.

Ludovic

2012-04-21 18:28

Starting from a picture of 4272x2848, when I press the key "-", JPEGCrops decreases the size to 4264x2842 that is NOT a multiple of 16.
I crop/save the picture and reload it with XnView -> the saved picture size is really 4264x2842. Thus I wonder how the picture has been saved without quality loss?...
Is it a bug or do I misunderstand the answer of your FAQ "Can I crop as I like?"?
Thanks for your software.

Toke Eskildsen

2012-04-21 20:52

The 16 pixel limitation is only for the coordinates of the upper left corner. A JPEG consists of blocks of 8x8 or 8x16 pixels (16x8 and 16x16 are also possible, but uncommon) and a crop is basically a copy of the relevant blocks.

The bottom and the right hand size do not have to be at multiples of 8 or 16 though, just as the size of a standard JPEG do not need to be such multiples. Technically the right hand side and the bottom blocks are always there in full 8 or 16 pixel size, but an attribute states how many of the pixels that are to be shown. Unfortunately no such attribute exists for the left and top side - if it did, there would be no restrictions at all on the cropping area.

As for assurance of losslessness, I refer you to jpegtran. It is the tool used underneath JPEGCrops and in contrast to my buggy program, jpegtran is a solid piece of software. Its codebase is used in a lot of different programs and has thus been tested thoroughly.

Ludovic

2012-04-21 23:44

Thank you for your quick answer.
I didn't know the existence of the attribute that "states how many of the pixels that are to be shown". Now it is perfectly clear.

Dennis McGrath

2012-05-04 22:54

This tool is exactly what we needed for repetitive work.
I love that it remembers the source and target directories.

I know you are not working on this anymore but I just had to mention that the ONLY thing we miss is a “square” option, like free but always square.

It would then do everything we need.

As it is, we have to carefully adjust the crop.
It's hard to get it exact.

Dennis McGrath
dmcgrath@qmiusa.com

Toke Eskildsen

2012-05-05 20:52

You can add your own aspects. A square would be a fixed aspect of 1x1, units optional and depending on your intended usage: If you're goint to print the image, you probably want units.

JPEGCrops suggestions