Legacy ImageMagick Discussions Archive

I see that JPEG XR support has been added recently. Though it requires the jxrlib to be manually added. Is there a reason for this? jxrlib is licenced under the BSD licence and could be added directly into the project as far as I can tell.

Just wondering what the reasoning behind this was.

ImageMagick priorities are demand driven. Thus far we have seen little demand for the JPEG XR format. If that changes in the future, we will reconsider better support for the format.

Fair enough.

I assumed though that all that would be required would be to copy the jxrlib code branch into ImageMagick? Maybe you rather not have the bloat for a format in low demand?

In any case, consider me one vote in favour of jpeg xr support .

It would be great if support for jpeg-xr enhanced. To be honest, I haven't succeeded to make it work at the current state. The format is now supported by 3 browsers IE9-11 and natively by Windows Vista -8.1 so I guess it could be in quite a high demand.
Looking forward to seeing it implemented.
Thanks in advance.

I too think this would be a great addition. Especially if it will be widely supported by web browsers.

Another vote for better support of JPEG XR format please!

It's only useful for IE and Edge browsers but still, JPEG XR has many advantages over JPEG, not least smaller file-size. We'd make very good use of it if ImageMagick supports it.

greenlands wrote:It's only useful for IE and Edge browsers

Unless you want to use jpeg-xr for intranet websites with ie/edge, maybe you should look at the hevc/x265-based bpg which is an actual step forward and uses the latest and greatest image compression: viewtopic.php?f=2&t=28896&p=128670&hilit=bpg#p128670

BPG image format would be great except no browsers support it:

http://caniuse.com/#search=bpg

greenlands wrote:BPG image format would be great except no browsers support it:
http://caniuse.com/#search=bpg

Yeah, well, but if *some* windows-only browsers support xr and the rest is WONTFIX, that's basically "none" in real life: http://caniuse.com/#search=jpegxr

https://bugs.chromium.org/p/chromium/is ... =56908#c27 ... "As noted on https://bugzilla.mozilla.org/show_bug.cgi?id=500500#c36 , Mozilla feels that JPEG-XR is worse than JPEG from a compression standpoint and thus unlikely to be worth adding. Similarly, some of the Blink owners noted problems with particular testcases, which they felt demonstrated that JPEG-XR's compression quality was disappointing."

To my understanding, the main obstacle for bpg are the licensing issues - but imho xr has still too few advantages over jpeg other than transparency support, the same problem that stopped jpeg2k in its tracks.

... xr vs legacy (not enough of an advantage) : http://xooyoozoo.github.io/yolo-octo-bu ... xr=s&jpg=s

... xr vs 2k (about the same. the wavelets are blurrier, but less artifacts): http://xooyoozoo.github.io/yolo-octo-bu ... xr=s&jp2=s

... xr vs. bpg (q.e.d.): http://xooyoozoo.github.io/yolo-octo-bu ... xr=s&bpg=s

http://xooyoozoo.github.io/yolo-octo-bu ... pg=t&jpg=s is an interesting site. Looks good. But apparently all the images are from JPG files, which are then converted to the other formats.

To me, this seems to be a useless comparison. Data that has already been mangled by lossy (I assume) JPEG compression, in a way that suits JPEG, is then further mangled by some other format. So if the third generation is lower quality than the second generation, does this prove anything useful?

snibgo wrote:But apparently all the images are from JPG files, which are then converted to the other formats.

What makes you say that, and "apparently". I just assumed that of course the source is a lossless file and then compressed to the various destination formats - it's not like it's difficult to acquire a lossless image like that scene nowadays.

The only catch is that of course the images in the list would be chosen to suit bpg, while I guess that with more natural scenes jpeg2000 would do better - for example note the heavy wavelet blur on the fine details of the church. But even considering that and that jpeg2000/jpeg-xr encoders aren't as tuned as jpeg, bpg blows everything out of the water and even decompresses quickly. Plus hevc/x265 intra-image encoding is still being improved...