Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts and ideas about the growing size of (image) data #49

Open
munix9 opened this issue Oct 7, 2021 · 8 comments
Open

Thoughts and ideas about the growing size of (image) data #49

munix9 opened this issue Oct 7, 2021 · 8 comments

Comments

@munix9
Copy link
Contributor

munix9 commented Oct 7, 2021

I'm thinking about the growing size of the (image) data.
Has any thought been given to possibly trying a more efficient image format?
I'm currently playing around a bit with AVIF and the compression and quality are astounding.
Example:
textures/hires/earth.png ~ 11M
After conversion using avifenc earth.png earth.avif
earth.avif ~ 1,7M

See also:
https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVIF)
https://github.com/AOMediaCodec/libavif/tree/master/examples

@levinli303
Copy link
Collaborator

yeah I think we could add support for avif like how we did for jpeg and png

@375gnu
Copy link
Collaborator

375gnu commented Oct 8, 2021

Probably DDS is a better solution as it's hardware supported, so no need to unpack them in video memory.

@munix9
Copy link
Contributor Author

munix9 commented Oct 9, 2021

I would still not disregard AVIF.
DDS is currently already usable in Celestia, isn't it?

Short test:
avifenc 0.9.2 (dav1d [dec]:0.9.2, aom [enc/dec]:v3.1.2, rav1e [enc]:0.4.1 (0.4.1))
ImageMagick 7.1.0-8 Q16-HDRI x86_64

$ avifenc earth.png earth_1.avif
$ convert -define dds:compression=dxt1 earth.png earth_dxt1.dds
$ convert -define dds:compression=dxt5 earth.png earth_dxt5.dds

$ du -h earth*
1.7M earth.avif
5,4M earth_dxt1.dds
11M  earth_dxt5.dds
11M  earth.png

@levinli303
Copy link
Collaborator

a rough implementation of loading avif textures. the APIs in libavif are simple enough only CelestiaProject/Celestia#1129

@munix9
Copy link
Contributor Author

munix9 commented Oct 9, 2021

I have created an AppImage (Linux) with the AVIF patch for testing.
The size has decreased significantly, the speed and quality still needs to be checked.
avifenc allows to adjust the output by means of parameters (see below).

With AVIF (~135M )
https://download.opensuse.org/repositories/home:/munix9:/test/AppImage/
https://download.opensuse.org/repositories/home:/munix9:/test/AppImage/celestia-1.7.0~git20211007+cfc77c67d-lp152.476.1.Build476.2.glibc2.17-x86_64.AppImage

Without AVIF (~ 268M)
https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/
https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-1.7.0~git20211007+cfc77c67d-lp152.474.1.Build474.1.glibc2.17-x86_64.AppImage

JPGs and PNGs have been converted under extras-standard and textures.
The corresponding *.ssc and iss.cmod have been adjusted - maybe I missed something somewhere, but it's just for testing.

The conversion itself takes place during the package build and can be examined in https://build.opensuse.org/package/view_file/home:munix9:test/celestia-data/celestia-data.spec?expand=1 starting with the line # avif test.

avifenc options
Syntax: avifenc [options] input.[jpg|jpeg|png|y4m] output.avif
Options:
    -h,--help                         : Show syntax help
    -V,--version                      : Show the version number
    -j,--jobs J                       : Number of jobs (worker threads, default: 1. Use "all" to use all available cores)
    -o,--output FILENAME              : Instead of using the last filename given as output, use this filename
    -l,--lossless                     : Set all defaults to encode losslessly, and emit warnings when settings/input don't allow for it
    -d,--depth D                      : Output depth [8,10,12]. (JPEG/PNG only; For y4m or stdin, depth is retained)
    -y,--yuv FORMAT                   : Output format [default=auto, 444, 422, 420, 400]. Ignored for y4m or stdin (y4m format is retained)
                                        For JPEG, auto honors the JPEG's internal format, if possible. For all other cases, auto defaults to 444
    -p,--premultiply                  : Premultiply color by the alpha channel and signal this in the AVIF
    --stdin                           : Read y4m frames from stdin instead of files; no input filenames allowed, must set before offering output filename
    --cicp,--nclx P/T/M               : Set CICP values (nclx colr box) (3 raw numbers, use -r to set range flag)
                                        P = color primaries
                                        T = transfer characteristics
                                        M = matrix coefficients
                                        (use 2 for any you wish to leave unspecified)
    -r,--range RANGE                  : YUV range [limited or l, full or f]. (JPEG/PNG only, default: full; For y4m or stdin, range is retained)
    --min Q                           : Set min quantizer for color (0-63, where 0 is lossless)
    --max Q                           : Set max quantizer for color (0-63, where 0 is lossless)
    --minalpha Q                      : Set min quantizer for alpha (0-63, where 0 is lossless)
    --maxalpha Q                      : Set max quantizer for alpha (0-63, where 0 is lossless)
    --tilerowslog2 R                  : Set log2 of number of tile rows (0-6, default: 0)
    --tilecolslog2 C                  : Set log2 of number of tile columns (0-6, default: 0)
    -g,--grid MxN                     : Encode a single-image grid AVIF with M cols & N rows. Either supply MxN identical W/H/D images, or a single
                                        image that can be evenly split into the MxN grid and follow AVIF grid image restrictions. The grid will adopt
                                        the color profile of the first image supplied.
    -s,--speed S                      : Encoder speed (0-10, slowest-fastest, 'default' or 'd' for codec internal defaults. default speed: 6)
    -c,--codec C                      : AV1 codec to use (choose from versions list below)
    --exif FILENAME                   : Provide an Exif metadata payload to be associated with the primary item
    --xmp FILENAME                    : Provide an XMP metadata payload to be associated with the primary item
    --icc FILENAME                    : Provide an ICC profile payload to be associated with the primary item
    -a,--advanced KEY[=VALUE]         : Pass an advanced, codec-specific key/value string pair directly to the codec. avifenc will warn on any not used by the codec.
    --duration D                      : Set all following frame durations (in timescales) to D; default 1. Can be set multiple times (before supplying each filename)
    --timescale,--fps V               : Set the timescale to V. If all frames are 1 timescale in length, this is equivalent to frames per second (Default: 30)
                                        If neither duration nor timescale are set, avifenc will attempt to use the framerate stored in a y4m header, if present.
    -k,--keyframe INTERVAL            : Set the forced keyframe interval (maximum frames between keyframes). Set to 0 to disable (default).
    --ignore-icc                      : If the input file contains an embedded ICC profile, ignore it (no-op if absent)
    --pasp H,V                        : Add pasp property (aspect ratio). H=horizontal spacing, V=vertical spacing
    --crop CROPX,CROPY,CROPW,CROPH    : Add clap property (clean aperture), but calculated from a crop rectangle
    --clap WN,WD,HN,HD,HON,HOD,VON,VOD: Add clap property (clean aperture). Width, Height, HOffset, VOffset (in num/denom pairs)
    --irot ANGLE                      : Add irot property (rotation). [0-3], makes (90 * ANGLE) degree rotation anti-clockwise
    --imir MODE                       : Add imir property (mirroring). 0=top-to-bottom, 1=left-to-right

aom-specific advanced options:
    1. <key>=<value> applies to both the color (YUV) planes and the alpha plane (if present).
    2. color:<key>=<value> or c:<key>=<value> applies only to the color (YUV) planes.
    3. alpha:<key>=<value> or a:<key>=<value> applies only to the alpha plane (if present).
       Since the alpha plane is encoded as a monochrome image, the options that refer to the chroma planes,
       such as enable-chroma-deltaq=B, should not be used with the alpha plane. In addition, the film grain
       options are unlikely to make sense for the alpha plane.

    When used with libaom 3.0.0 or later, any key-value pairs supported by the aom_codec_set_option() function
    can be used. When used with libaom 2.0.x or older, the following key-value pairs can be used:

    aq-mode=M                         : Adaptive quantization mode (0: off (default), 1: variance, 2: complexity, 3: cyclic refresh)
    cq-level=Q                        : Constant/Constrained Quality level (0-63, end-usage must be set to cq or q)
    enable-chroma-deltaq=B            : Enable delta quantization in chroma planes (0: disable (default), 1: enable)
    end-usage=MODE                    : Rate control mode (vbr, cbr, cq, or q)
    sharpness=S                       : Bias towards block sharpness in rate-distortion optimization of transform coefficients (0-7, default: 0)
    tune=METRIC                       : Tune the encoder for distortion metric (psnr or ssim, default: psnr)
    film-grain-test=TEST              : Film grain test vectors (0: none (default), 1: test-1  2: test-2, ... 16: test-16)
    film-grain-table=FILENAME         : Path to file containing film grain parameters

Version: 0.9.2 (dav1d [dec]:0.9.2, aom [enc/dec]:v3.1.2, rav1e [enc]:0.4.1 (0.4.1))
libyuv : available (1794)

@munix9
Copy link
Contributor Author

munix9 commented Oct 12, 2021

I will change the "official" unstable openSUSE packages and the AppImage to avif soon - maybe there will be some feedback from the users.

@munix9
Copy link
Contributor Author

munix9 commented Oct 13, 2021

That's done (for now).
I don't quite like the package dependencies yet, but it's not called "unstable" for nothing.

There are additional packages, for now only for openSUSE:
celestia-data-common-avif
celestia-data-common-dds

I will probably deactivate celestia-data-common-dds again, because it doesn't really save much space.

These now overwrite the original, unconverted images of the package celestia-data-common.

The AppImage uses the package celestia-data-common-avif, so some space and time is saved, also and especially for updates.

Maybe I can somehow manage to use github-actions to do the conversion and then you can download the finished packages as zip and/or xz packages, let's see.

@mattiaverga
Copy link

While looking at updating planet textures to a better resolution and with a clear and open source license, I've found this site where high resolution textures are available under CC-BY-4.0.
I've also discovered that Celestia now supports avif format, so I've tried to use some of the 8k textures there with good results. Also, using avif format with a quality set to 50 allows a size reduction while using far more detailed textures.
I'm not very good at graphic, so I just took the textures and converted them and put in celestia directory. I found them having much (too) vivid colors than the celestia originals and also I cannot get good results trying to use the Earth normal and clouds textures with avif format... maybe someone here can be interested in getting them in good shape, so that celestia can really get some "high resolution" textures.
Below some screenshot with the new textures (left: old textures - right:new textures):

earth

mercury

saturn

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants