Libvips: Vips CLI especifica el formato de archivo con tuberías
En imagemagick puedo leer y escribir en tuberías y especificar su formato:
cat in.jpg | convert JPG:- -resize 50% PPM:- | jpeg-recompress --ppm -q medium - out.jpg
En las herramientas vips cli, puedo usar /dev/stdin o /dev/stdout, pero no parece haber una forma de indicar el formato del archivo, lo que limita cuánto puede lograr usando canalizaciones en vips.
Sería genial si los vips permitieran especificar/anular el cargador/ahorrador para las imágenes de entrada y salida.
Ejemplo de sintaxis:
cat in.jpg | vips resize -[load=jpeg] -[save=ppm] 0.5 | jpeg-recompress --ppm -q medium - out.jpg
Esto también permitiría encadenar varias operaciones vips cli sin pagar la entrada/salida del disco para escribir en archivos .v.
felixbuenemann
Todos 4 comentarios
Hola Felix, se ha hablado un poco de esto, incluso hay una rama experimental con soporte para streams:
https://github.com/jcupitt/libvips/tree/load-from-stream
Puede ejecutar este programa en C:
https://gist.github.com/jcupitt/ff21f5b8d1dd6ba54c6f
Lee una serie de imágenes de un socket, las procesa y las envía a otro socket, todo sin tener que cargar la imagen completa. El objetivo era admitir depósitos de AWS, pero también funcionaría para canalizaciones de línea de comandos, con una pequeña cantidad de trabajo adicional.
Hubo una larga charla al respecto sobre este tema:
https://github.com/lovell/sharp/issues/30
Me di por vencido por un momento, luego se rompió, luego traté de limpiarlo, listo para fusionarme con el maestro, y encontré algunos problemas. Necesita un poco más de trabajo todavía :/
jcupitt
en 6 may. 2016
No estaba hablando de transmitir múltiples imágenes, aunque sería una característica interesante.
La idea principal es poder configurar el cargador o el protector (o más o menos el tipo de archivo), cuando no se puede inferir de la extensión del archivo. Estoy seguro de que hay más problemas para los tipos de archivos que requieren búsqueda, pero, por ejemplo. jpeg, png, ppm funcionarían bien. Esto también sería útil cuando hay múltiples implementaciones que pueden emitir o cargar el mismo tipo de archivo. Por ejemplo, PDF podría cargarse con pdfload o magickload.
felixbuenemann
en 6 may. 2016
Creo que necesitarías las cosas de transmisión para que /dev/stdin funcione. Por ejemplo, esto falla:
$ cat k2.jpg | vips jpegload /dev/stdin x.jpg
VipsJpeg: Not a JPEG file: starts with 0x87 0xe5
...
Los cargadores de archivos esperan poder abrir su entrada varias veces. El material de transmisión agregaría un búfer de lectura que haría esto posible: las muchas imágenes de una transmisión son solo una ventaja.
jcupitt
en 10 may. 2016
Esto se agrega en 8.9. Puedes escribir por ej.
aws s3 cp s3://mybucket/input.jpg - | \
vips thumbnail_source [descriptor=0] .jpg 128 | \
aws s3 cp - s3://mybucket/output.jpg
Las notas de la versión tienen más información:
https://libvips.github.io/libvips/2019/12/11/Qué hay de nuevo en 8.9.html
jcupitt
en 11 jul. 2020
Temas relacionados
kloczek
·
3Comentarios
gencer
·
4Comentarios
huskier
·
4Comentarios
solisoft
·
3Comentarios
binarykitchen
·
3Comentarios
Comentario más útil
Esto se agrega en 8.9. Puedes escribir por ej.
Las notas de la versión tienen más información:
https://libvips.github.io/libvips/2019/12/11/Qué hay de nuevo en 8.9.html