Comment 1 for bug 158435

The current plan is to write a binary which goes from jpg to jp2, does rotation (deskewing), cropping, and contrast enhancement along the way, and emits statistics of the distribution of values in the components.

Further, it may emit more than one jp2 (one being "OrigJP2" and another being some kind of "FinalJP2").

An input jpg can be read in through leptonica.

The rotation can be done by Leptonica's pixRotate() function as Raj currently does in mflm-rotate-am2.c (petabox/sw/books/microfilm).

The cropping can be done Leptonica's pixRasterop() function, defined in rop.c. It would be desirable to do this in-place, but i don't see a way to do this short of hand-coding it. I believe that to make everything maintainable we want to avoid hand-coding wherever possible, so will just use pixRasterop() as it stands (meaning that we have to do one extra allocation of pixels for the cropped output).

The contrast enhancement can be done by Leptonica's pixTRCMap() function, defined in enhance.c. (This will do the same kind of contrast enhancement we currently do using pnmnorm with the bvalue and wvalue options. The way it works in Leptonica is that you supply a map [i.e., 256 values] which is applied to the source to produce the destination. So if you want 30 and below to go to 0, and 240 and above to go to 255, then you just populate the map that way [with 31 through 239 being linearly remapped using a linear map sending 30 to 0 and 240 to 255].)

Statistics can be gathered while the Leptonica output is sent to the back end (where they all have to be touched anyway while being permuted). The statistics, per Hank, include the min, max, mean, and standard deviation of each channel.

Because we want multiple outputs, i plan for the program to take multiple sets of arguments, each set consisting of a rotation (if any), crop (if any), enhancement arguments (if any), request for statistics (if any), and output file name with backend arguments. So calling in general will be something like:
    program infile rotation/crop/enhancement/stats/output1 rotation/crop/enhancement/stats/output2 ...

All image-changing operations will be done in the order specified, and everything will be cumulative (to avoid any extra copy steps).

I think we'll probably end up using it like
    program output1 rotatation/crop/enhancement/stats/output2
where output1 is our OrigJp2, and output2 is our processed jp2, but it's easier to program it more generally so that we use one chunk of code repeatedly.

If anybody sees any problems with this approach, or has any advice or changes, please let me know.