Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th November 2019, 07:22   #161  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,462
Quote:
Originally Posted by hajj_3 View Post
I didn't know that JPEG XL could losslessly compact JPEG images to the new format. They really are trying to be as backward compatible as possible.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 22nd November 2019, 19:12   #162  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 656
New High Throughput JPEG 2000
https://htj2k.com/
Library: https://github.com/aous72/OpenJPH

The code is written in C++; the color and wavelet transform steps can employ SIMD instructions on Intel platforms. It conceivable that at some point in the future, SIMD instructions are employed to improve performance of the block (de)coder, and/or for platforms other than Intel. As it stands, on Intel Skylake i7-6700, encoding 4K 4:4:4 HDR images losslessly takes around 0.5s, and decoding takes around 0.34s; for lossy compression, performance depends on the quantisation step size (qstep), but for a high-quality image at a bitrate of around 3 bits/pixel, encoding takes around 0.27s and decoding takes 0.22s.

As it stands, the OpenJPH library needs documentation. The provided encoder ojph_compress only generates HTJ2K codestreams, with the extension j2c; the generated files lack the .jph header. Adding the .jph header is of little urgency, as the codestream contains all needed information to properly decode an image. The .jph header will be added at a future point in time. The provided decoder ojph_expand decodes .jph files, by ignoring the .jph header if it is present.

The provided command line tools ojph_compress and ojph_expand accepts and generated .pgm, .ppm, and .yuv. See the usage examples below.

https://www.sendspace.com/file/u1qesh

Last edited by Jamaika; 22nd November 2019 at 19:18.
Jamaika is offline   Reply With Quote
Old 1st December 2019, 03:30   #163  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,462
OpenJPH is definitely interesting, though I'm not sure if it's promising yet. BTW, Jasper is unofficially dead: https://github.com/mdadams/jasper/issues/208
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 22nd December 2019, 10:49   #164  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 656
Merry Christmas

I add new codecs with the latest updates.
libHEIF v1.6.1 https://www.sendspace.com/file/xdjl6h
libWebP v1.0.3 https://www.sendspace.com/file/e2n4xt
JVETVCC v7.1 https://www.sendspace.com/file/m713dc
HTJPEG2000 v0.6.1 https://www.sendspace.com/file/0hosrl

Imperfections in free codecs.
Code:
fg_main_mswin.c: In function 'fgPlatformSystemTime':
fg_main_mswin.c:480:35: warning: left shift count >= width of type [ttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wshift-count-overflow-Wshift-count-overflowm]
  480 |     return currTime32 | timeEpoch << 32;
      |                                   ^~
Code:
convert.c: In function 'imagetopgx':
convert.c:1387:9: warning: 'strncpy' specified bound depends on the length of the source argument [ttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=-Wstringop-overflow=m]
 1387 |         strncpy(name, outfile, dotpos);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
convert.c:1371:29: note: length computed here
 1371 |         const size_t olen = strlen(outfile);
      |                             ^~~~~~~~~~~~~~~
Code:
In file included from pthread.c:103:
dll.c:158:55: warning: 'gcc_ctor' initialized and declared 'extern'
  158 | __attribute__((section(".ctors"), used)) extern int (*gcc_ctor)(void) = __ptw32_on_process_init;
      |                                                       ^~~~~~~~
Code:
UnitTools.cpp: In function 'void PU::getInterMergeCandidates(const PredictionUnit&, MergeCtx&, int, const int&)':
UnitTools.cpp:1346:50: warning: writing 1 byte into a region of size 0 [ttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=-Wstringop-overflow=m]
 1346 |     mrgCtx.interDirNeighbours [uiArrayAddr     ] = 1;
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
In file included from UnitTools.h:43,
                 from UnitTools.cpp:38:
ContextModelling.h:488:17: note: at offset 6 to object 'MergeCtx::interDirNeighbours' with size 6 declared here
  488 |   unsigned char interDirNeighbours[ MRG_MAX_NUM_CANDS      ];
      |                 ^~~~~~~~~~~~~~~~~~

Last edited by Jamaika; 22nd December 2019 at 13:48.
Jamaika is offline   Reply With Quote
Old 23rd December 2019, 04:47   #165  |  Link
Sparktank
47.952fps@71.928Hz
 
Sparktank's Avatar
 
Join Date: Mar 2011
Posts: 913
Thanks a lot! I keep downloading the updates, but never actually get around to trying them out.

Merry christmas!
__________________
Win10 (x64) build 18362| GPU Caps Viewer 1.42.4.0
NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 | (r435_95-4)
NTSC | DVD: R1 | BD: A
Intel Xeon X5660 @2.80GHz
Sparktank is offline   Reply With Quote
Old 31st December 2019, 07:30   #166  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 656
The jpeg family is growing. I wonder if ffmpeg will add new products next year.

https://gitlab.com/wg1/jpeg-xl
PS I am busy, you can compile the codec yourself.
Jamaika is offline   Reply With Quote
Old 31st December 2019, 08:11   #167  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
So it has been written, so it shall be done.

Win64 AVX2: https://mega.nz/#!opJwGaaK!9PvdLVknq...DZTtWnx2jYtsz8
I haven't really seen it run multithreaded, could be a problem with my build. Compiling it on Windows has been a bit of a pain.

Metrics chosen: DSSIM and SSIMULACRA, based on some tests I ran: https://github.com/SmilingWolf/VQMTCrossVal
Dataset: 24 photographic images, converted to YUV444 when needed, eg. for libaom (AVIF), rav1e, x265 (HEIF)

First results:


BDRates:
Code:
Anchor: MozJPEG, Pixfmt: yuv444p

|       |     PSNR |      SSIM |   PSNR-HVS-M |    MS-SSIM |     VMAF |    DSSIM |   SSIMULACRA |   Butteraugli |
|-------|----------|-----------|--------------|------------|----------|----------|--------------|---------------|
| VP9   | -57.0804 | -47.6035  |     -39.8609 | -43.8144   | -51.2703 | -40.0591 |     -45.6282 |      -11.4759 |
| rav1e | -56.3667 | -50.742   |     -40.7575 | -46.2724   | -36.2597 | -36.7846 |     -44.047  |      -10.7987 |
| HEIF  | -61.1283 | -54.1593  |     -47.4304 | -52.0366   | -55.6929 | -51.0367 |     -54.9468 |      -34.716  |
| AVIF  | -64.8833 | -56.8196  |     -48.5822 | -52.1488   | -58.0279 | -48.2892 |     -55.1035 |      -27.4204 |
| JXL   | -11.3135 |   3.43907 |      18.5342 |   0.262228 | -15.0838 | -37.5572 |     -43.8005 |      -38.0935 |
BDRates only considering results where BPP >= 0.5:
Code:
Anchor: MozJPEG, Pixfmt: yuv444p

|       |     PSNR |     SSIM |   PSNR-HVS-M |   MS-SSIM |      VMAF |    DSSIM |   SSIMULACRA |   Butteraugli |
|-------|----------|----------|--------------|-----------|-----------|----------|--------------|---------------|
| VP9   | -48.8105 | -33.6331 |     -20.5436 |  -25.8753 | -46.5842  | -20.2622 |     -32.2217 |      -15.5581 |
| rav1e | -49.0907 | -35.3474 |     -20.8911 |  -27.1528 | -38.7075  | -20.164  |     -32.4197 |      -21.2363 |
| HEIF  | -50.0149 | -39.1381 |     -27.7217 |  -32.0109 | -48.8714  | -29.2475 |     -41.565  |      -39.2024 |
| AVIF  | -53.1125 | -40.4173 |     -24.153  |  -30.6302 | -48.4774  | -25.0276 |     -40.1755 |      -35.5703 |
| JXL   |  17.4175 | 104.61   |     110.595  |   81.5671 |   4.37415 | -33.6651 |     -44.0711 |      -62.3568 |
Made some tests with the kind people on the AV1 Discord, we pretty much agreed that a cutoff between JPEG XL and x265 at around 0.5-0.6 BPP looks sane.

Last edited by SmilingWolf; 31st December 2019 at 08:26.
SmilingWolf is offline   Reply With Quote
Old 1st January 2020, 09:19   #168  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 656
Thanks for the answer, codec AVX2 and tests.
What can you say about Google PIK, jpeg lossless, FLIF, FUIF projects. Are they included in JPEGXL?
What do you recommend entropy coder lossless? FSE, google PIK, or brotli.

I personally have some doubts when compiling under Windows for SSE2.

Strange files not included to the codec. For GCC is rubbish.
dct.cc, epf_dispatch.cc, jpegxl_emcc.cc, optimize.cc, predictor.cc

Why is the APNG library associated with libpng and not lodePNG ???

The advantage of the codec is finally quick thread service compared to google PIK.

PS I add codec JPEGXL SSE Windows in a week.
Code:
jpegxl_emcc.cc:76:50: error: call of overloaded 'make_unique<jxl::ExternalImage>(jxl::ThreadPool*&, const Image3F&, jxl::Rect&, const jxl::ColorEncoding&, const jxl::ColorEncoding&, const bool&, jxl::ImageU*, const size_t&, size_t&, const bool&, jxl::CodecIntervals*&)' is ambiguous
   76 |       bits_per_sample, big_endian, temp_intervals);
      |                                                  ^
In file included from c:\msys1000\x86_64-w64-mingw32\include\jxl\codec_in_out.h:26,
                 from c:\msys1000\x86_64-w64-mingw32\include\jxl\brunsli.h:27,
                 from jpegxl_emcc.cc:16:
c:\msys1000\x86_64-w64-mingw32\include\jxl\common.h:123:20: note: candidate: 'std::unique_ptr<_Tp> jxl::make_unique(Args&& ...) [with T = jxl::ExternalImage; Args = {jxl::ThreadPool*&, const jxl::Image3<float>&, jxl::Rect&, const jxl::ColorEncoding&, const jxl::ColorEncoding&, const bool&, jxl::Plane<short unsigned int>*, const long long unsigned int&, long long unsigned int&, const bool&, std::array<jxl::CodecInterval, 4>*&}]'
  123 | std::unique_ptr<T> make_unique(Args&&... args) {
      |                    ^~~~~~~~~~~
In file included from c:\msys1000\include\c++\10.0.0\memory:82,
                 from c:\msys1000\x86_64-w64-mingw32\include\jxl\base\padded_bytes.h:25,
                 from c:\msys1000\x86_64-w64-mingw32\include\jxl\brunsli.h:24,
                 from jpegxl_emcc.cc:16:
c:\msys1000\include\c++\10.0.0\bits\unique_ptr.h:925:5: note: candidate: 'typename std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with _Tp = jxl::ExternalImage; _Args = {jxl::ThreadPool*&, const jxl::Image3<float>&, jxl::Rect&, const jxl::ColorEncoding&, const jxl::ColorEncoding&, const bool&, jxl::Plane<short unsigned int>*, const long long unsigned int&, long long unsigned int&, const bool&, std::array<jxl::CodecInterval, 4>*&}; typename std::_MakeUniq<_Tp>::__single_object = std::unique_ptr<jxl::ExternalImage>]'
  925 |     make_unique(_Args&&... __args)
      |     ^~~~~~~~~~~

Last edited by Jamaika; 4th January 2020 at 13:59.
Jamaika is offline   Reply With Quote
Old 2nd January 2020, 01:30   #169  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,316
Quote:
Originally Posted by SmilingWolf View Post
Made some tests with the kind people on the AV1 Discord, we pretty much agreed that a cutoff between JPEG XL and x265 at around 0.5-0.6 BPP looks sane.
Thank You for comparison. Jpeg XL has an excelent quality. Good quality starts at 0.5 BPP anyway with any format.

There is some additional test. https://www.reddit.com/r/jpegxl/comm...oposals_based/
IgorC is offline   Reply With Quote
Old 2nd January 2020, 21:27   #170  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 656
JPEGXL has added a lot of other libraries. When compiling the JPEG XL codec, you can ask question? Is it possible to import jpeg photos including jpegXT family? I mean about JPEG 10bit photos, e.g. Panasonic and HDR gamma.
To check this, you need to have good jpegXT/LS codecs to test the jpegXL and the question arises why did the developers not add jpegXT only libjpeg and sjpeg based webp? Users will not test this with ffmpeg either.
JpegXT is specifically created in GCC. The basic GCC functions {-o2 / -o3 -ftree-vectorize or -flto} cann't be used. The {-std=gnu++11 -ggdb3} function is only works. This makes the codec has big size and not functional as a plugin for other codecs. The codec has four preset: Sequential, Progressive, LossLess and the Baseline standard.
Code:
jpegXT.exe -q 90 -h -l image_21447.ppm image_21447_(s).jpg {Sequential} [HDR (-r) use only with (-c)???] {nearby lossless without (-c)}
jpegXT.exe -q 90 -h -v -qt 3 -oz -s 1x1,2x2,2x2 image_21447.ppm image_21447_(p).jpg {Progressive}
jpegXT.exe -q 90 -h image_21447.ppm image_21447_(b).jpg {Sequential}
jpegXT.exe {Baseline???} [not standard function -c as rgb24 and -r as HDR]
jpegXT.exe -q 100 -h -p -c image_21447.ppm image_21447_(l).jpg {LossLess} [don't use HDR??? (-r) error][recommended with (-c) for ffplay][not recommended for JPEGXL]
jpegLS.exe -encodepnm image_21447.ppm image_21447_(l).jpg {JpegLS} [not recommended for JPEGXL]
jpegXT.exe -q 100 -ls1 -c image_21447.ppm image_21447_(s).jpg {JpegLS} [interleaved][not recommended optimise Huffman][don't use HDR??? (-r) error]
jpegXT.exe image_21447_(...).jpg image_21447_(...).ppm
JpegXT create bad 12bit. So we're talking only about paid software here ex. Image Converter Plus.
Code:
jpegXT.exe -q 90 -h -v -r12 image_21447.ppm image_21447_12xt.jpg
Should be:
Stream #0:0: Video: mjpeg (Progressive), yuv444p16le(12 bpc, pc, bt470bg/unknown/unknown)

Currently, the ffplay converter can correctly display all preset options. It can be said that ffplay has a built-in extended jpegXT/LS family. FFplay doesn't display info additional HDR and gamma options.
This is sometimes helpful when determining whether a given codec converts jpeg photos well.
Stream # 0: 0: Video: mjpeg (Baseline), yuvj420p (pc, bt470bg / unknown / unknown)

Summarizing:
jpegXL doesn't import Lossless options brg24/rgb24. I cann't add 10, 12 or 16bit files.

Did I create something?
Yes, I compiled JPEGXL for SSE Windows. Is it working properly? I don't know that, but it starts quickly and has responsive options.

Code:
Library:          libJPEGXL                  c++ [30 Dec 2019] {include PIK,FUIF}
                  brotli                     c   [19 Dec 2019]
                  brunsli                    c++ [31 Oct 2019]
                  butteraugli JXL            c++ [30 Dec 2019]
                  highway     JXL            c++ [30 Dec 2019]
                  skcms                      c++ [31 Dec 2019]
                  libJPEG-turbo 2.0.4  8bit  c   [30 Dec 2019]
                  libsJPEG      0.1.0        c++ [12 Mar 2019]
                  lodePNG                    c++ [19 Dec 2019]
                  libPNG        1.6.38       c   [20 Apr 2019] {for APNG}
                  giflib        5.2.1        c   [24 Jun 2019]
                    zlib        1.2.11.1     c   [09 Jul 2019]
                  openexr       2.4.0        c++ [03 Dec 2019] {instead TIFF, Adobe DNG}
Compiled by Jamaika
Edit: corrected JPEGXT
https://www.sendspace.com/file/0mbasu

Last edited by Jamaika; 5th January 2020 at 12:22.
Jamaika is offline   Reply With Quote
Old 3rd January 2020, 23:30   #171  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,089
Quote:
Originally Posted by foxyshadis View Post
I didn't know that JPEG XL could losslessly compact JPEG images to the new format. They really are trying to be as backward compatible as possible.
JPEG's entropy encoding is pretty darn weak. Adding modern arithmetic coding can save significant bits without changing the actual visual data. There have been formats doing that kind of stuff for a couple of decades now. The Stuffit guys (old Mac OS compression software) had a lossless JPEG repacker back then at least.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd January 2020, 23:35   #172  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,089
Quote:
Originally Posted by IgorC View Post
Reading the requirements, it sounds like just doing HEVC in HEIF would do pretty much everything desired.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th January 2020, 06:03   #173  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,316
Quote:
Originally Posted by benwaggoner View Post
Reading the requirements, it sounds like just doing HEVC in HEIF would do pretty much everything desired.
Reading your every comment, it sounds like just doing HEVC everywhere would do pretty much everything. Literally.
IgorC is offline   Reply With Quote
Old 5th January 2020, 14:28   #174  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 468
Quote:
Originally Posted by benwaggoner View Post
Reading the requirements, it sounds like just doing HEVC in HEIF would do pretty much everything desired.
I would guess that both, the HEVC and HEIF implementation would be pretty complex to implement. That said we don't know what the end result of JPEG XL will be but I think simpler?
And would something like a free baseline be even possible with the current HEVC license situation?


And on that note is anything known about the licensing of JPEG XL? What is the free baseline missing or rather what will need commercial licensing?
__________________
x264 full help - x264 --fullhelp r2345
Cuttermaran HCEnc provider - Support for HCEnc in Cuttermaran
DualDVDRB - Dual core support for DVD-RB free
Rumbah is offline   Reply With Quote
Old 5th January 2020, 16:20   #175  |  Link
Sparktank
47.952fps@71.928Hz
 
Sparktank's Avatar
 
Join Date: Mar 2011
Posts: 913
Quote:
Originally Posted by benwaggoner View Post
JPEG's entropy encoding is pretty darn weak. Adding modern arithmetic coding can save significant bits without changing the actual visual data. There have been formats doing that kind of stuff for a couple of decades now. The Stuffit guys (old Mac OS compression software) had a lossless JPEG repacker back then at least.
Go on. You have really informative posts to read. Don't be shy to write too much. Every time I see you post, I want to read more. There's a few others here on doom9 that I enjoy reading.
__________________
Win10 (x64) build 18362| GPU Caps Viewer 1.42.4.0
NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 | (r435_95-4)
NTSC | DVD: R1 | BD: A
Intel Xeon X5660 @2.80GHz
Sparktank is offline   Reply With Quote
Old 6th January 2020, 04:06   #176  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,089
Quote:
Originally Posted by IgorC View Post
Reading your every comment, it sounds like just doing HEVC everywhere would do pretty much everything. Literally.
I haven't done much comparison with AV1 for still images yet, and I'm sure VVC will outperform HEVC and AV1 for images as well.

Still image psychovisual tuning is somewhat different than for video, so maturity of encoder is going to be a big factor as well.

I must say, I freak out a little bit whenever I see VMAF being used to compare still image encoding, since the ML model was never even trained on that scenario.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 6th January 2020, 07:28   #177  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 656
http://libwebpjs.appspot.com/jpegxl/
Jpegxl appeared in the cloud. Of course, the added photos are public.
Jamaika is offline   Reply With Quote
Old 6th January 2020, 21:49   #178  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,089
Quote:
Originally Posted by Rumbah View Post
I would guess that both, the HEVC and HEIF implementation would be pretty complex to implement. That said we don't know what the end result of JPEG XL will be but I think simpler?
HEIF is a pretty straightforward container format. Implementing every last feature would be a good chunk of work, but a subset that doesn't include animation and other complex stuff wouldn't be that bad.

Encoding and decoding HEVC can be done in HW on the large majority of mobile devices today, All MacOS, and I'd guess the significant majority of Windows systems. The Chrome and Firefox browsers, which explicitly block decoding of HEVC by the OS or GPU, are the biggest holes now.

Quote:
And would something like a free baseline be even possible with the current HEVC license situation?
That is an important question, and one I don't know the answer to. A LOT of that patents asserted in HEVC pertain to interframe encoding, which wouldn't apply to still-only encoding. Who is asserting what that applies to what is the big question. Apple certainly didn't consider that a blocker when they made HEIF HEVC the default image file format in iOS.

There are certainly practical reasons pushing back against HEIF HEVC; I was really talking about JPEG's technical requirements list.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th January 2020, 11:23   #179  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 93
Quote:
Originally Posted by Jamaika View Post
... sjpeg based webp? ...
https://www.sendspace.com/file/0mbasu
sjpeg is a separate and independent jpeg encoder ('regular' old-school jpeg, ITU-t81), used 10's of billions of time daily at Google. It has nothing to do with the rest of the "JPEG family", nor WebP.

skal/
skal is offline   Reply With Quote
Old 9th January 2020, 09:09   #180  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 19
Hi SmilingWolf,

> Compiling it on Windows has been a bit of a pain.
Glad to hear you got it working. Thank you for sharing these results!

I made the code Windows-compatible a while back but there may be regressions.
Would you consider raising an issue mentioning any warnings/errors/incompatibilities?


Hi Jamaika,
> What can you say about Google PIK, jpeg lossless, FLIF, FUIF projects. Are they included in JPEGXL?
Yes, JPEG XL incorporates (enhanced versions of) PIK and FUIF.

> jpegxl_emcc.cc:76:50: error: call of overloaded 'make_unique
Thank you for reporting this, I have fixed it and we'll periodically update the jpeg-xl repo. You can also work around this by disabling C++14 support in the compiler.


Hi Ben,
> Reading the requirements
That list is abridged. If you're interested and have livelink access, the document number is wg1n83043.
Jan Wassenberg is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.