Allow opj_compress and opj_decompress to read/write images over stdin/stdout

[gcode-importer]

Originally reported on Google Code with ID 224

What steps will reproduce the problem?
1.piping openjepg with another applivcation BEFORE it
2.application sent picture to STDOUT
3.image_to_j2k do not recognize pipe input

What is the expected output? What do you see instead?
expected output is j2c image. Instead in case of "-" as input say unrecognized file,
without -i option say must have input image in PNG,TIFF.....

What version of the product are you using? On what operating system?
version 2.0 windows 7 64 bit

Please provide any additional information below.
convert image.tiff -(somefilter) rgb:- |image_to_j2k -i - -o output.j2c 
this pipe do mot work

Reported by rado.markov on 2013-06-08 15:35:45

[gcode-importer]

You use version 2.0 of the library, but version 2.0 does
not contain 'image_to_j2k' but 'opj_compress'.

  opj_compress -i infile.EXT -o outfile.EXT
or
  image_to_j2k -i infile.EXT -o outfile.EXT

Both test the outfile extension: JP2, J2k, etc

and decide whether the outfile should be done.

Both test the infile extension: PNG, BMP, etc

and decide which conversion function should be called:
pngtoimage, bmptoimage, etc.

The pipe stream does not contain an extension that
can be tested.

One could perhaps add a special input file name, e.g.

  '-i pipe:PNG' or '-i pipe:png'

to call pngtoimage.

winfried

Reported by szukw000 on 2013-07-13 19:41:16

[gcode-importer]

cat file7.png  | bin/opj_compress -i pipe:png -o file7.j2k

[INFO] tile number 1 / 1
Generated outfile file7.j2k

---------------
CHANGES
---------------

convert.c:
===============

pngtoimage(const char *read_idf, opj_cparameters_t * params)
{
    int piped = 0;

    if(strcmp(read_idf, "pipe:png") == 0)
   {
    reader = stdin; piped = 1;
   }
    else
    if((reader = fopen(read_idf, "rb")) == NULL)
   {
    fprintf(stderr,"pngtoimage: can not open %s\n",read_idf);
    return NULL;
   }

}


opj_compress.c:
===============

static int get_file_format(char *filename)
{
    char *ext = strrchr(filename, '.');

    if (ext == NULL)
     ext = strrchr(filename, ':');

    if(ext == NULL) return -1;

    ++ext;

}


winfried

Reported by szukw000 on 2013-07-13 20:41:21

[gcode-importer]

In the above sketch add at the very end of pngtoimage():

    if(!piped) fclose(reader);

winfried

Reported by szukw000 on 2013-07-14 05:38:37

[gcode-importer]

Reported by malaterre on 2014-02-24 17:25:27

• Labels added: Priority-Low
• Labels removed: Priority-Medium

[gcode-importer]

Issue 379 has been merged into this issue.

Reported by mayeut on 2014-10-23 21:34:56

[gcode-importer]

Renamed to add opj_decompress & writing over stdout

Reported by mayeut on 2014-10-23 21:36:09

• Labels added: Type-Enhancement
• Labels removed: Type-Defect

[gcode-importer]

The absence of file extension can easily be overcome by using magic numbers. They are
much more reliable than file extensions anyways.

Reported by njdoyle on 2014-10-23 22:03:55

[adolski]

+1 as this will enable the use of opj_decompress with Java's ProcessBuilder (and streams to/from arbitrary sources) without the hassle of JNI. Interestingly, doing something like this actually works, from the command line at least:

ln -s /dev/stdin stdin.jp2
ln -s /dev/stdout stdout.bmp
opj_decompress -i stdin.jp2 -o stdout.bmp < source.jp2 > result.bmp

I've not been successful getting it to work with ProcessBuilder though.

[jronallo]

Yes, this would be a nice feature and, though not a performance gain for opj_decompress, would be for applications that use it.

[jpstroop]

If it helps in the meantime, I've used a named pipe when I've needed to do this in the past.

[kamermans]

I see this issue was closed, along with its merged duplicate issues, and I see this in the changelog:

- Allow opj\_compress and opj\_decompress to read/write images over stdin/stdout [\#379](https://github.com/uclouvain/openjpeg/issues/379)

What I do not see, however, is any evidence in the code or documentation that this is possible. I'm using a version that I compiled today from master at commit level 66297f07a43d2770a97c8456d20202f3d051d980.

Can someone please correct me if I'm wrong? If I am wrong, and you can use STDIN (ex: -i -:bmp) and STDOUT (ex :-o -:jp2), then I'm happy to submit a PR with the updated documentation for opj_compress and opj_decompress.

Note: I do see code in opj_decompress (line 498, infile_format()) that attempts to identify the input file via magic numbers, which makes sense to me, so perhaps automatic type detection is only supported for this argument.