gdal_translate using /vsistdin/ and /vsistdout/ to pipe commands

Question

I am trying to pipe some of my commands with gdal_translate's output. These commands should read from standard input, so I'm writing to /vsistdout/. However, I am getting some errors. To be a bit more generic, I tried some other commands to illustrate the issues I face:

$ gdal_translate -of JPEG2000 Lenna.png /vsistdout/ | gdal_translate -of PNG /vsistdin/ Lenna01.png
ERROR 6: Read or update mode not supported on /vsistdout
ERROR 3: Unable to create file /vsistdout/.

ERROR 4: `/vsistdin/' not recognised as a supported file format.

GDALOpen failed - 4
`/vsistdin/' not recognised as a supported file format.

However, the following works:

$ gdal_translate -of JPEG Lenna.png /vsistdout/ | gdal_translate -of PNG /vsistdin/ Lenna0.png
Input file size is 512, 512
0...10...20...30...40...50...60...70...80...90...100 - done.

(In my tests, I am using my image format, which gets the same error as JPEG2000).
Is it that gdal_translate has a per-format support of the /vsistdout/ (and /vsistdin/) parameter?

Answer 1

From comparing the GeoTIFF format page:

Streaming operations

Starting with GDAL 2.0, the GeoTIFF driver can support reading or writing TIFF files (with some restrictions detailed below) in a streaming compatible way. When reading a file from /vsistdin/, a named pipe (on Unix), or if forcing streamed reading by setting the TIFF_READ_STREAMING configuration option to YES, the GeoTIFF driver will assume that the TIFF Image File Directory (IFD) is at the beginning of the file, i.e. at offset 8 for a classical TIFF file or at offset 16 for a BigTIFF file. The values of the tags of array type must be contained at the beginning of file, after the end of the IFD and before the first image strip/tile. The reader must read the strips/tiles in the order they are written in the file. For a pixel interleaved file (PlanarConfiguration=Contig), the recommended order for a writer, and thus for a reader, is from top to bottom for a strip-organized file or from top to bottom, which a chunk of a block height, and left to right for a tile-organized file. For a band organized file (PlanarConfiguration=Separate), the above order is recommended with the content of the first band, then the content of the second band, etc... Technically this order corresponds to increasing offsets in the TileOffsets/StripOffsets tag. This is the order that the GDAL raster copy routine will assume.

[...]

When writing a file to /vsistdout/, a named pipe (on Unix), or when definiting the STREAMABLE_OUTPUT=YES creation option, the CreateCopy() method of the GeoTIFF driver will generate a file with the above defined constraints (related to position of IFD and block order), and this is only supported for a uncompressed file. The Create() method also supports creating streamable compatible files, but the writer must be careful to set the projection, geotransform or metadata before writing image blocks (so that the IFD is written at the beginning of the file). And when writing image blocks, the order of blocks must be the one of the above paragraph, otherwise errors will be reported.

and the JPeg2000 page:

The driver uses the VSI Virtual File API, so it can read JPEG2000 compressed NITF files.

it seems that this is still being implemented on a format by format basis and that JP2K only supports read not write.