vuescan on 13.1

I am trying out Vuescan on two boxes. Both are running 13.1 x64.

The 64 bit version fails on both. It starts but the GUI is not correctly operational. Starting from the command line yields the following error messages:

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/actions/dialog-cancel.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/actions/dialog-cancel.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/32x32/actions/dialog-cancel.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/actions/dialog-cancel.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/32x32/status/dialog-information.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/status/dialog-information.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/32x32/status/dialog-information.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/status/dialog-information.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/actions/window-close.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/actions/window-close.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/32x32/actions/window-close.png’: Fatal error in PNG image file: bad parameters to zlib

(vuescan:9308): Gtk-WARNING **: Error loading icon: Failed to load image ‘/usr/share/icons/oxygen/16x16/actions/window-close.png’: Fatal error in PNG image file: bad parameters to zlib

On one of the machines the 32 bit version runs correctly but it fails in the same manner on the second.

Is this an issue with libpng?

thanks in advance.

What version of VueScan are you trying?
I just tried ver 9.4.19 on my 13.1 laptop and see similar issues.
An older version actually ran, sort of, but flaky.

Comparing to my 12.3 system where vuescan 9.4.19 runs OK, I see that libz.so is version 1.2.7 for 12.3, 1.2.8 for 13.1

So, misery loves company, I’m right here with you.
Searching for solutions…

Since it is proprietary software that is in question, support should be obtained via the vendor (ie their issue).

Support

In particular, refer ‘How do I submit a Problem Report’

Thanks, I have already sent some info.
The test on Ubuntu 10.10
Still investigating

What version of VueScan are you trying?

9.4.19

I contacted the vendor and received a completely useless reply - they simply stated that they test on an old version of Ubunutu and supporting newer versions of Linux is difficult.

On 2013-12-31 07:16, tedbar123 wrote:
>
>> What version of VueScan are you trying?
>
> 9.4.19
>
> I contacted the vendor and received a completely useless reply - they
> simply stated that they test on an old version of Ubunutu and supporting
> newer versions of Linux is difficult.

You could to trace the thing, to find out what it loads.

Maybe you have to try an older version of zlib just for its benefit (library preload option, I think).


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

OK, a chance to experiment with some LD debugging.

I tried the following from the directory where VueScan is unpacked

~/bin/Vuescan9/VueScan> LD_DEBUG=files ./vuescan 2>debug.out
~/bin/Vuescan9/VueScan> cat debug.out |grep fatal

The problems, symbol look-up errors, start in interfaces to** /usr/lib64/gtk-2.0** but there are several others.

I doubt a simple library substitution will fix this, but I’ll keep playing with it

Some interesting results to add to this.
First, I noticed after my last post that the (supposedly) fatal symbol lookup errors reported in my previous post actually appear when the same LD_DEBUG=files ./vuescan test was run on my 12.3 desktop, where vuescan still ran OK. So they are not really fatal.

After a bit of research, I determined that KDE Skanlite would actually work with my scanner on my desktop, where I do 99% of my scanning. It is not as full featured as vuescan, but I deemed it adequate for my needs and moved ahead to upgrade my desktop to 13.1. When, in error, I selected vuescan rather than skanlite to do a quick scan, I was amused to see vuescan open and run fine on the now 13.1 desktop. So now I am really confused.

So, with both desktop and laptop now at 13.1, I reran ldd vuescan >file on both machines, edited out the physical load address info and ran

diff desktop2 laptop2
63c63,64
<       libatiuki.so.1 => /usr/lib64/libatiuki.so.1 
---
>       libnvidia-tls.so.331.20 => /usr/lib64/tls/libnvidia-tls.so.331.20 
>       libnvidia-glcore.so.331.20 => /usr/lib64/libnvidia-glcore.so.331.20

Ah so, I had missed these differences earlier.

So I now believe it is the video hardware(and drivers) issue. My laptop is a corei7 with integrated intel video and add-on nvidia card. I did install bumblebee and play with it back when 12.3 was loaded, but really do not need it at the moment so have not paid much attention. I am not sure why vuescan sees the laptop as nvidia, not intel.

I also cannot say for certain that vuescan ran on the laptop prior to seeing the post that started this thread; I don’t scan much from the laptop. Perhaps tedbat123 can comment on his experiences here. Being a heavy vuescan user on the desktop, I was very interested in how well it would work with 13.1 before my upgrade.

When I get to it, I’ll bring up bumblebee on my laptop and see if that helps vuescan.

All this on my laptop:
In digging about I found that an Nvidia repo was active and that nvidia drivers had been loaded.
I am not exactly sure how/why.
This was a “clean” install from dvd.

I disabled the Nvidia repo then used YAST to remove anything found by search-nvidia that did not want to do other massive package removals.

After rebooting, intel graphics reported running by Kinfocenter.

vuescan works fine.

On 2014-01-05 06:06, cmcgrath5035 wrote:

> After rebooting, intel graphics reported running by Kinfocenter.
>
> vuescan works fine.

So vuescan uses something from the nvidia driver if present? What for? :-o


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

So vuescan uses something from the nvidia driver if present? What for? :-o

I’m not sure - perhaps a side effect of the GUI library package vuescan uses?
Vuescan does have some good filtering and image correction tools available.

I have never 100% (perhaps even 75%) understood what gets loaded on this Optimus (intel 915 + nvidia GT 630M) system.
I loaded bumblebee back when I first loaded oS on the new Win7 machine (I think it was 12.2 at the time), bumblebee ran as advertised when requested but I really had no need for the extra graphics performance so have not maintained or used it.

I specifically did a DVD install (not upgrade; format /, reuse /home) to get rid of the potential collection of “stuff” after various such experiments.

After the DVD install, most everything “worked” and I have been focused on other activities, assuming the intel i915 was in control of the display.
I have subsequently upgraded to kernel 3.11.10 to resolve a bluetooth-suspend issue, but I don’t think that is in play here, the desktop ran vuescan with the stock 3.11.6 kernel.

Looking back, it appears that the DVD install detected the nvidia hardware, added the nvidia repo and loaded the nvidia 331.20 drivers.
I can’t say for certain that I did not activate the nvidia repo, in anticipation of future experiments, and the driver packages auto-installed in one of the many updates I ran.
What exactly the nvidia 331.20 drivers were doing, I’m not sure.
Yesterday, when I saw that ‘ldd vuescan’ was reporting loading nvidia related libraries on the laptop, and ati related libraries on the desktop, but I thought I was running on intel 915 on the laptop, I became suspicious and uninstalled the nvidia 331.20 files, disabled the nvidia repo and rebooted.

In its current state, KInfocenter reports that kernel module i915 is providing the OpenGL interface.
Interestingly, lsmod reports both the i915 and noveau kernel modules loaded.
Running ‘ldd vuescan’ shows a third set of display .so libraries are loaded, presumably to interface the i915 driver and vuescan runs fine.

Short summary - I am not exactly sure who is doing what to whom, but (for the moment) it “works”.
Clearly, my understanding that the nvidia hardware was essentially hidden until bumblebee is installed is not correct with 13.1, and perhaps was not even when 12.3 was loaded.
I can hardly wait for kernel 3.20 to appear, from search about I see that 3.20 will provide some support for the Optimus style multi graphics hardware, obviating the need for Bumblebee, maybe?

I did a bit more digging - into the output generated by LD_DEBUG=files ./vuescan 2>debug2.out

The video driver (on my desktop, it is **libatiuki.so.1 => /usr/lib64/libatiuki.so.1 **) is loaded by /usr/X11R6/lib64/libGL.so.1, which sort of makes sense.

A very interesting observation as one of my two machines has an Nvida card the other not. It runs on the machine with the Nvidia driver installed but only the 32 bit version, the 64 bit version still fails.

I have not used Vuescan since an early version but returned to it as I am in the process of digitising photos. It does a good job of inverting negs based on film type. I copy using my DSLR and then treat the raw NEF file as the input to Vuescan - at least that is what I intended to do.

The alternative is to use an editor, I use Afterhsot and the curves can be built for each neg type after a straight inversion of the channels. Rather than fight with Vuescan I set about building some curves as it actually fits my work flow better. The results are excellent and give me more control.

Thanks for the feedback, I am still going to see if I can get it running - just because it is there :wink: