vips-8.0 is finally done, after about five years of painful work. Here's what's new in 8.0 since 7.42, the last version in the vips-7.0 series. There will be another post summarising the whole vips-7.0 to vips-8.0 change, hopefully.
There are a range of
minor new features and stability improvements, plus a few larger ones:
Much better conversion to greyscale
There's a
new colour path for conversion to greyscale which gives much better results.
The new vips result is on the right. The Apparent Greyscale option is the result of a fancy algorithm which adjusts local lightness to try to simulate local colour difference, it looks a bit too contrasty to me. The Gimp result is roughly what vips used to do.
More efficient use of file descriptors
For many formats libvips used to use two file descriptors per open image. On many systems there's a limit of 1,000 file descriptors per process, so you were limited to about 400 images open at once.
libvips now always uses only one file descriptor per image, so you can have over 900 images open.
Rewritten TIFF pyramid creator
The libvips TIFF pyramid code was very old and crusty, and based on tiles. The fancy strip-based pyramid code from dzsave has been reworked and patched into the TIFF writer, and it's now 3x to 4x faster.
Removed old stuff
All the old vips-7.0 documentation has been removed, the new vips-8.0 API is the only documented interface now. The vips7.0 API is still there and should still work, but it won't get any new features.
Thanks John. Any progress on the Ruby interface?
ReplyDeleteThere has been some Ruby progress: the main bug is now fixed in master, there's just a relatively small leak left now. It looks like mvz will need to add quite a bit of code to gir_ffi to fix it though, so it might take a while.
DeleteYou can follow progress here: https://github.com/mvz/gir_ffi/issues/54
... I should have said, vips8 ruby is fine for use now, if you don't mind small leaks. It has full docs and a test suite.
Deletehttps://github.com/jcupitt/gir_ffi-vips
You'll need git master of that plus git master of gir_ffi.
This comment has been removed by the author.
ReplyDeleteThat's really a good news, John!
ReplyDeleteI'm particularly interested by the new grayscale conversion method... if I understand correctly, the conversion involves an intermediate linear scRGB colorspace. What is the gamma and colorpsace of the final grayscale image?
I've also read with a lot of interest the discussion related to Lovell's sharp library (https://github.com/lovell/sharp/issues/193). At some point of the discussion the use of the Lab "L" channel is mentioned, with controversial results. Actually, I think that there is some misconception on how to properly convert the "L" channel to grayscale. IN my experience, the conversion can be done in three simple steps:
1. convert from the original RGB colorspace to Lab using a CMS (like LCMS)
2. discard the color information by filling the "a" and "b" channel with a uniform 50% gray color
3. convert back to whatever output RGB or grayscale colorspace (or just the input RGB colorspace for simplicity)
I have applied this method to the mountain image used as example in sharp issue 193, with this result: https://plus.google.com/photos/yourphotos?hl=en&pid=6145105815466213378&oid=110624611011165412718
As you can see, the final grayscale image is very close to what you get with your improved method, however I think there might be a couple of advantages:
- both methods try to achieve the same goal: translate color into the lightness perceived by the human eye; however, I guess that the Lab conversion does a more sophisticated job than a simple linear relation between RGB channels...
- there is no need to linearize the RGB data (or at least not explicitly), which might give better results with 8-bits input data (but I have no proof or example of that)
Maybe you can consider to add this alternative method in some future version of VIPS, as all building blocks are already available.
Hope this helps!
Hi, yes, the new vips one goes to linear light, then combines the channels as 0.2R + 0.7G + 0.1B, then back to sRGB. This is exactly equivalent to going to CIELAB and setting a/b to 0, I think, but quicker.
DeleteHi, very interesting... then I will use the new method for "L channel" B&W conversion in the case of sRGB input images. Thanks for the clarification!
Delete