[Therion] Progressive coded JPG files??

[Bill Gee]

Having no new questions, suggestions or information for a few days, I 
did a bit more digging.  I still do not have an answer, but I do have 
some ideas where the experts can look.

I did find a work-around.  Details below ...

In the xTherion program, background images are loaded in lines 17846-17850:

       if {$ximage} {
	set imgid [image create photo -data $xdata]
       } else {
	set imgid [image create photo -file $ffname]
       }

I found a reference to "image create photo" at the main TCL web site:

https://www.tcl-lang.org/man/tcl8.0/TkCmd/photo.html

According to this, specifying "-file $ffname" will load the image using 
whatever format handler is registered for that type.  Tk includes by 
default handlers for GIF and PPM/PGM formats.  That is why PNG images 
still work.

I could not find where Tk stores registered handlers for additional 
image formats.  There is a TCL function called Tk_CreatePhotoImageFormat 
which registers image format handlers.  I see no call to that function 
in xTherion.  I also see nothing in the Tk documentation as to whether 
the result of the function call is saved in a configuration file somewhere.

I could not find any sample code for Tk_CreatePhotoImageFormat which 
initializes a JPEG handler.

Workaround!  xTherion includes a shebang line at the top which names its 
executable as "/usr/bin/env wish".  I have two versions of wish on my 
system - 8.6 and 9.0.  /usr/bin/wish is really a link to wish9.0.  I 
modified xTherion to call for wish8.6 instead.  That failed with an 
error about bwidget not found.

To fix that, I created a symbolic link:

ln -s /usr/share/tcl9.0/bwidget1.10.1/ /usr/share/tcl8.6/

That works.  xTherion no longer complains about bwidget missing.  More 
important - It now loads JPG files without error!

So what is the deal?  What does wish really do?  Did the set of default 
image handlers change between wish 8.6 and 9.0?

Someone - PLEASE!!! - do some serious debugging on this.  It is beyond 
my skill and knowledge.  The problem may not have hit other 
distributions, but it almost certainly will.

===============
Bill Gee

On 8/20/25 07:20, Bill Gee wrote:
> Martin asked if tkimg package is installed.  It is installed.  I suspect 
> if it were not, then png files would also fail.
> 
> ==================
> bgee at main2:~$ rpm -qa | grep -i tkimg
> tkimg-1.4.16-4.fc42.x86_64
> =================
> 
> Wookey - Therion is apparently compiled against libjpeg-turbo.
> 
> ==================
> root at main2:~# ps ax | grep wish
>   467595 ?        Ss     0:00 wish /usr/bin/xtherion /public/document/ 
> CaveSurveys/CaveSpringCave/thconfig
> 
> root at main2:~# lsof -p 467595 | grep -i jpe
> lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
>        Output information may be incomplete.
> wish    467595 bgee  mem       REG                8,2    666168 
> 9437408 /usr/lib64/libjpeg.so.62.4.0
> 
> root at main2:~# rpm -q --whatprovides /usr/lib64/libjpeg.so.62.4.0
> libjpeg-turbo-3.1.0-2.fc42.x86_64
> ===================
> 
> The error message is coming from a TCL program.  TCL is an interpreted 
> script - not an ELF image.  I think the concept of "compiled against 
> library xxx" does not apply here.  Something in that script is loading 
> libjpeg, but I have no idea what it is or where it is called.
> 
> Looking through the source code - I see the error message is generated 
> at line 737 in me_imgs.tcl.  Looking at the code around that line, I do 
> not see anything suggestive.  The message is triggered when an object 
> named $imgid is null (line 735), which means some earlier code is not 
> recognizing the jpg file as valid.  Or perhaps not even trying to load it??
> 
> Looking at package descriptions - openjpeg is intended for JPEG 2000 
> formats.  libjpeg-turbo is intended for general jpeg handling.
> 
> 
> ===============
> Bill Gee
> 
> On 8/19/25 21:04, Wookey wrote:
>> On 2025-08-19 08:25 -0500, Bill Gee wrote:
>>> It appears that xTherion will no longer load ANY jpg file.
>>
>>> The system is Fedora 42.  Therion is 6.3.4+dev, compiled back in 
>>> April. I have several jpeg libraries installed:
>>>
>>> root at main2:~# rpm -qa | grep jpeg
>>> libjpeg-turbo-3.1.0-2.fc42.x86_64
>>> openjpeg-2.5.3-6.fc42.x86_64
>>> turbojpeg-3.1.0-2.fc42.x86_64
>>> openjpeg-tools-2.5.3-6.fc42.x86_64
>>> libjpeg-turbo-utils-3.1.0-2.fc42.x86_64
>>> libjpeg-turbo-devel-3.1.0-2.fc42.x86_64
>>> openjpeg-devel-2.5.3-6.fc42.x86_64
>>> jpeginfo-1.7.1-6.fc42.x86_64
>>> jpegoptim-1.5.5-6.fc42.x86_64
>>> mjpegtools-libs-2.2.1-8.fc42.x86_64
>>
>> OK. Just checked on Debian 13 (stable released last week) and therion 
>> will load jpegs OK there.
>>
>> In case it helps:
>> therion 6.3.4-2                              amd64        Cave 
>> surveying - 2D and 3D drawing software
>> libjpeg-turbo-progs 1:2.1.5-4                            amd64        
>> Programs for manipulating JPEG files
>> libjpeg62-turbo:amd64 1:2.1.5-4                            
>> amd64        libjpeg-turbo JPEG runtime library
>> libturbojpeg0:amd64 1:2.1.5-4                            amd64        
>> TurboJPEG runtime library - SIMD optimized
>>
>> So your libjpeg-turbo is 3.x whilst I have 2.x. Maybe that's 
>> significant? I think libjpeg-turbo and openjpeg are alternatives. 
>> Check which therion is using on your system. Mine is linked against 
>> libjpeg.so.62 which comes from libjpeg62-turbo
>>
>> Wookey
>>
>> _______________________________________________
>> Therion mailing list
>> Therion at speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
> 
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> https://mailman.speleo.sk/listinfo/therion