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 9th January 2020, 18:29   #181  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
I'll open an issue, but first, are there official guidelines to build on Windows, possibly using static linking?

I'm using a MSYS2+CMake+Clang env to compile.
A few notes off the top of my head:
- I had to empty the targets array within jpegxltests.cmake because one or more of them were failing to build, one of those was jxl/threads/thread_parallel_runner_test.cc for sure;
- disabled TCMalloc and anything having to do with GMock/GTest because of misc build errors, some of them given by -Werror, some nastier to fix;
- I had to build djpeg_main.cc by hand specifying -DJPEGXL_STATIC_DEFINE=1 for some reason, it was mixing up dynamic and static function declarations/imports;
- replaced the clang-cl specific line @ https://gitlab.com/wg1/jpeg-xl/blob/...Lists.txt#L147 with the same flags as right above, the ones from "if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86_64")"

Last edited by SmilingWolf; 9th January 2020 at 19:12.
SmilingWolf is offline   Reply With Quote
Old 9th January 2020, 21:32   #182  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 808
Quote:
Originally Posted by skal View Post
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.
Thank you for the correction. I suggested the creators of webmproject and the wording of sjpeg on websites as lossless.
Jamaika is offline   Reply With Quote
Old 9th January 2020, 21:42   #183  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 808
Quote:
Originally Posted by Jan Wassenberg View Post
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.
Welcome to the doom9 forum, the creator of JPEGXL.
We look forward to the successful development of the codec and keep our fingers crossed.
My comments are rather written out of curiosity and I don't think they add much.
Here are some curiosities, links, some compiled jpeg codecs and stagnation on the creative market.

Last edited by Jamaika; 9th January 2020 at 22:50.
Jamaika is offline   Reply With Quote
Old 9th January 2020, 21:48   #184  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 808
Quote:
Originally Posted by SmilingWolf View Post
I'll open an issue, but first, are there official guidelines to build on Windows, possibly using static linking?

I'm using a MSYS2+CMake+Clang env to compile.
A few notes off the top of my head:
- I had to empty the targets array within jpegxltests.cmake because one or more of them were failing to build, one of those was jxl/threads/thread_parallel_runner_test.cc for sure;
- disabled TCMalloc and anything having to do with GMock/GTest because of misc build errors, some of them given by -Werror, some nastier to fix;
- I had to build djpeg_main.cc by hand specifying -DJPEGXL_STATIC_DEFINE=1 for some reason, it was mixing up dynamic and static function declarations/imports;
- replaced the clang-cl specific line @ https://gitlab.com/wg1/jpeg-xl/blob/...Lists.txt#L147 with the same flags as right above, the ones from "if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86_64")"
I used the commands entered manually under GCC 10.0. I can't know otherwise and of course I know that Windows is the best VIsual Studio XXX.
Code:
echo off
set PATH=C:\MSYS1000\bin;%PATH%
rem echo %PATH%
rem cd "C:\MSYS1000\bin"

for %%f in ("%~dp1*.cc") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -DJPEGXL_VERSION="(unknown)" -DBROTLI_BUILD_64_BIT=1 -DPNG_DEBUG=0 -DBITS_IN_JSAMPLE=8 -DINLINE="inline __attribute__((always_inline))" -DLOCAL(type)="static type" -DJPEGXL_MAJOR_VERSION=0 -DJPEGXL_MINOR_VERSION=0 -DJPEGXL_PATCH_VERSION=0 -DJPEGXL_ENABLE_EXR=1 -DJPEGXL_ENABLE_SJPEG=1 -DHWY_RUNTIME_TARGETS=HWY_NONE -DHWY_STATIC_TARGETS=HWY_NONE -DHWY_ARCH=HWY_ARCH_X86 -c %%f -o %%~nf.o


cd giflib
for %%f in ("%~dp1*.c") do gcc.exe -std=gnu11 -fPIC -ftree-vectorize -g0 -O3 -DWIN32 -c %%f -o %%~nf.o
cd ..
cd libz
for %%f in ("%~dp1*.c") do gcc.exe -std=gnu11 -fPIC -ftree-vectorize -g0 -O3 -DWIN32 -c %%f -o %%~nf.o
cd ..
cd libjpeg
for %%f in ("%~dp1*.c") do gcc.exe -std=gnu11 -fPIC -ftree-vectorize -g0 -O3 -DWIN32 -DBITS_IN_JSAMPLE=8 -DINLINE="inline __attribute__((always_inline))" -DLOCAL(type)="static type" -c %%f -o %%~nf.o
cd ..
cd libpng
for %%f in ("%~dp1*.c") do gcc.exe -std=gnu11 -fPIC -ftree-vectorize -g0 -O3 -DWIN32 -DPNG_DEBUG=0 -c %%f -o %%~nf.o
cd ..

cd brotli\enc
for %%f in ("%~dp1*.c") do gcc.exe -std=gnu11 -ftree-vectorize -g0 -O3 -fPIC -DBROTLI_BUILD_64_BIT=1 -c %%f -o %%~nf.o
cd ..\..
cd brotli\dec
for %%f in ("%~dp1*.c") do gcc.exe -std=gnu11 -ftree-vectorize -g0 -O3 -fPIC -DBROTLI_BUILD_64_BIT=1 -c %%f -o %%~nf.o
cd ..\..
cd brotli\common
for %%f in ("%~dp1*.c") do gcc.exe -std=gnu11 -ftree-vectorize -g0 -O3 -fPIC -DBROTLI_BUILD_64_BIT=1 -c %%f -o %%~nf.o
cd ..\..

cd iex
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -DDEBUG -ftree-vectorize -g0 -O3 -fPIC -DWIN32 -DILMBASE_FORCE_CXX03 -DPLATFORM_WINDOWS -c %%f -o %%~nf.o
cd ..
cd ilmThread
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -DDEBUG -ftree-vectorize -g0 -O3 -fPIC -DWIN32 -DILMBASE_FORCE_CXX03 -DPLATFORM_WINDOWS -c %%f -o %%~nf.o
cd ..
cd Imath
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -DDEBUG -ftree-vectorize -g0 -O3 -fPIC -DWIN32 -DILMBASE_FORCE_CXX03 -DPLATFORM_WINDOWS -c %%f -o %%~nf.o
cd ..
cd Half
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -DDEBUG -ftree-vectorize -g0 -O3 -fPIC -DWIN32 -DILMBASE_FORCE_CXX03 -DPLATFORM_WINDOWS -c %%f -o %%~nf.o
cd ..
cd IlmImf
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -DDEBUG -ftree-vectorize -g0 -O3 -fPIC -DWIN32 -DILMBASE_FORCE_CXX03 -DPLATFORM_WINDOWS -c %%f -o %%~nf.o
cd ..

cd libsjpeg
for %%f in ("%~dp1*.cc") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -c %%f -o %%~nf.o
cd ..
cd butteraugli
for %%f in ("%~dp1*.cc") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -c %%f -o %%~nf.o
cd ..
cd base
for %%f in ("%~dp1*.cc") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -DHWY_RUNTIME_TARGETS=HWY_NONE -DHWY_STATIC_TARGETS=HWY_NONE -DHWY_ARCH=HWY_ARCH_X86 -c %%f -o %%~nf.o
cd ..
cd common
for %%f in ("%~dp1*.cc") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -c %%f -o %%~nf.o
cd ..
cd dec
for %%f in ("%~dp1*.cc") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -c %%f -o %%~nf.o
cd ..
cd enc
for %%f in ("%~dp1*.cc") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -c %%f -o %%~nf.o
cd ..
cd modular\encoding
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -DHWY_RUNTIME_TARGETS=HWY_NONE -DHWY_STATIC_TARGETS=HWY_NONE -DHWY_ARCH=HWY_ARCH_X86 -c %%f -o %%~nf.o
cd ..\..
cd modular\image
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -DHWY_RUNTIME_TARGETS=HWY_NONE -DHWY_STATIC_TARGETS=HWY_NONE -DHWY_ARCH=HWY_ARCH_X86 -c %%f -o %%~nf.o
cd ..\..
cd modular\ma
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -DHWY_RUNTIME_TARGETS=HWY_NONE -DHWY_STATIC_TARGETS=HWY_NONE -DHWY_ARCH=HWY_ARCH_X86 -c %%f -o %%~nf.o
cd ..\..
cd modular\transform
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -DJPEGXL_ENABLE_SKCMS=1 -DHWY_RUNTIME_TARGETS=HWY_NONE -DHWY_STATIC_TARGETS=HWY_NONE -DHWY_ARCH=HWY_ARCH_X86 -c %%f -o %%~nf.o
cd ..\..
I don't know where to download the file "epf_dispatch.h"

Changes to files:
skcms.cc
Code:
#if defined(__SSE__)
    #include <immintrin.h>
#endif
…
#if defined(__SSE__)
    #define N 4
    template <typename T> using V = Vec<N,T>;
    using Color = float;
#endif
…
#if !defined(__AVX2__) && !defined(__AVX512__) … namespace hsw {..}<--delete
jpegxl_emcc.cc
Code:
  result = jxl::make_unique<ExternalImage>(pool, ib.color(), rect,
What is JPEGXL_STATIC_DEFINE for? There is no such definition in JpegXL.

Last edited by Jamaika; 10th January 2020 at 11:06.
Jamaika is offline   Reply With Quote
Old 9th January 2020, 22:32   #185  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
Quote:
Originally Posted by Jamaika View Post
What is JPEGXL_STATIC_DEFINE for? There is no such definition in JpegXL.
It exists in an header generated by CMake.
The function that creates this header is called here -> https://gitlab.com/wg1/jpeg-xl/blob/...gxl.cmake#L369
Reference from the CMake manual: https://cmake.org/cmake/help/v3.16/m...ortHeader.html
SmilingWolf is offline   Reply With Quote
Old 10th January 2020, 08:33   #186  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 808
This is not found in other converters

Library enc/dec:
JPEGXL [29 Dec 2019] C⁺⁺11 new {if there is a color problem you can use lcms2, however the creator recommends skcms C⁺⁺11}
JPEGXT/LS [28 Aug 2019] 8/12bit C⁺⁺11 {ggdb3!!!}
JPEG2000 2.3.1+ [17 Nov 2019] C11
HTJPEG2000 [06 Jan 2020] 8/16bit C⁺⁺11 new
JPEGLS 2.1.1+ [05 Jan 2020] 8/16bit C⁺⁺14 new
libWebP 1.1.0+ [08 Jan 2020] 8bit C11 new
jvetvvc 7.1+ [08 Jan 2020] 8+10+12bit C⁺⁺11 {disable TRACING, SIMD} {no import y4m} new
Jamaika jvetvvc
HDRTools 0.19.1+ [03 Dec 2019] jvetvvc new {add support for the XYZ space used by JPEG XL}
360lib 10.0+ [03 Dec 2019] jvetvvc new
libheif HDR 1.6.1+ [29 Dec 2019] only 8bit

libTIFF 4.1.0+ [07 Jan 2020]
libRAW 0.19.5+ [05 Dec 2019] master
libJPEG_turbo 2.0.4+ [08 Jan 2020](can use mozJPEG or libjpeg 9.3, don't use jpegXT)
libexpat 2.2.9+ [01 Jan 2020]
liblcms2 2.0.10+ [06 Jan 2020]
freeGLUT 3.2.1+ [27 Oct 2019]

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

PS: When will JpegXS appear?

Last edited by Jamaika; 10th January 2020 at 11:41.
Jamaika is offline   Reply With Quote
Old 10th January 2020, 10:29   #187  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 20
Quote:
Originally Posted by SmilingWolf View Post
I'll open an issue, [..] are there official guidelines to build on Windows [..]?
Thanks! I had tested with the free MSVC preview with CMake support included, plus vckpg.

> one of those was jxl/threads/thread_parallel_runner_test.cc
OK, we'll be happy to fix if you can help post the error.

> - disabled TCMalloc and anything having to do with GMock/GTest
Yes, those are a bit difficult, FYI we no longer bundle gperftools/TCMalloc.

> - replaced the clang-cl specific line [..] with the same flags as right above
Thanks, I can fix upstream right away
Jan Wassenberg is offline   Reply With Quote
Old 10th January 2020, 10:30   #188  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 20
Quote:
Originally Posted by Jamaika View Post
Welcome to the doom9 forum, the creator of JPEGXL.
We look forward to the successful development of the codec and keep our fingers crossed.
Thank you for the warm welcome! JXL has been created by a large team

> I don't know where to download the file "epf_dispatch.h"
It has been deleted, we can also remove epf_dispatch.cc (I am doing so upstream).
Jan Wassenberg is offline   Reply With Quote
Old 10th January 2020, 11:26   #189  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,015
has Jpeg XL been ratified then as i see no mention on jpeg.org?
hajj_3 is offline   Reply With Quote
Old 10th January 2020, 15:39   #190  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 20
Quote:
Originally Posted by hajj_3 View Post
has Jpeg XL been ratified then as i see no mention on jpeg.org?
It is in the late stages of standardization, and updates will be shared on https://jpeg.org/news.html (expected in a few weeks).
Jan Wassenberg is offline   Reply With Quote
Old 11th January 2020, 15:34   #191  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,565
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.
I don't even count sitx and rk (anyone else remember WinRK?) as viable formats, more as experiments. At least any JPEG-* will end up in decoders for a good long while.

What I don't understand is why all the big JPEG libraries didn't immediately add arith coding in as soon as it expired, in 2011. All of our pics could be 20-30% smaller right now, for essentially no penalty at this point, an easy lossless conversion. JXL is basically grafting that together with a still version of H.264's SVC, to sidecar a diff image to add high-bit-depth/HDR on top of a standard JPEG. (And JPEG XT is just JPEG XL Extended, so XL really doesn't have a reason to exist anymore.)

I'm a huge fan of AVIF/HEIF, and little mooted formats before that, but I can't deny that their advantage is significantly reduced against something as simple as JPEG-arith or JP2.

Most of my love for AVIF/HEIF comes from the support of layering and positioning, though, something that image libraries are completely unwilling to even try to support so far. That alone might doom the format to just being a generic image format instead.
foxyshadis is offline   Reply With Quote
Old 12th January 2020, 09:32   #192  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 20
Quote:
Originally Posted by foxyshadis View Post
All of our pics could be 20-30% smaller right now
I'm a bit surprised by that estimate, IIRC we were seeing more like 10% benefit from arithmetic. Reaching 22% savings requires a more advanced context model (e.g. Brunsli, which is integrated into JXL).

Quote:
Originally Posted by foxyshadis View Post
grafting that together with a still version of H.264's SVC, to sidecar a diff image to add high-bit-depth/HDR on top of a standard JPEG.
Clarification: what you describe is JPEG XT.
XL allows high precision (> 16 bit), so it can do HDR without needing any extension layers.

Quote:
Originally Posted by foxyshadis View Post
Most of my love for AVIF/HEIF comes from the support of layering and positioning
Yes, we also think this is useful and it's supported in JXL.
Jan Wassenberg is offline   Reply With Quote
Old 16th January 2020, 18:55   #193  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 757
is the JPEG XL Reference encoder already tuned for maximum quality ( as in AV1 ) , or can we expect to squeeze even more out of it?

Last edited by iwod; 17th January 2020 at 05:26.
iwod is offline   Reply With Quote
Old 17th January 2020, 03:31   #194  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,598
Quote:
Originally Posted by iwod View Post
is the JPEG XL Reference encoder already tuned for maximum quality ( as in AV1 ) , or can he expect to squeeze even more out of it?
Psychovisual tuning is NEVER done. We've seen substantial JPEG improvements in the last decade (JPEGmini). I don't have any indication that AV1 is anything close to its maximum quality potential. Still image tuning is quite a different use case than for moving images.

It kind of freaks me out when people use VMAF for still images, because it is not trained on 0.1 fps content at all.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 17th January 2020, 18:26   #195  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 808
New version libjpeg 9d 2020
It's getting more and more interesting. Jpeg turbo is based on version 8. Does jpegXL prefer version 9?
codec_jpg.cc:199: Wrong JPEG library version: library is 90, caller expects 80
Optimize the optimal Huffman code table generation to produce
slightly smaller files. Thank to John Korejwa for suggestion.
Note: Requires rebuild of testimgp.jpg.

Decoding Huffman: Use default tables if tables are not defined.
Thank to Simone Azzalin for report (Motion JPEG),
and to Martin Strunz for hint.

Add sanity check in optimal Huffman code table generation.
Thank to Adam Farley for suggestion.

rdtarga.c: use read_byte(), with EOF check, instead of getc()
in read_*_pixel().
Thank to Chijin Zhou for cjpeg potential vulnerability report.

jmemnobs.c: respect the max_memory_to_use setting in
jpeg_mem_available() computation. Thank to Sheng Shu and
Dongdong She for djpeg potential vulnerability report.

jdarith.c, jdhuff.c: avoid left shift of negative value
compiler warning in decode_mcu_AC_refine().
Thank to Indu Bhagat for suggestion.

Add x64 (64-bit) platform support, avoid compiler warnings.
Thank to Jonathan Potter, Feiyun Wang, and Sheng Shu for suggestion.

Adjust libjpeg version specification for pkg-config file.
Thank to Chen Chen for suggestion.

Restore GIF read and write support from libjpeg version 6a.
Thank to Wolfgang Werner (W.W.) Heinz for suggestion.

Improve consistency in raw (downsampled) image data processing mode.
Thank to Zhongyuan Zhou for hint.

Avoid out of bounds array read (AC derived table pointers)
in start pass in jdhuff.c. Thank to Peng Li for report.

Improve code sanity (jdhuff.c).
Thank to Reza Mirzazade farkhani for reports.

Add jpegtran -drop option; add options to the crop extension and wipe
to fill the extra area with content from the source image region,
instead of gray out.

http://www.ijg.org/files/jpegsr9d.zip

Last edited by Jamaika; 17th January 2020 at 19:32.
Jamaika is offline   Reply With Quote
Old 18th January 2020, 10:01   #196  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 808
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]
                  liblcms2      2.10 alpha   c   [08 Jan 2020]
                  libJPEG-turbo 2.0.4 8bit   c   [08 Jan 2020] {don't use version 9}
                  libsJPEG      0.1.0        c++ [07 Jan 2020]
                  lodePNG                    c++ [12 Jan 2020]
                  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++ [16 Jan 2020] {instead TIFF, Adobe DNG}
Compiled by Jamaika
https://www.sendspace.com/file/38s2b2
Jamaika is offline   Reply With Quote
Old 18th January 2020, 22:13   #197  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 20
Quote:
Originally Posted by benwaggoner View Post
Psychovisual tuning is NEVER done.
Agreed, there are lots of improvements possible for the JXL encoder.

Quote:
Originally Posted by Jamaika
Jpeg turbo is based on version 8. Does jpegXL prefer version 9?
codec_jpg.cc:199: Wrong JPEG library version: library is 90, caller expects 80
Interesting, that check seems to be inside the JPEG library - apparently a mismatch between the include file and system library?
Jan Wassenberg is offline   Reply With Quote
Old 28th January 2020, 12:02   #198  |  Link
kanaka
Registered User
 
Join Date: Jan 2019
Posts: 20
I've made test of jpeg xl
Code:
cjpegxl.exe --distance=1.0 0067.jpg 0067.10.jxl
djpegxl.exe  0067.10.jxl 0067.10decoded.png
next i've checked quality:
Code:
butteraugli.exe 0067.jpg 0067.10decoded.png
its returned 1.468054 Why?
Distance is not the same as butteraugli quality?
kanaka is offline   Reply With Quote
Old 29th January 2020, 02:16   #199  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 20
Quote:
Originally Posted by kanaka View Post
cjpegxl.exe --distance=1.0
butteraugli.exe . returned 1.468054
Thanks for testing! Both are distances, but the cjpegxl parameter is a target. It will be reached fairly precisely when --adaptive_reconstruction 0, but when the loop filter is on, that leads to a somewhat higher distance than targeted.
Does that answer your question?
Jan Wassenberg is offline   Reply With Quote
Old 29th January 2020, 09:46   #200  |  Link
kanaka
Registered User
 
Join Date: Jan 2019
Posts: 20
Quote:
Originally Posted by Jan Wassenberg View Post
It will be reached fairly precisely when --adaptive_reconstruction 0
Yes. Thanks for your reply, but it doesn't help.

Code:
cjpegxl.exe --adaptive_reconstruction=0 --distance=1.0 0067.jpg 0067.10noada.jxl
butteraugli still returns 1.497234

Maybe i has old version of butteraugli or there is quality lost in color conversion? I don't know...
kanaka 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 14:25.


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