Problem with JPEG2000 inclusion in 2025.02.28 update

I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included). This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow): %%%% begin here \setupexternalfigures[location={local,default}] \starttext \line{% \externalfigure[cow.pdf][height=1in]% \hss \externalfigure[cow-jp2.jp2][height=1in]} \stoptext %%%% end here I get the same problem with .JPX (JPEG2000 Part 2) images (which are the ones I really want to use). This is a show-stopper for the document I produce. Can anyone suggest either (a) a workaround so that I can include JPEG2000 images (aside from converting them to JPEGs and including those), or (b) tell me how I can revert to the previous version of ConTeXt? (Unfortunately, my web search for installing an older version is polluted by mostly non-ConTeXt uses of the word "context".) Thanks. Jim

On 20 Mar 2025, at 17:09, Jim
wrote: I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included).
This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow):
Which OS are you using because I have no problem displaying sample1.jp2 from https://toolsfairy.com/image-test/sample-jp2-files on a Mac using 2025.02.28. \starttext \externalfigure[sample1.jp2][height=20cm] \stoptext Regards, — Bruce Horrocks Hampshire, UK

Hi Bruce, thanks for getting back. On Sat, Mar 22, 2025 at 12:18 (+0000), Bruce Horrocks wrote:
On 20 Mar 2025, at 17:09, Jim
wrote:
I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included).
This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow):
Which OS are you using
I am using Linux (specifically, Slackware64 15.0).
because I have no problem displaying sample1.jp2 from https://toolsfairy.com/image-test/sample-jp2-files on a Mac using 2025.02.28.
I downloaded and tried sample-jp2-files-sample1.jp2 from that web site, and it also does not show up using the most recent context. (Just out of curiosity, did you try the cow-jp2.jp2 I attached to my original email?) I have TL2024 and TL2025 installed on my my system. The context in TL2025 is also the 2025.02.28 version, and it also doesn't work. Contrariwise, the context in TL (2024.02.27) does show .JP2 and .JPX images. While I could use the context from TL2024 to include JPX files, the TL2024 context breaks paragraphs differently than more recent versions, and is missing some other things which I depend upon. Thus my interest in either getting the JP2/JPX inclusion (on Linux) fixed, or backing up to whatever version preceded 2025.02.28. Cheers. Jim

Hi Jim,
it works here with your cow-jp2.jp2 without problems with:
┌──(userland㉿localhost)-[~]
└─$ context --version
mtx-context | ConTeXt Process Management 1.06
mtx-context |
mtx-context | main context file: /home/userland/lmtx/tex/texmf-context/tex/context/base/mkiv/context.mkiv
mtx-context | current version: 2025.02.28 18:16
mtx-context | main context file: /home/userland/lmtx/tex/texmf-context/tex/context/base/mkxl/context.mkxl
mtx-context | current version: 2025.02.28 18:16
on:
┌──(userland㉿localhost)-[~]
└─$ uname -a
Linux localhost 6.1.93-android14-11 #1 SMP PREEMPT Thu Feb 13 06:09:31 UTC 2025 aarch64 GNU/Linux
Greetings Lutz
Am 22. März 2025 14:55:04 MEZ schrieb Jim
Hi Bruce,
thanks for getting back.
On Sat, Mar 22, 2025 at 12:18 (+0000), Bruce Horrocks wrote:
On 20 Mar 2025, at 17:09, Jim
wrote: I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included).
This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow):
Which OS are you using
I am using Linux (specifically, Slackware64 15.0).
because I have no problem displaying sample1.jp2 from https://toolsfairy.com/image-test/sample-jp2-files on a Mac using 2025.02.28.
I downloaded and tried sample-jp2-files-sample1.jp2 from that web site, and it also does not show up using the most recent context.
(Just out of curiosity, did you try the cow-jp2.jp2 I attached to my original email?)
I have TL2024 and TL2025 installed on my my system. The context in TL2025 is also the 2025.02.28 version, and it also doesn't work.
Contrariwise, the context in TL (2024.02.27) does show .JP2 and .JPX images.
While I could use the context from TL2024 to include JPX files, the TL2024 context breaks paragraphs differently than more recent versions, and is missing some other things which I depend upon.
Thus my interest in either getting the JP2/JPX inclusion (on Linux) fixed, or backing up to whatever version preceded 2025.02.28.
Cheers. Jim
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___________________________________________________________________________________

On 23 Mar 2025, at 07:43, Lutz Haseloff
wrote: it works here with your cow-jp2.jp2 without problems with:
I installed a fresh Slackware 15 into a VM and tried to build the sample file and it failed: same grey box that Jim reported. I then tried compiling the luametatex binary locally, managed to mess-up my system copying binaries around :-( and started again with a fresh VM. Second time around I used XFCE rather than KDE and this time it worked first time, no-recompile needed! So either I messed-up first time or there might be an issue when using KDE. So the question to Jim is: are you using KDE? (This might well be a red herring but worth asking.) Whichever desktop you're using, it might be worth uninstalling context completely (so that you get back to the default Slackware version of 2021.03.05) and then re-install as per the wiki instructions. Regards, — Bruce Horrocks Hampshire, UK

Hi Bruce, On Sun, Mar 23, 2025 at 09:52 (+0000), Bruce Horrocks wrote:
On 23 Mar 2025, at 07:43, Lutz Haseloff
wrote:
it works here with your cow-jp2.jp2 without problems with:
I installed a fresh Slackware 15 into a VM and tried to build the sample file and it failed: same grey box that Jim reported.
Was that Slackware64? And I tried my already-existing VM (just in case there was something weird on my bare-iron system), installed ConTeXt stand-alone, and also got the same "grey box" for the JP2 image.
I then tried compiling the luametatex binary locally, managed to mess-up my system copying binaries around :-( and started again with a fresh VM. Second time around I used XFCE rather than KDE and this time it worked first time, no-recompile needed!
?! Was this another Slackware(64?) 15.0 system? Or a VM with some other system?
So either I messed-up first time or there might be an issue when using KDE.
So the question to Jim is: are you using KDE? (This might well be a red herring but worth asking.)
No, I use the venerable fvwm. Although I have KDE installed on my system (as well as xfce).
Whichever desktop you're using, it might be worth uninstalling context completely (so that you get back to the default Slackware version of 2021.03.05) and then re-install as per the wiki instructions.
TeX is the one (set of) Slackware packages I no longer install at all, I just go with texlive (and, since I started using ConTeXt, the stand-alone ConTeXt). As yet another data point: just in case I had some peculiar Slackware configuration in my VM, I installed (stand-alone) ConTeXt into an MX-Linux VM, and it also gives me grey boxes for JPEG2000 images. Given Pablo's reported success with Fedora, and your (eventual) success with a second VM (although I'm really having a hard time seeing what your choice of desktop environment has to do with context creating a PDF with or without the grey box), I'm beginning to wonder if I have a poltergeist in my hardware. If so, perhaps I need to ask around on alt.witchcraft. :-) Cheers. Jim
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___________________________________________________________________________________

Hi Lutz, On Sun, Mar 23, 2025 at 08:43 (+0100), Lutz Haseloff wrote:
Hi Jim,
it works here with your cow-jp2.jp2 without problems with:
┌──(userland㉿localhost)-[~] └─$ context --version mtx-context | ConTeXt Process Management 1.06 mtx-context | mtx-context | main context file: /home/userland/lmtx/tex/texmf-context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2025.02.28 18:16 mtx-context | main context file: /home/userland/lmtx/tex/texmf-context/tex/context/base/mkxl/context.mkxl mtx-context | current version: 2025.02.28 18:16
on:
┌──(userland㉿localhost)-[~] └─$ uname -a Linux localhost 6.1.93-android14-11 #1 SMP PREEMPT Thu Feb 13 06:09:31 UTC 2025 aarch64 GNU/Linux
Thanks very much for replying. Just for more information: is this on a phone, an Android tablet, a Chromebook, or some other device? Cheers. Jim

Am 22.03.2025 um 13:18 schrieb Bruce Horrocks:
On 20 Mar 2025, at 17:09, Jim
wrote: I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included).
This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow):
Which OS are you using because I have no problem displaying sample1.jp2 from https://toolsfairy.com/image-test/sample-jp2-files on a Mac using 2025.02.28.
I would add the following tracker at the beginning to get more information out of ConTeXt. \enabletrackers[graphics.*]
\starttext \externalfigure[sample1.jp2][height=20cm] \stoptext
Wolfgang

Hi Wolfgang, thanks for replying. On Sun, Mar 23, 2025 at 18:34 (+0100), Wolfgang Schuster wrote:
Am 22.03.2025 um 13:18 schrieb Bruce Horrocks:
On 20 Mar 2025, at 17:09, Jim
wrote:
I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included).
This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow):
Which OS are you using because I have no problem displaying sample1.jp2 from https://toolsfairy.com/image-test/sample-jp2-files on a Mac using 2025.02.28.
I would add the following tracker at the beginning to get more information out of ConTeXt.
\enabletrackers[graphics.*]
\starttext \externalfigure[sample1.jp2][height=20cm] \stoptext
Thanks for that suggestion. With that suggestion, and a bit more digging, the "mystery" is solved. First, I want to apologize for making an unforgivable mistake on my initial question, because although I thought (*cough*) I confirmed that example didn't work, in fact it does work for me (at least now, and presumably before). A more recent message I sent had the one which didn't work, and still doesn't: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \definegraphictypesynonym [jpx] [jp2] \setupexternalfigures[location={local,default}] \starttext \line{% \externalfigure[cow.pdf][height=1in]% \hss \externalfigure[cow-jp2.jp2][height=1in]} \vskip 20pt \line{% \externalfigure[cow-jpg.jpg][height=1in]% \hss \externalfigure[cow-jpx.jpx][height=1in]} \stoptext %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The problem (as I now discover, because of Wolfgang's sample and tracker suggestion) is the line \definegraphictypesynonym [jpx] [jp2] which I egregiously omitted from my first (over-)simplified example. I needed this before 2025.02.28 because up until then the .jpx extension was not known to ConTeXt, and some helpful person on this very mailing list suggested I add that to my context source files. However, including that line in the 2025.02.28 version (with the tracker) and running context produces this output: figures > label: cow-jp2.jp2, name: cow-jp2.jp2, parent: cow-jp2.jp2 graphics > inclusion > forcing format 'jp2' graphics > inclusion > unknown format 'jp2' graphics > inclusion > './cow-jp2.jp2' resolved to './cow-jp2.jp2' graphics > inclusion > checking conversion of './cow-jp2.jp2', fullname './cow-jp2.jp2', old format 'jp2', new format 'pdf', conversion 'default', resolution 'default', crop 'yes', arguments '' graphics > inclusion > format 'jp2' is not supported So even in a test file with no .jpx file like this %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \definegraphictypesynonym [jpx] [jp2] \setupexternalfigures[location={local,default}] \enabletrackers[graphics.*] \starttext \line{% \externalfigure[cow.pdf][height=1in]% \hss \externalfigure[cow-jp2.jp2][height=1in]} \stoptext %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% the \definegraphictypesynonym causes context to not "know" .jp2 files. In summary, it would appear that \definegraphictypesynonym [jpx] [jp2] is now a very bad thing to have in a context file. I used diffpdf to compare two versions of a 24-page document: the one I created before upgrading to 2025.02.28 and the one I just did now, after removing that \definegraphictypesynonym line. Aside from a couple of changes in line-breaking, and some (presumed) false positive differences, all seems to be good. Again, thanks to everyone who contributed, and I am sincerely and profusely sorry for wasting your time. Jim

On 3/20/25 18:09, Jim wrote:
I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included).
This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow):
Hi Jim, using your image (SHA512 2087e6b338a0f99b1fd3c1b987eabc246b97d0508f69afdcddcc947caa1fc3eea1e7a8e166825700659ffc2c7500a1e746deceee8df24d978f7849602fa69eef) with both ConTeXt 2025.02.28 18:16 and either LuaTeX 1.21 7667 or 2.11.07 20250226 gets the right image displayed on the page. I’m on Fedora Linux, so Linux might not be the problem here. Would it be possible that your PDF viewer or dependent libraries might have an issue with these kind of images? On my computer, either Evince/Okular (both poppler-based), or MuPDF-GL, or MuPDF.js (from current Firefox) display both images right fine. My (educated?) guess is that this might be an issue with your viewer. At least, test your result with a different PDF viewer. Just in case it might help, Pablo

On 3/23/25 10:07, Pablo Rodriguez wrote:
with both ConTeXt 2025.02.28 18:16 and either LuaTeX 1.21 7667 or 2.11.07 20250226 gets the right image displayed on the page.
Well, LuaTeX 2.11.07 20250226 is actually LuaMetaTeX 2.11.07 20250226. Just in case it had lead to confussion, Pablo

Hi Pablo, On Sun, Mar 23, 2025 at 10:07 (+0100), Pablo Rodriguez via ntg-context wrote:
On 3/20/25 18:09, Jim wrote:
I use JPEG2000 images and, unit the most recent update, these worked fine for me (i.e., anywhere a "normal" JPEG could be included, a JPEG2000 could be included).
This seems to have come to a crashing halt with the 2025.02.28 update. Now I just get the gray box. Here is an example of it not working (I have attached a .JP2 image of ConTeXt's favourite cow):
Hi Jim,
using your image (SHA512 2087e6b338a0f99b1fd3c1b987eabc246b97d0508f69afdcddcc947caa1fc3eea1e7a8e166825700659ffc2c7500a1e746deceee8df24d978f7849602fa69eef) with both ConTeXt 2025.02.28 18:16 and either LuaTeX 1.21 7667 or 2.11.07 20250226 gets the right image displayed on the page.
I’m on Fedora Linux, so Linux might not be the problem here.
Well, I'm a bit boggled as to what the problem might be. As you might have seen in my reply to Bruce, I tried an MX-Linux VM and that has the same issue.
Would it be possible that your PDF viewer or dependent libraries might have an issue with these kind of images?
No, the issue does not seem to be the viewers. It is not like there is a blank spot where the image is, instead I see the grey box that context puts in when it can't find or read or ... an image that you asked for. Also, just for completeness, xpdf, evince, whatever AucTeX uses in PDFview, and my venerable Adobe acroread only show the grey box. Whereas, xpdf, evince and acroread all show the JPEG2000 images when I run the context from texlive 2024.
On my computer, either Evince/Okular (both poppler-based), or MuPDF-GL, or MuPDF.js (from current Firefox) display both images right fine.
My (educated?) guess is that this might be an issue with your viewer.
Thanks, but that seems very unlikely to me. Especially since all my viewers were working fine before I upgraded by stand-alone context to the 2025.02.28 version. It seems unlikely they would all stop working because of that.
At least, test your result with a different PDF viewer.
Just in case it might help,
Thanks. But sadly, that does not appear to be the issue. Cheers. Jim

On 3/23/25 17:30, Jim wrote:
Hi Pablo,
Hi Jim, how about OpenJPEG or the library that displays JPEG2000 and JPX images? I attach my output file from your sample, is it displayed right on your system? If the image isn’t displayed, could you send to the list the PDF output from your sample? I hope this helps, Pablo

On Sun, Mar 23, 2025 at 18:14 (+0100), Pablo Rodriguez via ntg-context wrote:
On 3/23/25 17:30, Jim wrote:
Hi Pablo,
Hi Jim,
Hi Pablo,
how about OpenJPEG or the library that displays JPEG2000 and JPX images?
The PDFs that I created before 2025.02.28 came along all (well, I only tested some of them) still display correctly. As does the PDF I more recently created with the TL2024 version of context.
I attach my output file from your sample, is it displayed right on your system?
Perfectly. So even more, I don't think my problem has anything to do with PDF viewing programs.
If the image isn’t displayed, could you send to the list the PDF output from your sample?
Just in case anyone is confused by what I mean when I say "grey box", here is my test of including a PDF, JPG, JP2 and JPX. When I look at it, I see the PDF cow, the JPG cow, but neither the JP2 nor the JPX image. Here is the context for that PDF: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \definegraphictypesynonym [jpx] [jp2] \setupexternalfigures[location={local,default}] \starttext \line{% \externalfigure[cow.pdf][height=1in]% \hss \externalfigure[cow-jp2.jp2][height=1in]} \vskip 20pt \line{% \externalfigure[cow-jpg.jpg][height=1in]% \hss \externalfigure[cow-jpx.jpx][height=1in]} \stoptext %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Further, given that pdfimages only finds the JPG image in the attached PDF, I feel more strongly yet that there is only one image in there. (Although I admit if there was a library problem and pdfimages used the same library, that could cause pdfimages to show nothing.) Finally, I tested the current stand-along context on two more computers: (1) MX Linux running on bare metal (2) Ubuntu 18.04.6 LTS running on bare metal. In both cases, the PDF did not have the JP2 or JPX image. For those keeping score, here is a summary of all the tests I know about: (me) x86_64: Slackware64 15.0 bare metal: doesn't work (me) x86_64: Slackware64 15.0 VM: doesn't work (me) x86_64: MX Linux (debian 12.9) bare metal: doesn't work (me) x86_64: MX Linux (debian 12.9) VM: doesn't work (me) x86_64: Ubuntu 18.04.6 LTS bare metal: doesn't work (LH) aarch64: 6.1.93-android14-11 works (PR) ? Fedora works [[I assume when Pablo says "LuaTeX 2.11.07 20250226" he means ...20250228 ]] (BH) Mac ? works (BH) ? Slackware 15 VM, KDE DE: doesn't work (BH) ? (Slackware 15?) VM, Xfce DE: works Thanks to everyone contributing. Jim

On 3/23/25 18:51, Jim wrote:
[...] (PR) ? Fedora works [[I assume when Pablo says "LuaTeX 2.11.07 20250226" he means ...20250228 ]]
Metadata actually show (just after reinstalling the binaries): LuaMetaTeX 2.11.07 20250226 + ConTeXt LMTX 2025.02.28 18:16 ConTeXt is from 2025.02.28, but LMTX seems to be from two days before (20250226). Just in case it might help, Pablo

On 23 Mar 2025, at 18:19, Pablo Rodriguez via ntg-context
wrote: On 3/23/25 18:51, Jim wrote:
[...] (PR) ? Fedora works [[I assume when Pablo says "LuaTeX 2.11.07 20250226" he means ...20250228 ]]
Metadata actually show (just after reinstalling the binaries):
LuaMetaTeX 2.11.07 20250226 + ConTeXt LMTX 2025.02.28 18:16
ConTeXt is from 2025.02.28, but LMTX seems to be from two days before (20250226).
Just in case it might help,
Replying to Pablo's message to bring the thread back together but @Jim: I think you're right: the desktop shouldn't make difference so I'm not sure what I did wrong originally. The VM I'm using is a VMware Fusion VM with a new install from "slackware64-15.0-install-dvd.iso". It all seems to work: both the pre-built binary from the distribution and a compiled on Slackware version (which comes out at a different size!). I can send you the "compiled on Slackware" version if you think that might help, but it's easy enough to compile for yourself. Regards, — Bruce Horrocks Hampshire, UK

On 3/23/25 17:30, Jim wrote:
No, the issue does not seem to be the viewers. It is not like there is a blank spot where the image is, instead I see the grey box that context puts in when it can't find or read or ... an image that you asked for.
Sorry, Jim, I have just noticed that I overlooked which kind of grey box you were having. Sorry again for the previous noise, Pablo

Since you already handled the more exotic cases, something very simple: Are you sure this is not just a typo, maybe with upper/lowercase? (I’m reminded of problems between case sensitive and insensitive systems like Linux vs. MacOS that costed hours of debugging…) Since ConTeXt doesn’t rely on external libraries, I think we can exclude a difference in e.g. libjpeg between different Linux distributions. A difference between GUIs or window managers is really improbable, as apparently a difference in PDF viewers. Hraban

Hi Hraban, On Sun, Mar 23, 2025 at 18:21 (+0100), Henning Hraban Ramm wrote:
Since you already handled the more exotic cases, something very simple:
Are you sure this is not just a typo, maybe with upper/lowercase?
(I’m reminded of problems between case sensitive and insensitive systems like Linux vs. MacOS that costed hours of debugging…)
Good thought, but... Given that the very same source file works with the context found in TL2024, this seems unlikely. Unless somehow the TL2024 context (and the context in the stand-alone context distribution) intuits filename errors like that. Also, copying and pasting from my .tex file onto the end of an ls -l command gives me the file information. So I don't think so.
Since ConTeXt doesn’t rely on external libraries, I think we can exclude a difference in e.g. libjpeg between different Linux distributions.
I did notice that 'ldd .../luametatex' showed no apparently-relevant .so libraries. However, I did wonder whether building it on my system pulled in any .a libraries, which ldd wouldn't show.
A difference between GUIs or window managers is really improbable, as apparently a difference in PDF viewers.
I agree. Everything here is pointing to my context program. Hercule Poirot is never around when I need him. Jim
participants (6)
-
Bruce Horrocks
-
Henning Hraban Ramm
-
Jim
-
Lutz Haseloff
-
Pablo Rodriguez
-
Wolfgang Schuster