Oops, my fault, sorry. I'm always too lazy to test commands and then miss something.

Using .dz as a suffix writes zip by default. This is so you can stream it, eg:

vips flip k2.jpg .dz horizontal | cat > something.zip

The dzsave will write a zip to the pipe so you can send a pyramid directly to s3 (for example) and not need any memory or disc for intermediates.

You can set the container (zip, filesystem, SZI) with the container option, so:

john@banana ~/pics/x $ ls
john@banana ~/pics/x $ vips icc_transform ../k2.jpg x.dz[container=fs] srgb 
john@banana ~/pics/x $ ls -al
total 84
drwxrwxr-x   3 john john  4096 Apr 23 04:01 .
drwxr-xr-x 150 john john 69632 Apr 23 03:56 ..
-rw-r--r--   1 john john     0 Apr 23 04:01 x.dz
-rw-rw-r--   1 john john   206 Apr 23 04:01 x.dzi
drwxrwxr-x  14 john john  4096 Apr 23 04:01 x_files

The stray empty x.dz file is a bug, I'll fix it.

Awesome thanks!

Yeah, writing to a zip is a very cool feature, agreed! I definitely now have in my "someday cool project" pile writing an adapter for OpenSeadragon so it can read DZI directly from ZIP with http range requests, that would def be a big help to managing lots of dzi's! It looks like there is some open source JS for random access to zips already, but I haven't had time to really dig into it yet.

I am constantly amazed by how powerfully flexible the vips command line is, but have trouble wrapping my head around the syntax options to know what's possible. I have to admit, and this is the first time I've really gotten into it for coding, that ChatGPT has been very helpful in suggesting vips command line arguments, once I know the right questions to ask.

OK we left ONE thing out of the invocation for my needs, --embedded, to make sure it uses the embedded Adobe RGB profile as a source/input profile.

My final invocation looks like:

vips icc_transform --embedded input.jpg output.dz[container=fs,suffix=.jpg[Q=85]] srgb 

And appears to work nicely for me.

Thanks for all the help, and thanks for vips!

If you give no arguments it'll print a summary:

$ vips icc_transform
transform between devices with ICC profiles
usage:
   icc_transform in out output-profile [--option-name option-value ...]
where:
   in           - Input image, input VipsImage
   out          - Output image, output VipsImage
   output-profile - Filename to load output profile from, input gchararray
optional arguments:
   pcs          - Set Profile Connection Space, input VipsPCS
			default enum: lab
			allowed enums: lab, xyz
   intent       - Rendering intent, input VipsIntent
			default enum: relative
			allowed enums: perceptual, relative, saturation, absolute, auto
   black-point-compensation - Enable black point compensation, input gboolean
			default: false
   embedded     - Use embedded input profile, if available, input gboolean
			default: false
   input-profile - Filename to load input profile from, input gchararray
   depth        - Output device space depth in bits, input gint
			default: 8
			min: 8, max: 16
operation flags: sequential 
$

You can see the arguments in the docs as well:

https://www.libvips.org/API/current/libvips-colour.html#vips-icc-transform

We have new docs for the next libvips:

http://www.rollthepotato.net/~john/vips/method.Image.icc_transform.html

Now with a search function, woo!

Ah there's a tab-completion script too:

https://github.com/libvips/libvips/tree/master/completions

it makes the CLI a little easier to use.

Thanks for this!

So I did know this was theoretically possible, that zip's were theoretically random-accessible and so could be seeked with http-range, and that could make dealing with image pyramids so much less annoying . I have had it in the back burner of my mind for a while -- I did not know vips dzsave could CREATE the zip in one go like that, that's neat!

But while thoeretically possible, the solution to the exersize left for the reader, "You'll need something to parse the zip index from the end of the file", and how to fit that into things, is something I haven't figured out/had time to figure out.

If anyone has a working solution to demonstrate of this technique used with image pyramids and openSeadragon, I would LOVE to see it! Or failing that, even additional tips and pointers towards a solution! :)

When you have a ton of these on S3 or local storage or anywhere... dealing with millions of files is really no fun, even on file systems that can handle it, it's slow to do anything with em! So yeah, I have been trying to work out a solution in this direction too! Didn't know if anyone else was thinking of it, if anyone has an open source solution would love to see it!