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 May 2019, 01:26   #141  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,006
It does quite probably depend on the GPU chipset supporting a specific version. Which GPU do you have?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 19th May 2019, 07:24   #142  |  Link
p0w3rh0u5e
Registered User
 
Join Date: Feb 2008
Posts: 21
Quote:
Originally Posted by LigH View Post
It does quite probably depend on the GPU chipset supporting a specific version. Which GPU do you have?
Yep, I think so too. I have an RTX 2060, newest drivers, win10.
p0w3rh0u5e is offline   Reply With Quote
Old 20th May 2019, 22:43   #143  |  Link
p0w3rh0u5e
Registered User
 
Join Date: Feb 2008
Posts: 21
Quote:
Originally Posted by LigH View Post
It does quite probably depend on the GPU chipset supporting a specific version. Which GPU do you have?
For CUDA i had a look into the DLL and SDK, and it seems that there is simply no function called "cuMemsetD8Async_V2", there is only a "cuMemsetD8Async". The functions without Async do have indeed a V2, so maybe it's a typo or NVIDIA killed this function in an updated SDK?
p0w3rh0u5e is offline   Reply With Quote
Old 24th May 2019, 06:31   #144  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
At the beginning I apologize for the mess.
Here I add codecs which I compiled in GCC as I could and quickly without testing.
Quote:
Are there any prerequisites to get OpenCL or CUDA running (like some runtime DLLs)?
Good question. I don't know what is the function '-c' for? In theory, you can add the nvcuda.dll file from your graphics card.

I will describe a little bit about the compilation.

First of all, I used the latest drivers with the old codec guetzli software (2017).

I'll give half my kingdom to the one who knows the answer.
Which software to merged to close cl.h and cuda.h libraries.

Thirdly. I have not found the new CUDA DRVAPI DYNLINK software and I do not know how to compile it. Otherwise it displays messages like the nvcuda.dll driver in Windows.
The easiest way to compile using the nvcuda.dll and OpenCL.dll driver files. However the program may be unstable because these files were not compiled in GCC.

g++.exe -ftree-vectorize -g0 -O3 -fPIC -Wall -Wextra butteraugli.o butteraugli_comparator.o dct_double.o debug_print.o entropy_encode.o fdct.o gamma_correct.o guetzli.o idct.o jpeg_data.o jpeg_data_decoder.o jpeg_data_encoder.o jpeg_data_reader.o jpeg_data_writer.o jpeg_huffman_decode.o output_image.o preprocess_downsample.o processor.o quality.o quantize.o score.o gflags\windows_port.o clguetzli\clbutter_comparator.o clguetzli\clguetzli.o clguetzli\clguetzli_test.o clguetzli\clguetzli.cl.o clguetzli\cuguetzli.o clguetzli\cumem_pool.o clguetzli\ocl.o clguetzli\ocu.o clguetzli\utils.o libpng\png.o libpng\pngerror.o libpng\pngget.o libpng\pngmem.o libpng\pngpread.o libpng\pngread.o libpng\pngrio.o libpng\pngrtran.o libpng\pngrutil.o libpng\pngset.o libpng\pngtrans.o libpng\pngwio.o libpng\pngwrite.o libpng\pngwtran.o libpng\pngwutil.o libz\adler32.o libz\crc32.o libz\deflate.o libz\gzclose.o libz\gzlib.o libz\gzread.o libz\gzwrite.o libz\infback.o libz\inffast.o libz\inflate.o libz\inftrees.o libz\trees.o libz\uncompr.o libz\zutil.o -L. -lnvcuda -lOpenCL -o guetzli_opencl_cuda_08bit.exe

Should I use the nvcc software? I don't know. In my opinion, it isn't necessary.

For OpenCL I've added version 200 and for CUDA version 9000
Code:
-D__CUDA_API_VERSION=9000 -DCL_TARGET_OPENCL_VERSION=200
How do I replace the OpenCL.dll file? It should be added:
clguetzli\icd.o clguetzli\icd_dispatch.o clguetzli\icd_test_log.o clguetzli\icd_windows.o clguetzli\icd_windows_hkr.o

don't add files:

clguetzli\cl.o clguetzli\cl_ext.o clguetzli\cl_gl.o clguetzli\icd.o clguetzli\icd_test_log.o

Missing commands in icd_windows_hkr.c :
Code:
-DCM_GETIDLIST_FILTER_CLASS=0x00000200 -DCM_GETIDLIST_FILTER_PRESENT=0x00000100 
#include <devpropdef.h>
DEFINE_DEVPROPKEY(DEVPKEY_Device_ClassGuid,              0xa45c254e, 0xdf1c, 0x4efd, 0x80, 0x20, 0x67, 0xd1, 0x46, 0xa8, 0x50, 0xe0, 10);
Missing commands in cl.c :
Code:
CL_API_ENTRY cl_command_queue CL_API_CALL
clCreateCommandQueueWithProperties(
    cl_context                  context,
    cl_device_id                device,
    const cl_queue_properties * properties,
    cl_int *                    errcode_ret) CL_API_SUFFIX__VERSION_2_0
{
    cl_command_queue obj = (cl_command_queue) malloc(sizeof(struct _cl_command_queue));
    obj->dispatch = dispatchTable;
    test_icd_stub_log("clCreateCommandQueueWithProperties(%p, %p, %x, %p)\n",
                      context,
                      device,
                      properties,
                      errcode_ret);
}
Missing commands in cuguetzli.cpp :
#include <math.h>

Delete commands in clguetzli.cl.cpp :
#define abs(exper) fabs((exper))

I don't know why guetzli has to read additional .cu/.cl files outside of the codec since it's added inside.

Remember to delete the commands in clguetzli.cl:
Code:
#if defined (__USE_OPENCL__) || defined (__USE_CUDA__)
...
#endif // __USE_OPENCL__
Problem with old cuda_drvapi_dynlink.c

Code:
clguetzli\clguetzli.cl.o:clguetzli.cl.cpp:(.text+0x1ff5d): undefined reference to `cuMemcpyDtoH_v2'
clguetzli\cuguetzli.o:cuguetzli.cpp:(.text+0x1f51): undefined reference to `cuMemcpyDtoHAsync_v2'
clguetzli\cuguetzli.o:cuguetzli.cpp:(.text+0x2041): undefined reference to `cuMemcpyDtoDAsync_v2'
clguetzli\cuguetzli.o:cuguetzli.cpp:(.text+0x38a3): undefined reference to `cuMemcpyDtoD_v2'
clguetzli\cuguetzli.o:cuguetzli.cpp:(.text+0x5bf4): undefined reference to `cuMemcpyDtoH_v2'
clguetzli\cumem_pool.o:cumem_pool.cpp:(.text+0x99): undefined reference to `cuMemFree_v2'
clguetzli\cumem_pool.o:cumem_pool.cpp:(.text+0x23d): undefined reference to `cuMemAlloc_v2'
clguetzli\cumem_pool.o:cumem_pool.cpp:(.text+0x29e): undefined reference to `cuMemsetD8Async'
clguetzli\ocu.o:ocu.cpp:(.text+0x18): undefined reference to `cuCtxDestroy_v2'
clguetzli\ocu.o:ocu.cpp:(.text+0x92): undefined reference to `cuCtxDestroy_v2'
clguetzli\ocu.o:ocu.cpp:(.text+0x443): undefined reference to `cuCtxCreate_v2'

Last edited by Jamaika; 26th May 2019 at 13:10.
Jamaika is offline   Reply With Quote
Old 24th May 2019, 11:01   #145  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Remake codecs google:
Code:
- new guetzli changed creators:
  https://github.com/maxime-killinger/guetzli
  https://github.com/ianhuang-777/guetzli-cuda-opencl
  I've combined the fixes, although google didn't accept the Additions of cuda 9.0 and opencl 2.0. {test}
  https://github.com/google/guetzli/pull/227
  additions:
  https://github.com/NVIDIA/cuda-samples
  https://github.com/KhronosGroup/OpenCL-ICD-Loader
  https://github.com/KhronosGroup/OpenCL-Headers
  https://github.com/ptillet/isaac
- new brunsli lossless
- new fixes for codec VVC 5.0
#define JVET_N0438_LOOP_FILTER_DISABLED_ACROSS_VIR_BOUND  1 // loop filter disabled across virtual boundaries
#define JVET_N0067_NAL_Unit_Header                        1 // NAL Unit Header 
#define JVET_N0349_DPS                                    1 // Decoding Parameter Set
#define JVET_N0857_TILES_BRICKS                           1 // VTM-5 basic Slices/Tiles/Bricks design, rectangular slices not supported yet
#define JVET_N0150_ONE_CTU_DELAY_WPP                      1 // one CTU delay WPP
#define EMULATION_PREVENTION_FIX                          1 // fix for start code emulation reported in #270. Diverges from specification text
delete #define HEVC_DEPENDENT_SLICES                             1
https://www.sendspace.com/filegroup/...XoPbXwxyBjQXcw

Last edited by Jamaika; 26th May 2019 at 13:08.
Jamaika is offline   Reply With Quote
Old 28th May 2019, 21:54   #146  |  Link
p0w3rh0u5e
Registered User
 
Join Date: Feb 2008
Posts: 21
Thank you very much.

I think we are getting closer. ;-)

OpenCL Test1 returns a lot of these errors now "Error: clScaleImageEx:526 returned CL_INVALID_KERNEL.", it's not just limited to clScaleImageEx. / no output file
OpenCL Test2 returns the same two lines as your first version "Number of available platforms: 1
DeviceName: ICD_LOADER_TEST_OPENCL_STUB
SelectDevice: ICD_LOADER_TEST_OPENCL_STUB GPU=1" seems to do something, but still no output file is created

Cuda_OpenCL Version with --cuda returns a lot of these "Error: cuScaleImageEx:602 returned CUDA_ERROR_INVALID_HANDLE" (again, not just for cuScaleImageEx) when called with CUDA / no output file.
Cuda_OpenCL Version with --opencl returns a lot of these "Error: cuScaleImageEx:602 returned CUDA_ERROR_NOT_INITIALIZED.
Error: cuScaleImageEx:604 returned CUDA_ERROR_INVALID_HANDLE.
Error: cuComputeBlockZeroingOrder:143 returned CUDA_ERROR_NOT_INITIALIZED.
Error: cuComputeBlockZeroingOrder:146 returned CUDA_ERROR_INVALID_HANDLE." / but actually creates an output-file, sadly only with grey pixels. ;-)

I can send you complete logs if you need, but it's just a chain of almost the same errors.

Last edited by p0w3rh0u5e; 28th May 2019 at 21:56.
p0w3rh0u5e is offline   Reply With Quote
Old 30th May 2019, 16:15   #147  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
I have no idea for mistakes. I think GCC is still underdeveloped.
Only Visual Studio 2019 remains.
Jamaika is offline   Reply With Quote
Old 30th May 2019, 16:25   #148  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Code:
Library enc/dec:
libJPEGLS   2.0.1+     [20 Jun 2019] ooapi test 8/16bit C⁺⁺14
lodepng                [15 Jun 2019] don't use libpng 
libWebP     1.0.2+     [15 Jun 2019] don't use images 16bit PPM

libx265     3.1_RC2+2  [18 Jun 2019] 8+10+12bit
jvetvvc     5.0+       [21 Jun 2019] 8+10+12bit {disable TRACING}
libde265    2.0.0      [null 2019]
libheif HDR 1.0.0+     [18 Jun 2019] only 8bit
libsvt      1.3.0+     [20 Jun 2019] 8+10+12bit {import y4m}
libbpg      0.9.8                    add new function svt_hevc & jctvc

GCC 9.1.1 2019.05.30 /ftree-vectorize /g0 /O3 /fPIC don't use /flto
JPEG XT only /ggdb3 /flto /fPIC

New function VVC 5.0+:
#define JVET_N0276_CONSTRAINT_FLAGS 1 // JVET-N0276: On interoperability point signalling
#define JVET_N0278_HLS 1 // JVET-N0278: HLS for MPEG requirements on immersive media delivery and access
#define JVET_N0805_APS_LMCS 1 // JVET-N0805: Reference to APS from slice header for LMCS
#define JVET_N0070_WRAPAROUND 1 // reference wraparound simplifications
#define JVET_N0063_VUI 1 // JVET-N0063: Video Usability Information
#define JVET_N0847_SCALING_LISTS 1 //1: default mode, 2: user defined mode
#define JVET_N0438_LOOP_FILTER_DISABLED_ACROSS_VIR_BOUND 1 // loop filter disabled across virtual boundaries
#define JVET_N0067_NAL_Unit_Header 1 // NAL Unit Header
#define JVET_N0349_DPS 1 // Decoding Parameter Set
#define JVET_N0857_TILES_BRICKS 1 // VTM-5 basic Slices/Tiles/Bricks design, rectangular slices not supported yet
#define JVET_N0857_RECT_SLICES 1 // Support for rectangular slices and raster-scan slices (i.e., multiple tiles/brick in a slice)
#define JVET_N0150_ONE_CTU_DELAY_WPP 1 // one CTU delay WPP
#define EMULATION_PREVENTION_FIX 1 // fix for start code emulation reported in #270. Diverges from specification text

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

PS In truth, the topic has stopped dealing with JPEG images. There are only free to develop ideas HEVC / AV1.

Last edited by Jamaika; 21st June 2019 at 11:07.
Jamaika is offline   Reply With Quote
Old 28th June 2019, 09:19   #149  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
FUIF: Free Universal Image Format

WARNING: This is a research prototype. The bitstream is not finalized. Images encoded with the current version of FUIF may not (and probably will not) decode with future versions of FUIF. Use at your own risk!

FUIF is a new image format, combining ideas from JPEG, lossless WebP, and FLIF. It is a 'universal' image format in several senses:
1.it works well for any kind of image (photographic and non-photographic)
2.it can do both lossless and lossy (with the same underlying algorithm)
3.it is Responsive By Design: one file can be used, instead of needing separate images for the low-quality image placeholder, thumbnail, preview, dpr 1, dpr 2, etc
4.it is backwards compatible with JPEG, in the sense that existing JPEG images can be transcoded to FUIF losslessly (no generation loss) and effectively (smaller files)
5.it can achieve various trade-offs between encode/decode complexity and compression density

In more detail:

1. Any kind of image

FUIF supports several methods for image preprocessing and entropy coding, so it can use the methods that work best for a particular image (or a particular part of an image).

For non-photographic images with few colors, a palette (color index) can be used. There is no limit on the palette size.

For images with repetition (e.g. images that include text, where the same letter shapes appear in multiple locations), an optional transformation can be used to replace repetition with references (somewhat similar to JBIG2).

For photographic images, the DCT transformation can be used.

For raw sensor data, the format supports an arbitrary number of channels, that do not need to have the same dimensions, and that do not need to have the same value ranges either. The actual ranges can be used effectively (not just 8-bit or 16-bit like in PNG, but also things like 14-bit with a black level and white level range of 1023..15600).

FUIF supports bit depths up to 28-bit per channel, unsigned or signed. Only integer values are supported (no floating point), but in principle, floating point numbers can be represented as integers plus a suitable transfer function.

2. Lossless and lossy

FUIF uses reversible transforms (YCoCg, reversible Haar-like squeezing); optional quantization is the only source of loss.

Unlike FLIF, FUIF was designed with lossy compression in mind. Unlike JPEG, FUIF can obtain fully lossless compression. Unlike WebP and JPEG 2000, FUIF uses the same algorithm for both lossy and lossless.

FUIF attempts to offer state-of-the-art compression for both lossy and lossless compression.

3. Responsive By Design

The FUIF bitstream is designed in such a way that truncating a file results in a lower resolution downscaled image. It is similar to progressive JPEG or JPEG 2000 in this respect. Image formats (like WebP, HEIC/BPG, AVIF) that are derived from a video codec (VP8, HEVC, AV1) intra-frame encoding, do not support progressive decoding, since in a video codec it does not make much sense to decode a single frame progressively.

FUIF was designed specifically with web delivery in mind. Instead of having to produce, store and deliver many variants of an image, scaled to various dimensions, the idea is to use a single file and truncate it depending on the dimensions it gets rendered on. This approach has several advantages:
•Less storage needed (no redundancy)
•Better for CDNs (cache hit is more likely)
•Less bandwidth needed (e.g. if you are currently sending a LQIP, then a thumbnail, then when it gets clicked a larger image)
•Smart browsers could make choices themselves, e.g. load lower resolution when on a slow or expensive connection; when the local browser cache gets too full, instead of deleting whole files, it could trim off bytes at the end, keeping a preview in cache

The header of a FUIF file contains a mandatory list of truncation offsets, which makes it easy to know how many bytes should be requested or served. The following offsets are included in the header:
•LQIP: the first very low-quality preview of an image (typically at 100-200 bytes)
•scale 1/16
•scale 1/8
•scale 1/4
•scale 1/2

These power-of-two downscales are exact, in the sense that if you truncate the file at the given offset, the resulting image is the same as decoding the whole full-resolution image and then downscaling it. This cannot really be done in an efficient way with progressive JPEG.

FUIF has a minimalistic, compact header layout, so the first bits of actual image data appear as early as possible. This makes it possible to get a LQIP within a small byte budget, while it is still the beginning of the actual full image, so you also get the actual image dimensions, truncation offsets etc.

4. Backwards compatible with JPEG

There are a LOT of existing JPEG images out there, as well as devices that produce new JPEG images. If the only way to transcode a JPEG image to a new image format, is to decode the JPEG to pixels and encode that to the new format, then there is a problem. Either you get significant generation loss, or you get new files that are actually larger than the original.

FUIF supports the 8x8 DCT transform (which is inherently lossy due to rounding errors) and the YCbCr color transform (which is also inherently lossy for the same reason). This means it can losslessly represent the actual information in a JPEG image, while still adding most of the benefits of FUIF:
•LQIP and scale 1/16 (progressive JPEG starts at scale 1/8)
•Minimal header overhead
•Better compression

Comparing FUIF to Dropbox's Lepton, which also does lossless JPEG recompression:
•Lepton can obtain slightly better compression density
•Lepton is faster
•Lepton is bit-exact (not just image-exact)
•FUIF can be decoded progressively (Lepton is anti-progressive since it encodes the AC before the DC)
•FUIF can do more than just what JPEG can, for example you can add an alpha channel to an existing JPEG

https://github.com/cloudinary/fuif
Jamaika is offline   Reply With Quote
Old 12th July 2019, 08:21   #150  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Code:
Library enc/dec:
libJPEGLS   2.0.1+     [08 Jul 2019] ooapi test 8/16bit C⁺⁺14
lodepng                [03 Jul 2019] don't use libpng 
libWebP     1.0.2+     [03 Jul 2019] don't use images 16bit PPM

libx265     3.1+7      [08 Jul 2019] 8+10+12bit
jvetvvc     5.0+       [10 Jul 2019] 8+10+12bit {disable TRACING, SIMD} {no import y4m}
libde265    2.0.0
libheif HDR 1.0.0+     [04 Jul 2019] only 8bit
libsvt      1.3.0+     [10 Jul 2019] 8+10+12bit {import y4m}
libbpg      0.9.8                    add new function svt_hevc & jctvc

libTIFF     4.0.10+    [09 Jul 2019]
libRAW       0.19.3+   [10 Jul 2019] master
libJPEG_turbo 2.0.3+   [11 Jul 2019](can use mozJPEG or libjpeg 9.3, don't use jpegXT)
libexpat    2.2.7+     [10 Jul 2019]
GCC 9.1.1 2019.06.27 /ftree-vectorize /g0 /O3 /fPIC don't use /flto
JPEG XT only /ggdb3 /flto /fPIC

New function VVC 5.0+:
#define JVET_N0047_Merge_IDR_Non_IDR 1 // merging IDR and non-IDR pictures
#define JVET_N0276_CONSTRAINT_FLAGS 1 // JVET-N0276: On interoperability point signalling
#define JVET_N0278_HLS 1 // JVET-N0278: HLS for MPEG requirements on immersive media delivery and access
#define JVET_N0805_APS_LMCS 1 // JVET-N0805: Reference to APS from slice header for LMCS
#define JVET_N0070_WRAPAROUND 1 // reference wraparound simplifications
#define JVET_N0063_VUI 1 // JVET-N0063: Video Usability Information
#define JVET_N0847_SCALING_LISTS 1 //1: default mode, 2: user defined mode
#define JVET_N0438_LOOP_FILTER_DISABLED_ACROSS_VIR_BOUND 1 // loop filter disabled across virtual boundaries
#define JVET_N0067_NAL_Unit_Header 1 // NAL Unit Header
#define JVET_N0349_DPS 1 // Decoding Parameter Set
#define JVET_N0857_TILES_BRICKS 1 // VTM-5 basic Slices/Tiles/Bricks design, rectangular slices not supported yet
#define JVET_N0857_RECT_SLICES 1 // Support for rectangular slices and raster-scan slices (i.e., multiple tiles/brick in a slice)
#define JVET_N0150_ONE_CTU_DELAY_WPP 1 // one CTU delay WPP
#define JVET_M0128 1 // Implementation of RPL as in JVET-M0128
#define EMULATION_PREVENTION_FIX 1 // fix for start code emulation reported in #270. Diverges from specification text

https://www.sendspace.com/file/5r880k

JPEG XT will not be updated.
To BPG X265 3.1+7 added:
p->rc.aqMode = 3;
p->rc.aqStrength = 1.0;
p->deblockingFilterTCOffset = -1;
p->deblockingFilterBetaOffset = 1;
p->psyRd = 2.0;

Last edited by Jamaika; 12th July 2019 at 11:12.
Jamaika is offline   Reply With Quote
Old 29th July 2019, 16:19   #151  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Code:
Library encoder:  NEW libRAW    0.19.3       [27 Jul 2019]
                  libJPEG-turbo 2.0.3  8bit  [18 Jul 2019]
                  libjasper     2.0.16       [12 Mar 2019]
                  zlib          1.2.11.1     [13 Apr 2019]
                  libLCMS       2.10alpha    [26 Jul 2019]
                  DNG SDK       1.5.0        [15 May 2019]
                  XMP exempi    5.7.0        [05 Jan 2019]
                  libexpat      2.2.7        [28 Jul 2019]
                  Compiled by Jamaika
https://github.com/LibRaw/LibRaw/issues/233

Last edited by Jamaika; 31st July 2019 at 08:48.
Jamaika is offline   Reply With Quote
Old 12th August 2019, 07:46   #152  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 917
JPEG XL reaches Committee Draft
The 84th JPEG meeting was held in Brussels, Belgium. Significant progress occurred in most of the projects, namely on the new image coding system, JPEG XL, and the standard for new imaging technologies, JPEG Pleno. In particular, JPEG XL has issued the Committee Draft, which demonstrates the progress of the JPEG XL standard as an effective solution for the future of image coding. JPEG Pleno Part 1 (Framework) and Part 2 (Light field coding) have also reached Draft International Standard status.

Moreover, exploration studies are ongoing in the domain of media blockchain and on the application of learning solutions for image coding. Both have triggered a number of activities providing new knowledge and opening new possibilities on the future use of these technologies in future JPEG standards.

In the following, a short description of the most significant activities is presented.

JPEG XL
The JPEG XL Image Coding System (ISO/IEC 18181) has completed the Committee Draft of the standard. The new coding technique allows storage of high-quality images at one-third the size of the legacy JPEG format. Moreover, JPEG XL can losslessly transcode existing JPEG images to about 80% of their original size simplifying interoperability and accelerating wider deployment.

The JPEG XL reference software, ready for mobile and desktop deployments, will be available in Q4 2019. The current contributors have committed to releasing it publicly under a royalty-free and open source license.

source: https://jpeg.org/items/20190803_press.html
hajj_3 is offline   Reply With Quote
Old 22nd August 2019, 08:14   #153  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Free codecs at the end of the holiday. Some work better, worse. Some are common, others just trash of the internet.
Code:
Library enc/dec:
libJPEGLS   2.0.1+     [17 Aug 2019] ooapi test 8/16bit C⁺⁺14
lodepng                [15 Aug 2019] don't use libpng 
libWebP     1.0.3+     [30 Jul 2019] don't use images 16bit PPM

libx265     3.1.2+1    [31 Jul 2019] 8+10+12bit
jvetvvc     6.0+       [22 Aug 2019] 8+10+12bit {disable TRACING, SIMD} HDRTools {no import y4m}
libde265    2.0.0
libheif HDR 1.5.0+     [16 Aug 2019] only 8bit
libsvt      1.3.0+     [22 Aug 2019] 8+10+12bit {error import y4m}
libbpg      0.9.8                    add new function svt_hevc & jctvc

libTIFF     4.0.10+    [21 Aug 2019]
libRAW       0.19.3+   [13 Aug 2019] master
libJPEG_turbo 2.0.3+   [11 Jul 2019](can use mozJPEG or libjpeg 9.3, don't use jpegXT)
libexpat    2.2.7+     [21 Aug 2019]
Fix mingw-std-threads for all codecs.
Unfortunately google PIK didn't appear in August, despite announcements.
Dropbox Lepton doesn't work anyway, despite a successful build.

JpegXT update, surprise. He will probably change the website because he is new sponsor Fraunhofer IIS.
Release 1.54:

In this release, upsampling has been made conforming to the latest
corrigendum of 18477-1 and 18477-8. In particular, upsampling is now
by design always centered and never co-sited. The co-sited upsampling
procedure is still included in the source code, but never executed.

--------------------------------------------------------------------------

Release 1.55:

This release only addresses some minor formulation issues of the
command line such that references are formatted properly to make this
software package acceptable as a JPEG reference software.
No functional changes.

--------------------------------------------------------------------------

Release 1.56:

Encoding and reconstruction of 2-component images was actually never
supported, as it was considered a rather exotic use-case. Now that a
request was made, support for 2-components was added and should
hopefully work ok.

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

PS Interesting facts. A new JCTVC HEVC library has appeared, which is being built anew. I don't know what is this test creation?
https://vcgit.hhi.fraunhofer.de/jct-vc/HM

Last edited by Jamaika; 22nd August 2019 at 08:31.
Jamaika is offline   Reply With Quote
Old 28th September 2019, 11:05   #154  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Code:
Library enc/dec:
libJPEGLS   2.0.1+     [24 Oct 2019] ooapi test 8/16bit C⁺⁺14
lodepng                [22 Oct 2019] don't use libpng 
libWebP     1.0.3+     [05 Oct 2019] don't use images 16bit PPM

libx265     3.2+3      [25 Oct 2019] 8+10+12bit
jvetvvc     6.1+       [27 Oct 2019] 8+10+12bit {disable TRACING, SIMD} {no import y4m}
HDRTools    0.19.1+    [27 Oct 2019]
libde265    2.0.0
libheif HDR 1.5.1+     [23 Oct 2019] only 8bit
libsvt      1.4.1+     [27 Oct 2019] 8+10+12bit {error import y4m}?
libbpg      0.9.8                    add new function svt_hevc & jctvc

libTIFF     4.0.10+    [17 Oct 2019]
libRAW      0.19.5+    [13 Aug 2019] master
libJPEG_turbo 2.0.3+   [11 Jul 2019](can use mozJPEG or libjpeg 9.3, don't use jpegXT)
libexpat    2.2.7+     [25 Oct 2019]
liblcms2    2.0.10+    [27 Oct 2019]
freeGLUT    3.2.1+     [27 Oct 2019]
https://www.sendspace.com/file/0kc1wn

Last edited by Jamaika; 29th September 2019 at 05:20.
Jamaika is offline   Reply With Quote
Old 29th September 2019, 05:26   #155  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Complete reconstruction of the HM HEVC library
https://vcgit.hhi.fraunhofer.de/jct-...commits/master
compile fix for clang & gcc 8.3

New BPG image with new codecs X265 / SVT HEVC / HM HEVC
https://www.sendspace.com/file/5yl2i7

Last edited by Jamaika; 29th September 2019 at 06:08.
Jamaika is offline   Reply With Quote
Old 6th October 2019, 23:09   #156  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Reheating old cutlets.
I added my amateur corrections to projects. Maybe they will interest someone.
https://github.com/Jamaika1/libbpg-2019
Jamaika is offline   Reply With Quote
Old 9th October 2019, 17:48   #157  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Improved libRAW with parallelism v19.5
https://www.sendspace.com/file/nxr2ib
libHEIF will not be associated with JPEG, MJPEG, CineForm and old AVC codecs. It will also have nothing to do with Intel Media SDK codecs based on MXF or failed libmox project.
https://www.sendspace.com/filegroup/...DbKpWqr6MLbpnQ
libBPG project with new x265 3.2+5

What about the pictures for the VVC codec? If not accepted in the world of video, it will only remain spam on the forums.
Jamaika is offline   Reply With Quote
Old 14th November 2019, 11:40   #158  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 917
JpegXL update: https://www.spiedigitallibrary.org/c...237.full?SSO=1
hajj_3 is offline   Reply With Quote
Old 15th November 2019, 21:43   #159  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Thanks for the info, we are waiting for the codec to be implemented.
Jamaika is offline   Reply With Quote
Old 17th November 2019, 08:17   #160  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 650
Code:
Library enc/dec:
libJPEGLS   2.0.1+     [15 Nov 2019] ooapi test 8/16bit C⁺⁺14
brunsli                [31 Oct 2019] transport layer in the Committee Draft of JPEG XL
lodepng                [14 Nov 2019] don't use libpng 
libWebP     1.0.3+     [06 Nov 2019] don't use images 16bit PPM

libx265     3.2+15     [XX Nov 2019] 8+10+12bit
jvetvvc     7.0+       [15 Nov 2019] 8+10+12bit {disable TRACING, SIMD} {no import y4m}
HDRTools    0.19.1+    [27 Oct 2019]
libde265    2.0.0
libheif HDR 1.6.0+     [08 Nov 2019] only 8bit
libsvt      1.4.1+     [16 Nov 2019] 8+10+12bit {error import y4m}?
libbpg      0.9.8                    add new function svt_hevc & jctvc

libTIFF     4.1.0+     [15 Nov 2019]
libRAW      0.19.5+    [11 Nov 2019] master
libJPEG_turbo 2.0.4+   [15 Nov 2019](can use mozJPEG or libjpeg 9.3, don't use jpegXT)
libexpat    2.2.9+     [04 Nov 2019]
liblcms2    2.0.10+    [27 Oct 2019]
freeGLUT    3.2.1+     [27 Oct 2019]
https://www.sendspace.com/file/yq1wcp

Last edited by Jamaika; 17th November 2019 at 20:12.
Jamaika 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 10:42.


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