Bug 412491

I'm not able to reproduce this:

 /suse/werner> cat /etc/SuSE-release
 openSUSE 11.0 (i586)
 VERSION = 11.0
 /suse/werner> locate .jpg | xargs xv

and all jpeg are shown correct.  How deep is your color depth of your
screen. In other words: is it possible that you've out of colors on
the current screen?  Please test out

 xv -owncmap

to enforce xv to install its own color map.  This should help a lot
in 8 bit color depth.

I tried "xv -owncmap" and found no difference.  I also doubt it is a display
colormap problem, as I can display the an image with the new xv and an older
version at the same time, and only the new version displays the black image.
Further, I can display the same image with the problem xv, display (ImageMagick),
xli, and seamonkey on the same screen, with only xv failing to display the
image.  I will attach a screen grab as evidence.

Created attachment 231067 [details]
Comparison of xv, display, xli and seamonkey

Note that xv fails to display the image, except in black.

I can not reproduce this and without I'm not able to fix anything.
Try out the change color map within xv its self, that is

        start xv with an jpg
        click with mouse button 3 on the picture to popup cmd window
        now switch from 24 to 8 bit in `24/8 Bit' menu
        now switch from Std colormap to own colormap in `Display' menu

also I'd like to know the values reported by xrdb

       /suse/werner> xrdb -symbols | grep -iE 'rgb|color'
       -DBITS_PER_RGB=8
       -DCLASS=TrueColor
       -DCLASS_TrueColor=33
       -DCOLOR
       -DCLASS_TrueColor_24=33
       -DCLASS_DirectColor_24=34

adding maintainer of libjpeg to CC.
Hi Vladimir, maybe you have an idea what going wrong with
`XV - version 3.10a-jumboFix+Enh of 20070520' and why I
do not see this.

Beside this please attach onw of your jpegs.

When I start xv and go to the 24/8 bit menu, it is in 8 bit already.  Selecting
"own colormap" has no effect.  If I then try to switch to 24bit, I get a
warning popup about turning a 24-bit image to 8-bit and back again, and that
image data has probably been lost, and that I may want to reload the image.
Doing so displays the image.  So I then did:
        xv -24 <file>
and it displayed properly.

Running an older version of xv, the image is displayed properly in either
8 or 24 bit mode.

$ xrdb -symbols | grep -iE 'rgb|color'
-DBITS_PER_RGB=8
-DCLASS=TrueColor
-DCLASS_TrueColor=35
-DCOLOR
-DCLASS_TrueColor_16=35
-DCLASS_DirectColor_16=39

So the situation is much better, but I don't understand what is going on!

I will attach an image.

Created attachment 231154 [details]
Sample jpeg

Please also show the out put of

       xrdb -query | grep -i xv

which are the current active X resource properties of XV.
For comparision see /usr/share/doc/packages/xv/xvdocs.pdf
`Appendix B: X Resources'.

I'm know able to reproduce:

     xrdb -remove xv.force24
     xrdb -remove xv.force8
     xv -8 ~/bug-412491_joey.jpg

shows a black window, that is that the algorithm `slow 24/8'
and `quick 24/8' seems to fail both because

     xv -8 -best24 ~/bug-412491_joey.jpg

works perfect.  For a workaround I suggest

    echo 'xv.best24: true' >> ~/.Xdefaults
    echo 'xv.best24: true' | xrdb -merge

Created attachment 231347 [details]
xv-3.10a-1241.i586.rpm

Please try out the attached version.  This one includes a ficed
version, for more information simply do
    rpm -q --changelog xv | less

First, as your questions suggested, my .Xdefaults was setting xv*force8.
I had forgotten about this.  I need to use 8-bit mode because I frequently
use the colormap editing facility.  Second, the workarounds you suggested
worked.  Finally, and best of all, your fixed version works perfectly!
Many thanks.

Hope you liked the test jpeg, taken on our lawn here in Tasmania.