Latest binary with Windows XP support

[sergeevabc]

It is not a plea to continue building binaries with XP support, it is about where to find the latest binary.
Contrary to all EOLs in the world, hardware is not upgraded that fast and people need tools to rely on.
ImageMagick devs, to their shame, just removed such binaries and now users have to dig them up.
Fortunately, Vips for XP is still (and I hope will be) available here, but I wonder if 8.9.2 is the latest one?

[sergeevabc]

What I don’t get about 8.9.2 is this:

$ vips.exe pngsave
...
   palette      - Quantise to 8bpp palette, input gboolean
                        default: false
...

$ vips.exe pngsave in24bit.png out8bit.png --palette
(vips.exe:14316): VIPS-WARNING **: 11:45:08.011: ignoring palette (no quantisation support)

Why there is no quantisation support here? How do I, a mere user without compiling knowledge, get it enabled?

[jcupitt]

Hello again,

You can try more recent windows binaries, but I don't know if they'll work. I don't think any of us have XP systems we could test on.

Yes, it looks like the 8.9.2 binary is missing libimagequant. My memory is that we'd only recently added the feature and the Windows build system hadn't yet been updated to support it.

You could try the win binaries that Kleis has made:

https://github.com/libvips/build-win64-mxe/releases

Perhaps the 32-bit builds work on XP?

[sergeevabc]

32-bit builds are not working on XP after 8.9.2 which is mentioned in 8.9.2-build2 release message, I quote, “Drop support for Windows XP and Vista”. I confirm that is true, “vips.exe is not a valid Win32 application” is displayed on XP. @kleisauke, I wonder if it is possible to roll out a new XP build with color quantisation support since there is some drop-xp branch?

[kleisauke]

Hello,

I think v8.9.2 is the latest one that could possible support Windows XP. After commit libvips/build-win64-mxe@2228360 MinGW-w64 was build with --with-default-win32-winnt=0x601, which implies that Windows 7 is the minimum supported version.

This version of Windows is still the minimum supported version today, as libc++ uses TryAcquireSRWLockExclusive which didn't exist until Windows 7 (see mstorsjo/llvm-mingw@dcf34a9). Still officially supporting Windows XP would be difficult, since we now use LLVM to build the Windows binaries. This toolchain uses UCRT (the Universal C Runtime) which is only preinstalled since Windows 10, but can be installed on top of Vista or newer. If your constraints include Windows XP (whose support ended 7 years ago) then libvips is probably the wrong solution.

As a possible workaround to still support Windows XP, one could try to compile libvips' Windows binaires with GCC and by specifying --with-default-win32-winnt=0x0501 during the setup of MinGW-w64.
https://github.com/libvips/build-win64-mxe/blob/c91e3b25e8aa3be8c9b5f9079c47c24185deb02b/build/plugins/gcc/overrides.mk#L48

./build.sh web x86_64 static --without-llvm

^{(Note that I don't have an XP system to test it on, so I'm not sure if that works)}

Regarding libimagequant, that's only available since v8.10.6 which uses Lovell's fork (BSD-2-Clause).

[abubelinha]

As @sergeevabc , I also have an old WinXP 32 machine as scanning station and keep on using some old batch scripts for post-processing images.

But now I am trying to migrate most of that stuff to Python, so I would add a new variable to this topic.
I can perfectly cope with using vips 8.9.2 (actually, that would be a huge upgrade to the 7.18.2 version I am using in that machine).
But I don't know which is the pyvips version I should install there, since the most updated Python version I can use is Python 3.4. That one currently fails when trying to run pip install libvips, although https://pypi.org/project/pyvips/ says libvips is compatible with Python versions from 2.7, 3, 3.3, 3.4, 3.5, 3.6

c:\python34\scripts\pip install libvips
Collecting libvips
  ERROR: Could not find a version that satisfies the requirement libvips (from versions: none)
ERROR: No matching distribution found for libvips

What can I try to be able to use pyvips in this machine?
Thanks

[jcupitt]

Ah good spot Kleis.

[abubelinha]

@jcupitt Yes, I have many copies of libgobject-2.0-0.dll in hard disk
(Inkscape, AbiWord, Wireshark, postgis, different nip2 and vips folders ...)
But I think the only one of them included in the path is the copy of vips which is being dinamycally included in path by the python code I posted above:

os.environ['PATH'] = vipshome + ';' + os.environ['PATH']

What should I do about that?

@kleisauke Thanks for the info. I tried with this file: vips-dev-w32-web-8.8.0.zip (not sure about the difference between web/all versions, though).

Now I get this message box (as before, this happens in import pyvips line):

python.exe - Entry point not found:
The procedure entry point AcquireSRWLockExclusive could not be found in dinamyc links library KERNEL32.dll

EDIT: I have to say, the same message box appears if I call vips directly from CLI.
Any clues?

If I downgrade even more and point path to my aforementioned old copy of vips 7.18.2 (which runs OK from CLI) then I hit the python error mentioned in #194

Traceback (most recent call last):
  File "c:\python34\lib\site-packages\pyvips\__init__.py", line 19, in <module>
    import _libvips
ImportError: No module named '_libvips'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test_vips.py", line 43, in <module>
    vipstest()
  File "test_vips.py", line 26, in vipstest
    import pyvips
  File "c:\python34\lib\site-packages\pyvips\__init__.py", line 71, in <module>
    vips_lib = ffi.dlopen(_vips_libname)
  File "c:\python34\lib\site-packages\cffi\api.py", line 150, in dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)
  File "c:\python34\lib\site-packages\cffi\api.py", line 832, in _make_ffi_library
    backendlib = _load_backend_lib(backend, libname, flags)
  File "c:\python34\lib\site-packages\cffi\api.py", line 827, in _load_backend_lib
    raise OSError(msg)
OSError: cannot load library 'libvips-42.dll': error 0x7e.  Additionally, ctypes.util.find_library() did not manage to locate a library called 'libvips-42.dll'

But I insist that my WinXP and Python are both 32bit versions, so I downloaded files with substring "w32" in their names. I understand they should work in Win32 ... but I ask again because of this comment, which I suppose it just applies in case you download a "w64" file version.

[kleisauke]

The slim reader/writer (SRW) lock API was introduced in Windows Vista. It looks like the Windows XP compat code was removed in GLib v2.57.2 with this merge request:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/41

The minimum supported version of Windows on later versions is either Windows 7 (when cross-compiling) or Windows 8 (when building with Visual Studio).
https://github.com/GNOME/glib/blob/b3a568d19eaa4cb00609cfa21bbd7813e42aea94/meson.build#L523-L524
https://wiki.gnome.org/Projects/GLib/SupportedPlatforms

Perhaps the v8.6.5 binaries should still work on Windows XP? These ship with GLib v2.54.2.

not sure about the difference between web/all versions

The libvips Windows binary vips-dev-w32-all-x.y.z.zip contains ALL the file format loaders that libvips supports, including some very minor ones, and a complete copy of ImageMagick. It can process many different file types, but it is also rather vulnerable to hacking.

The vips-dev-w32-web-x.y.z.zip build contains only file format loaders that have been carefully tested and which are commonly used on the web. It won't load formats like openslide (for example), but it should be safer to use with untrusted input.

If I downgrade even more and point path to my aforementioned old copy of vips 7.18.2 (which runs OK from CLI) then I hit the python error mentioned in libvips/pyvips#194

pyvips requires at least libvips version 8.2 or later. AFAIK, the now-removed vips7 Python binding based on PyGObject was the only one that supported the vips7 interface.

[abubelinha]

Thanks a lot for the info @kleisauke
For some reason, in this case (v8.6.5) I don't see any "w32" zip files.
I see "4 assets", whereas for newest releases I see "6 assets" (2 of them being the "w32-all" and "w32-web" zip files.
This is a bit odd ... I would expect to find more 32 bit releases for old versions than for new ones.

Where can I find the 32bit binaries for those old releases?
Sorry, I don't recall where I downloaded my 7.18.2 files from.

EDIT: no idea about how to compile sources myself.
I guess I should look here and here ... but I really feel trying those things goes much beyond my skills.

[kleisauke]

Ah, the 32-bit binaries were only build and distributed since v8.7.0 on that repository. You might want to try the binaries in this answer instead: #2292 (comment).

[kleisauke]

I tried to build the latest libvips binaries with Windows XP compatibility restored (on a best effort basis). See commit libvips/build-win64-mxe@5513cdd on the winxp-compat branch.

If anyone wants to test this, you can download the statically-linked -web variant of these binaries here:
https://libvips-packaging.s3.amazonaws.com/vips-dev-w32-web-8.12.2-static-gcc-winxp.zip
https://libvips-packaging.s3.amazonaws.com/vips-dev-w64-web-8.12.2-static-gcc-winxp.zip

I'm not sure if the above binaries actually work on Windows XP, so I didn't upload the -all variant (for now).

Hope this helps.

[abubelinha]

Now it changed to:

vips.exe - Entry point not found:
The procedure entry point InitializeConditionVariable could not be found in dinamyc links library KERNEL32.dll

[kleisauke]

Once again thanks for testing and patience. Hopefully that one should be fixed with libvips/build-win64-mxe@a767454, I re-uploaded the resulting binaries.

(I don't know if there's a better way to test this compatibility than by running it on Windows XP, perhaps it can be run in a virtual machine?)

[abubelinha]

I would have been more than happy to use an old XP-compatible version, so I am quite surprised that you are trying to give WinXP support in the current version.

Nobody else does that. It's you who has a lot of patience, not me.
So of course it's not problem testing.
Current version error message:

vips.exe - Entry point not found:
The procedure entry point SetThreadErrorMode could not be found in dinamyc links library KERNEL32.dll

---

I was also thinking you could use a VM too (at least for the 64 bit version, which I cannot test).
It seems there are places where you can download preinstalled WinXP VMs, at least for Virtualbox:

• https://www.sysprobs.com/windows-xp-virtualbox-pre-installed-image
• https://archive.org/details/xp51_20191108 and some other appear by searching in archive.org

You'd have to check which version they are (32/64).

Off topic ... I just discovered your weserv/images work, which looks amazing (I didn't know of that ... service?) 👍 👍 👍 👍 👍

[kleisauke]

I was able to fix that one with commit libvips/build-win64-mxe@9ffcd5e, I re-uploaded the resulting binaries.

It looks like that was the last error. I was able to run these binaries in a Windows XP VM, and convert a JPEG image to AVIF (and vice-versa) without any problems. 🎉

Off topic ... I just discovered your weserv/images work, which looks amazing (I didn't know of that ... service?)

Great, I'm glad it's useful. Indeed, it is considered a free service.

[abubelinha]

And I can confirm it worked also in my machine, both CLI vips.exe and pyvips simple tests.

Thank you so much !!!

[abubelinha]

I am trying the WinXP 32bit version kindly compiled by @kleisauke last week.
It's been a long time since I wrote the batch script which I used with vips 7.18.2, for simply convert .tiff scanned images (sheets up to A3-size, 400 dpi, so between 50-100 MB each file) into jpeg-compressed tiled pyramidal tiffs suitable for iipimage server (example command taken from iipimage documentation)

So this is what I used to do back in 2010 or so (vips 7.18.2):
COMMAND:
vips im_vips2tiff "H:\testsource.tif" "H:\vips.7.18.2_output.pyr.tif":jpeg:50,tile:256x256,pyramid

OUTPUT:

vips warning: H:\testsource.tif: incorrect count for field "MinSampleValue" (1, expecting 3); tag ignored
vips warning: H:\testsource.tif: incorrect count for field "MaxSampleValue" (1, expecting 3); tag ignored
vips warning: H:\testsource.tif: incorrect count for field "MinSampleValue" (1, expecting 3); tag ignored
vips warning: H:\testsource.tif: incorrect count for field "MaxSampleValue" (1, expecting 3); tag ignored

Actually I didn't knew about the warnings because I called this from php without collecting the output.
Images produced were just fine for my purposes.

Now when I tried it with the new version, I got many more warnings.
I am using the syntax @jcupitt recommended here, but that was 20 months ago, so maybe the syntax has changed again?

COMMAND:
vips tiffsave "H:\testsource.tif" "H:\vips.8.12.2_output.pyr.tif" --compression jpeg --Q 50 --tile --tile-width 256 --tile-height 256 --pyramid

OUTPUT (just the tail because there are many similar warnings):

(vips:1956): VIPS-WARNING **: 13:21:21.219: Caution: quantization tables are too coarse for baseline JPEG
(vips:1956): VIPS-WARNING **: 13:21:21.219: Caution: quantization tables are too coarse for baseline JPEG
(vips:1956): VIPS-WARNING **: 13:21:21.219: mozjpeg library likely detected. Disable emission of Huffman tables in JpegTables tag, and use optimize_co
ding to avoid potential issues
(vips:1956): VIPS-WARNING **: 13:21:21.235: Caution: quantization tables are too coarse for baseline JPEG
(vips:1956): VIPS-WARNING **: 13:21:21.235: Caution: quantization tables are too coarse for baseline JPEG
(vips:1956): VIPS-WARNING **: 13:21:21.235: mozjpeg library likely detected. Disable emission of Huffman tables in JpegTables tag, and use optimize_co
ding to avoid potential issues
(vips:1956): VIPS-WARNING **: 13:21:21.235: Caution: quantization tables are too coarse for baseline JPEG

The main problem are not the warnings though.
The produced tiled pyramidal tif file is about 4 times smaller in size, so I guess my new command is not doing the equivalent conversion to the old one.
Could you take a look at them? (I had to zip them because github didn't let me upload tiffs)
vips_test1.zip

[kleisauke]

FWIW, you can hide these warnings by setting the VIPS_WARNING environment variable. The above binaries were compiled with MozJPEG, hence the mozjpeg library likely detected warning.

[abubelinha]

Thank you both!!

@kleisauke
Might MozJPEG be also the origin of "Caution: quantization tables are too coarse for baseline JPEG" messages?
Would that VIPS_WARNING hide them as well?
What implications could that have? (i.e. missing other important warnings, i.e. "unable to process damaged file", or whatever).
Could I avoid those warnings by changing any parameters? (instead of hiding them)

@jcupitt : despite huge difference in file size, both old and new vips output tiled tiffs with the same width/height pixel dimensions as testsource.tif.
So if you say they are OK ... I wasted 75% of our museum server space the last 10 years? (by tiffs being 4 times bigger than they should).
That's really good news!! (LOL) Because if I re-run all tiling conversions as of today, we'll have a lot of spare room in server.

Related to this: zoomable tiled tiffs are suitable for iipimage server, but they can't be viewed with a simple web browser.
So I have to convert them to jpeg or png if I somebody requests me a copy to embed in a web page, email, or even a Word document.

Do you know if nowadays there are more recommendable multi-resolution formats that vips can produce and iipimage can handle?
Anyone which everybody can open with "normal" office applications? (word processor, simple image viewers)

As I will probably regenerate all our images to reduce server space x4, I should consider if pyramidal tiff is still the best choice.
Thanks a lot for your help !

[jcupitt]

I think pyramidal TIFFs are probably still the best choice. You can insert them directly into word on o365, at least. You might try turning the quality up -- maybe Q 85?

[abubelinha]

Thanks a lot for the modern Word tip @jcupitt (I am attached to this old WinXP but I should have tested that somewhere else).

Your Q 85 advice is for solving the "quantization tables are too coarse..." warning, isn't it?

Actually vips 8.12.2 removes the warning from Q 70 and higher. Current vips Q 70 duplicates the output file size I get with Q 50 but is still less than vips 7.18.2 output size when I used :jpeg:50 option, so that's fine, thanks!!

BTW I wonder what exactly mean this number.

• Has it exactly the same meaning in old vips :jpeg:50 vs current Q 50?
• Is it the same concept as my (old) Photoshop CS4 "File - Scripts - Image Processor" menu, File Type - Quality input box? (asks for a number between 0 and 12).

I used 5 in Photoshop, to get a similar output quality and file size as I in get with vips Q 50.
But I wonder if this "jpeg quality concept" is some kind of standard defined somewhere?
(basically, in order to know how to best citate it if in a research work I want to talk about the quality of provided images).

BTW, @kleisauke now my Photoshop CS4 starts with a "Owl Orphanage: Photoshop.exe - Could'nt find the entry point for procedure _FreeImage_AllocateT@28 in dynamic links library FreeImage.dll" ... could this have something to be with recent vips 32bit installation? Nothing that hurts. Just wondering. Thanks a lot again for your huge help.

[kleisauke]

Might MozJPEG be also the origin of "Caution: quantization tables are too coarse for baseline JPEG" messages?

These messages also appear with libjpeg-turbo. See the discussion at mozilla/mozjpeg#145 for more information about this.

Would that VIPS_WARNING hide them as well?

Setting this environment variable will probably hide those warnings as well.

What implications could that have? (i.e. missing other important warnings, i.e. "unable to process damaged file", or whatever).

Setting this environment variable only hides warnings. You can use the fail-on property to control the loader sensitivity (e.g. to catch damaged/truncated images). For example:

$ vips copy PIA03883.jpg[fail-on=error] x.tif[compression=jpeg,Q=70,tile,tile-width=256,tile-height=256,pyramid]

Could I avoid those warnings by changing any parameters? (instead of hiding them)

By using a higher JPEG quality you can avoid them, as you have noticed.

could this have something to be with recent vips 32bit installation?

I don't think this error is related to the above Windows XP binaries, as libvips does not depend on FreeImage.