Re: [ARMini-support] Jcut

  • From: Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx>
  • To: armini-support@xxxxxxxxxxxxx
  • Date: Mon, 21 Apr 2014 14:38:29 +0100

The following bytes were arranged on 21 Apr 2014 by Chris Bell (Lists):

> (What is a 'binary' by the way?  Can I use it 'as is' or does it need
> some sort of 'compliling' first?)

A binary is what you get after having compiled the source code.  So no,
you don't need to compile it again.  And yes, you can use it as is, this
being the very purpose of a binary.

> Versions:  !Jcut 3.01 (Sun 06th October 2002)
>            jpegtran 104k 15:40:58 31 Jan 2013

Hmm, that's odd.  On closer inspection, I discovered that I was, in
fact, using a version of jpegtran from 22 Dec 2011.  I have no idea
where I got it from.

Anyway, I think I've managed to work out the problem.

Here is the output from the 2011 version upon being called with no (or
invalid) arguments:

usage: jpegtran [switches] inputfile outputfile
Switches (names may be abbreviated):
  -copy none     Copy no extra markers from source file
  -copy comments Copy only comment markers (default)
  -copy all      Copy all extra markers
  -optimize      Optimize Huffman table (smaller file, but slow compression)
  -progressive   Create progressive JPEG file
Switches for modifying the image:
  -grayscale     Reduce to grayscale (omit color data)
  -flip [horizontal|vertical]  Mirror image (left-right or top-bottom)
  -rotate [90|180|270]         Rotate image (degrees clockwise)
  -transpose     Transpose image
  -transverse    Transverse transpose image
  -trim          Drop non-transformable edge blocks
Switches for advanced users:
  -restart N     Set restart interval in rows, or in blocks with B
  -maxmemory N   Maximum memory to use (in kbytes)
  -outfile name  Specify name for output file
  -verbose  or  -debug   Emit debug output
Switches for wizards:
  -scans file    Create multi-scan JPEG per script file

And here is the output from the 2013 version, i.e. what you see in the
command window after Jcut fails:

usage: jpegtran [switches] inputfile outputfile
Switches (names may be abbreviated):
  -copy none     Copy no extra markers from source file
  -copy comments Copy only comment markers (default)
  -copy all      Copy all extra markers
  -optimize      Optimize Huffman table (smaller file, but slow compression)
  -progressive   Create progressive JPEG file
Switches for modifying the image:
  -crop WxH+X+Y  Crop to a rectangular subarea
  -grayscale     Reduce to grayscale (omit color data)
  -flip [horizontal|vertical]  Mirror image (left-right or top-bottom)
  -perfect       Fail if there is non-transformable edge blocks
  -rotate [90|180|270]         Rotate image (degrees clockwise)
  -scale M/N     Scale output image by fraction M/N, eg, 1/8
  -transpose     Transpose image
  -transverse    Transverse transpose image
  -trim          Drop non-transformable edge blocks
Switches for advanced users:
  -arithmetic    Use arithmetic coding
  -restart N     Set restart interval in rows, or in blocks with B
  -maxmemory N   Maximum memory to use (in kbytes)
  -outfile name  Specify name for output file
  -verbose  or  -debug   Emit debug output
Switches for wizards:
  -scans file    Create multi-scan JPEG per script file

Now for a little game of spot-the-difference.

The 2013 version has clearly had features added to it - but how is this
preventing it from recognising a command line which worked before?

The breakthrough came after I used Reporter to force Jcut to divulge
exactly what format of command line it was using.  The result was
something in this format:

<Jcut$Dir>.jpegtran -c all -restart 1b  -maxmemory 28672 <inputfile> <scrapfile>

So I tried that with the 2011 and 2013 binaries, and lo and behold, it
worked and didn't work, respectively.

Then I tried altering the "-c all" part of the above line to the more
verbose "-copy all".  And it worked!

It turns out that the authors made a bad decision when they added a
switch called "-crop" to the arguments.  You see that bit up the top
where it says "(names may be abbreviated)"?  Well, actually taking this
advice whenever you see it is almost always a bad idea, and this episode
illustrates why.

Formerly, there was only one switch beginning with C, which was "-copy",
and so Jcut could use this without fear of ambiguity.  But now there are
two - and, in a stunningly stupid move, the new one takes precedence
over the old one, meaning "-c" now means "-crop" rather than "-copy",
hence breaking command line compatibility with the old versions!

To fix this, you can open the Jcut !RunImage (which is uncompressed
BASIC, positively inviting you to edit it).  Search and replace the
string "-c" with "-copy" - this should score 8 hits, and no more or
less.  Then save (take a backup if you're paranoid).

I did this, and it enabled Jcut and the new jpegtran to happily coexist.
I haven't tested it very thoroughly, but the base functionality appears
to be there.

Of course, all this does raise the question of how exactly Jcut was
cropping JPEGs years before the jpegtran utility had any internal
support for doing so, but I think I'd rather not worry about that...

-- 
  __<^>__   === RISC OS is a work of art.  Some people adore it,  ===
 / _   _ \  === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive.                                        ===
 \_>   <_/  ======================= Martin Bazley ===================
---
To alter your preferences or leave the group, 
visit //www.freelists.org/list/armini-support
List-related queries to info@xxxxxxxxxxxx

Other related posts: