Bob Friesenhahn

The problem seems to be that when libjpeg is built, the link library (".lib") is either not built, or does not use the naming expected by the rest of the code. If someone is able to assist with this who is fluent with Visual Studio, it would be greatly appreciated. Otherwise I will wait for the developer who did the JPEG updates to return.

Mercurial changeset 16720:171c0dd24d8a partially addresses issues. In the Visual Studio build, source files for formats not supported are not excluded so they still need to successfully compile. Now the jxl and heif modules will build without warning or error in Visual Studio. The issue with JPEG remains. The developer who committed the JPEG updates will not be available to look at this for another week.

I installed Visual Studio 2022 and ran into the same issue with the current sources. However, it does work with older sources. In between times, libjpeg was updated (by someone else) and it seems that the associated project file is producing something unexpected. I also see an issue related to JXL. There are no JXL sources in the project so the failure is likely due to something I did wrong.

On Fri, 29 Jul 2022, William wrote: I'm having issues with compiling latest graphicmagick on Windows 10. Put simply, the issue is 'migrating project(s) from visual studio 7 (2002) to visual studio 2022' breaks successful compiling. Here is detailed description of the process. I have not tried this yet. The most recent Visual Studio I have tried is 2019. There is no need to have Visual Studio 7 installed. The configure.exe program writes Visual Studio 7 compatible project files. Then when opening...

On Thu, 28 Jul 2022, tiefensuche wrote: Thank you for clarification. I noticed it by skimming through the code and looking into the changeset 15991:bc99af93614d. Since it is the only occurrence that was not changed while the same case was changed on other lines, it looked to me it was accidentally forgotten rather than intentionally kept as is, although it has no impact. Source code inspections are always appreciated. Even better are volunteers willing to help with development and testing. Bob Bob...

Missing cast

I have implemented the suggested change as Mercurial changeset 16717:0a06f497d588. Thanks for bringing this issue to my attention.

On Wed, 27 Jul 2022, tiefensuche wrote: I think in coders/miff.c line 392, there is a cast missing. It looks like quantum|=(*p++); but should actually be quantum|=((unsigned int) *p++); Did something other than code inspection cause you to notice this? The type of p is 'unsigned char' and the type of 'quantum' is 'unsigned int'. I believe that the rules say that the value is automatically cast to the type of the value it is assigned to. The value is the least significant byte of a two-byte value....