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 29th January 2020, 11:02   #201  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 17
Thanks for trying it, that is a surprising outcome. I ran a similar test (with somewhat newer code, but doubt that makes a difference), and see distance 1.17 reached with ar=1 and 1.10 with ar=0.

Would you mind sharing that image? I wonder if it is 4:2:0, or has interesting characteristics.
Jan Wassenberg is offline   Reply With Quote
Old 29th January 2020, 12:43   #202  |  Link
kanaka
Registered User
 
Join Date: Jan 2019
Posts: 19
Quote:
Originally Posted by Jan Wassenberg View Post
Would you mind sharing that image? I wonder if it is 4:2:0, or has interesting characteristics.
This image hasn't subsampling. It is taken from encode.su
I've uploaded all files here https://drive.google.com/drive/folde...WoiQhX9nHiasMZ
kanaka is offline   Reply With Quote
Old 30th January 2020, 07:52   #203  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 17
Thank you for sharing the image! I have tested with the current code and see a distance of 1.0935496092 with default flags (ar on, target distance 1). Looks like we indeed had an issue that has been fixed.

We plan on syncing the code again soon to gitlab.com/wg1/jpeg-xl.
Jan Wassenberg is offline   Reply With Quote
Old 31st January 2020, 11:25   #204  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 648
Quote:
Originally Posted by kanaka View Post
This image hasn't subsampling. It is taken from encode.su
I've uploaded all files here https://drive.google.com/drive/folde...WoiQhX9nHiasMZ
New butteraugli with JpegXL
https://www.sendspace.com/file/uzd2jm
Jamaika is offline   Reply With Quote
Old 6th February 2020, 19:08   #205  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
The JPEG-XL repo has been updated today, fresh build for commit b3a65719 (AVX2 required): https://mega.nz/#!IswGxSQT!N17WHrUka...wDOKKOapgu5pq0
SmilingWolf is offline   Reply With Quote
Old 7th February 2020, 09:18   #206  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 17
Quote:
Originally Posted by SmilingWolf View Post
The JPEG-XL repo has been updated today
Thank you for noticing and sharing a build so quickly
FYI this includes a simplified cjpegxl command line interface and help; feedback is very welcome.
Jan Wassenberg is offline   Reply With Quote
Old 7th February 2020, 13:19   #207  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 648
THX team JpegXL
Unfortunately JpegXL SSE doesn't work with gcc10.
https://www.sendspace.com/file/3moype

cjpegXL_jxl.exe image_21447_(s)_YCbCr.jpg image_21447_(s)_YCbCr.jxl -v -q 90
Jamaika is offline   Reply With Quote
Old 7th February 2020, 15:23   #208  |  Link
paul97
Registered User
 
Join Date: Mar 2018
Posts: 7
Would be nice to have also the support on http://libwebpjs.appspot.com/jpegxl/
paul97 is offline   Reply With Quote
Old 7th February 2020, 18:14   #209  |  Link
kanaka
Registered User
 
Join Date: Jan 2019
Posts: 19
There is something wrong with speed kitten and tortoise. It gives huge files
Where is jpeg lossles repacking option (-j) ?

Last edited by kanaka; 7th February 2020 at 18:23.
kanaka is offline   Reply With Quote
Old 7th February 2020, 18:58   #210  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
Quote:
Originally Posted by kanaka View Post
Where is jpeg lossles repacking option (-j) ?
Still there, just hidden. Use cjpegxl.exe -v -help to see the full list of options.

The explanation with the different "kinds" of lossless implied by different Q settings ("mathematically", "visually in flicker test", "visually in side by side comparison") is a nice touch.
Previously, if I got it right, -Q was supposed to be used with modular encoding (-g option) and --distance with VarDCT/the default mode.
How does the "new" -Q work?
SmilingWolf is offline   Reply With Quote
Old 8th February 2020, 10:38   #211  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 17
Quote:
Originally Posted by kanaka View Post
There is something wrong with speed kitten and tortoise. It gives huge files
Sorry to hear that, I tried on deer from imagecompression.info and didn't see a size increase. Can you share the image?

Quote:
Originally Posted by SmilingWolf
Previously, if I got it right, -Q was supposed to be used with modular encoding (-g option) and --distance with VarDCT/the default mode.
How does the "new" -Q work?
Right, the new (lowercase) -q sets what was previously --distance or -Q. The mapping function is in JxlCompressArgs::ValidateArgs.
Jan Wassenberg is offline   Reply With Quote
Old 8th February 2020, 12:13   #212  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
So from the comments in the code it seems to translate to:
- -q < -1000 uses VarDCT, --distance 1.0
- -q == 100 uses modular encoding, lossless
- -q between 40 and 100 uses VarDCT with --distance between 18.77 and 0.1111
-- -q 95 == --distance 0.444
-- -q 90 == --distance 1.000
- -q between 0 and 40 uses modular encoding with -Q between 0 and -1600
SmilingWolf is offline   Reply With Quote
Old 8th February 2020, 14:18   #213  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 857
Quote:
Originally Posted by kanaka View Post
There is something wrong with speed kitten and tortoise. It gives huge files
That is my experience as well. The slowest preset especially gives significantly bigger filesizes compared to the default, and the visual quality is not improving either in my opinion.
Tommy Carrot is offline   Reply With Quote
Old 8th February 2020, 17:16   #214  |  Link
Jan Wassenberg
Registered User
 
Join Date: Jan 2020
Location: Switzerland
Posts: 17
Quote:
Originally Posted by SmilingWolf View Post
So from the comments in the code it seems to translate to
Thank you for summarizing it here!

Quote:
Originally Posted by Tommy Carrot View Post
That is my experience as well. The slowest preset especially gives significantly bigger filesizes compared to the default, and the visual quality is not improving either in my opinion.
Can you help us understand this by sharing the distance/settings and the image, perhaps in a Gitlab issue?

The slower modes do hit the target distance more exactly, at the cost of some more bits. I do agree that squirrel modes and faster (even up to cheetah) are quite attractive points on the speed/size curve.
Jan Wassenberg is offline   Reply With Quote
Old 14th February 2020, 10:01   #215  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 648
Code:
Library enc/dec:
libJPEGLS    2.1.1+   [02 Feb 2020] 8/16bit C⁺⁺14
libJPEG      9.4      [12 Jan 2020] 8+10+12bit
libJPEGturbo 2.0.4+   [08 Jan 2020] 8bit (can use mozJPEG or libjpeg 9.3, don't use jpegXT)
openjpeg     2.3.1+   [13 Feb 2020]
OpenJPH               [02 Feb 2020] C⁺⁺11
JpegXL                [06 Feb 2020] C⁺⁺11
OpenEXR      2.4.0+   [10 Feb 2020] C⁺⁺11
lodepng               [11 Feb 2020] C⁺⁺11 don't use libpng 
libWebP      1.1.0+   [08 Feb 2020] don't use images 16bit PPM
jvetvvc      7.3+     [13 Feb 2020] C⁺⁺11 8+10+12bit {disable TRACING, SIMD} {no import y4m}
libheif HDR  1.6.1+   [31 Jan 2020] C⁺⁺11 only 8bit
libTIFF      4.1.0+   [09 Feb 2020]
liblcms2     2.0.10+  [08 Jan 2020]
https://www.sendspace.com/file/hohhje

New function in openJPEG fom mjpeg 2K<>8K:
Code:
-IMF <PROFILE>[,mainlevel=X][,sublevel=Y][,framerate=FPS]
    Interoperable Master Format compliant codestream.
    <PROFILE>=2K, 4K, 8K, 2K_R, 4K_R or 8K_R.
    X >= 0 and X <= 11.
    Y >= 0 and Y <= 9.
    framerate > 0 may be specified to enhance checks and set maximum bit rate when Y > 0.
New function in libjpeg 9d 8/10/12bit include with JpegXT:
Code:
  -rgb           Create RGB JPEG file slow compression)
  -progressive   Create progressive JPEG file
  -rgb1          Create RGB JPEG file with reversible color transform
  -bgycc         Create big gamut YCC JPEG file
New function in JpegXL 02.02.2020:
Code:
Usage: cjpegXL_jxl.exe [OPTIONS]
 --container
    encode using container format {the function doesn't distinguish between JPEG containers}
 -q QUALITY, --quality=QUALITY
    Quality setting. Range: 0 .. 100.
    100 = mathematically lossless. Default for already-lossy input (JPEG/GIF)
    95 = visually lossless (flicker-test).
    90 = visually lossless (side by side). Default for generic input.
 -s SPEED, --speed=SPEED
    Encoder effort/speed setting. Valid values are:
    3|falcon| 4|cheetah| 5|hare| 6|wombat| 7|squirrel| 8|kitten| 9|tortoise
    Default: squirrel (7). Values are in order from faster to slower.
 -p, --progressive
    Enable progressive/responsive decoding.
New function in openJPH:
Code:
The following option has a default value (optional):
 -num_decomps  (5) number of decompositions
 -qstep        (1.0/255,0) quantization step size; all quantization
               step sizes are derived from this.
 -reversible   (false) for irreversible adnd true for reversible
 -colour_trans (true) if there are three color components that are
               downsampled by the same amount then the color transform
               is optional. This option is also available if there are
               more than three colour components, where it is applied
               to the first three colour components
 -prog_order   (RPCL) is the progression order, and can be one of:
               LRCP, RLCP, RPCL, PCRL, CPRL
 -block_size   {x,y} (64,64) where x and y are the height and width of
               a codeblock. In unix-like environment, { and } must be
               proceeded by a \
 -precincts    {x,y},{x,y},...,{x,y} where {x,y} is the precinct size
               starting from the coarest resolution; the last precinct
               is repeated for all finer resolutions
 -tile_offset  {x,y} tile offset.
 -tile_size    {x,y} tile width and height.
 -image_offset {x,y} image offset from origin.
 -profile      (None) is the profile, the code will check if the
               selected options meet the profile.  Currently only
               BROADCAST and IMF are supported

Last edited by Jamaika; 14th February 2020 at 10:58.
Jamaika is offline   Reply With Quote
Old 15th February 2020, 11:26   #216  |  Link
Thundik81
Registered User
 
Join Date: Jul 2004
Posts: 11
https://netflixtechblog.com/avif-for...ng-b1d75675fe4
Thundik81 is offline   Reply With Quote
Old 16th February 2020, 10:01   #217  |  Link
blurred
Registered User
 
Join Date: Jul 2016
Posts: 16
Nice comparisons including AVIF and JPEG XL: https://medium.com/@scopeburst/mozjp...n-44035c42abe8
https://imgsli.com/MTIxNTQ/
https://imgsli.com/MTIxNDg/
https://imgsli.com/MTIxNDk/
https://imgsli.com/MTE3ODc/
https://imgsli.com/MTE2MjI/
blurred is offline   Reply With Quote
Old 16th February 2020, 10:43   #218  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 648
These tests show me nothing. Nothing is described. What functions were used? what file sizes?
I know one thing. I ripped the RAW image with the road texture and compressed it with JPEG, VVC codecs. I don't see the thesis of the superiority of the new codecs over the old JPEG 420.
For old image HD isn't improvement. Finely grainy structures are blurred. J2K is the worst. Purple spots appear on the grays. VVC has the least blured for CTU128 at the same codecs size. Next OpenJPH for CTU64. Then the rest. That's the whole test.
Code:
cjpeg_08bit.exe -verbose -optimize -maxmemory 1000M -quality 42 111.ppm image_21447_08bit.jpg
jpegXT.exe -q 42 -h -s 1x1,2x2,2x2 111.ppm image_21447_12xt.jpg
cjpegXL_jxl.exe 111.ppm image_21447_(s)_YCbCr.jxl -q 78 -s 6 --jpeg_420
cjpegHTJ2K_j2c.exe -i 111.ppm -o image_21447.j2c -num_decomps 5 -block_size {64,64} -precincts {128,128},{256,256} -prog_order CPRL -colour_trans true -qstep 0.05
copenjpeg_j2k.exe -i 111.ppm -o YCoCg48(420)_lossless.j2k -r 45 -mct 1
EncoderApp_360.exe --SummaryVerboseness -c "encoder_randomaccess_vtm_2.cfg" --InputFile=113.yuv --BitstreamFile=video_2.vvc --SourceWidth=1280 --SourceHeight=720 --FrameRate=25.000 
--InputBitDepth=8 --InternalBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 --InputChromaFormat=420 --ChromaFormatIDC=420 --ConformanceWindowMode=0 --FramesToBeEncoded=1 
--MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 --Level=4 --BDPCM=1 --Tier=main --HashME=1 --IBC=1 --QP=28

Last edited by Jamaika; 16th February 2020 at 11:38.
Jamaika is offline   Reply With Quote
Old 16th February 2020, 13:23   #219  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 60
1. What about the file format / container that is generated by the reference implementation?

The spec hasn't released "Part 2, File format: Specifies an extensible box-based file format which adds support for metadata (EXIF and JUMBF)" https://jpeg.org/jpegxl/ ...

... and the code, at least to the in-code doc, seems to be simply the file format used by PIK: https://gitlab.com/wg1/jpeg-xl/-/blo...file_format.md

=> is this container final-ish, or just a hack for testing the code stream?

2. Thanks @blurred for the comparison links. But it's not just about pixel peeping ...

=> is it correct that HEVC/AV1 .AVIF/.HEIF only has yuv compression, and JPEG-XL (based on FLUF based on FLIF) lossless rgb, too?

Imho that's the big advantage of .WebP - it has excellent lossless or near-lossless rgb compression, which isn't outdated like lossy VP8.

3. Here comes WebP v2 :-) including "What can we do differently than AV1": https://www.youtube.com/watch?v=zogxpP2lm-o
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 16th February 2020 at 13:41.
Marsu42 is offline   Reply With Quote
Old 16th February 2020, 14:27   #220  |  Link
blurred
Registered User
 
Join Date: Jul 2016
Posts: 16
I don't know the details, but PIK/JPEG XL is the only one really preserving skin texture, also seen here (from https://encode.su/threads/3108-Googl...%D1%81ts/page2 ):

https://i.imgur.com/2dhkX8b.png

WebP v2 slides: https://aomedia.org/wp-content/uploa...ino_Google.pdf

It will be exciting year for image compression: HEIF vs AVIF vs JXL vs VVC vs WebP2 ...

Last edited by blurred; 16th February 2020 at 14:29.
blurred 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 07:38.


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