Overview

You can compete in one or more tracks. There are four challenge tracks in total:

Each track has a validation phase and a test phase. Submissions will be ranked on the leaderboard during the validation phase. The winners will be determined during the test phase. To qualify, you must:

  • submit at least one decoder during the validation phase,
  • submit compressed files during the test phase, matching a previously submitted decoder, and
  • submit an accompanying whitepaper through OpenReview.

Deadlines for these steps are given on the dates page.

Validation phase

To submit to our competition, please use the submit page. As a team, please make sure that you don't create duplicate accounts, as it complicates matching method and paper submissions. Separately submitting small variations of the same method by the same or overlapping teams is not allowed, and such submissions will be identified and removed. Typically, this means there will be a maximum of one account per organization, and one submission per organization and track.

The submissions run in a Docker container you select by either running your executable or by first unzipping your zip file and running ./decode. At this point, your decoder should be able to decode the images or videos, including unzipping them, into a local subfolder (we recommend images/ or videos/ for easier debugging). Note: It is important that you submit a working decoder in this phase or you will not be eligible in the test phase.

Test phase

Once the test phase begins, the test data will be released. You must encode this test data, and submit a previous decoder and compressed data that represents the entirety of the compressed dataset. You must upload a decoder binary or zip file, as you did in the validation phase, but if they are not hashed to the same value, your decoder will be rejected.

By submitting to the test phase, you give consent for us to publish the reconstructions from your method under the respective licensing terms of the original source image or video.

Note: To encourage development of learned codecs with low computational complexity, the 25% of test phase submissions with the highest decoding time in each track will not be considered eligible for a prize.

Paper submission

Technical novelty is not a requirement for the whitepapers. However, they will undergo a lightweight review process. They must include a self-contained description of the method, detailed enough to reproduce the results. Accepted papers will be linked on the papers page.

Independently of the mandatory whitepaper, challenge participants are specifically encouraged to submit papers about their method to the PCS submission site (CMT). Note that the PCS submission deadline is distinct from the whitepaper deadline. These papers will undergo the regular PCS submission process, and are otherwise also treated exactly the same as a regular conference paper. Accepted conference papers will be published on IEEE Xplore.

Image compression
Task

The goal is to compress a corpus of images to three bitrates:

  • 0.3 bpp*
  • 0.15 bpp*
  • 0.075 bpp*

The winners will be chosen based on a human rating task. The raters compare pairs of submitted image reconstructions to each other, using the uncompressed image as a reference, and chose which of the two is preferable.

Validation set

The validation set is the same as the test set from CLIC 2024 and consists of 29 images collected from Unsplash, two images with game content, and one image with screen content; all provided in PNG format. The test set for this year will be similar in terms of resolutions, content, and number of images.

The images are released using the Unsplash license. Please contact the organizers if you have objections to any of the released pictures.

Test set

The test set will be provided at the beginning of the test phase.

Submission guidelines
  • The submitted decoder size should not exceed 4GB.
  • To be eligible for a prize in a given track, you must submit to all the bit rates of that track. You are not limited to using the same decoder for all the rate points (but each decoder must have already been submitted in the validation phase).
  • Each submission is provided 2 CPUs and 12 GB RAM. In the GPU track, submissions can additionally use a L4 GPU with 24 GB memory.
  • There is a time limit of 5 hours for each submission. Note that to encourage development of low-complexity methods, the 25% slowest submissions will not be considered for a prize. This is independent of the time limit.
Example submission

The devkit (available soon) contains an example submission. It showcases the format expected by the server.

Video compression
Task

The goal is to compress a corpus of videos to the target bitrate for each sequence. Target bitrates are provided in a table along with the resolution, bit depth, and frame rate of each sequence.

The winners will be chosen based on a human rating task. The evaluation methodology is described in this paper.

Validation set

The validation set consists of 30 video sequences in the YUV 4:2:0 8 bit (yuv420p) format. The .yuv files are binary files containing 8-bit videos, without any header. The file name indicates resolution and frame rate of each sequence. (In Python, the yuvio library can be used to read and write raw video files.)

  • The validation set will be provided shortly.

Please contact the organizers if you have objections to any of the released videos.

Test set

The test set will be provided at the beginning of the test phase.

Submission guidelines
  • The submitted decoder size should not exceed 4GB.
  • The decoder must reconstruct the videos in the same format as the provided sequences, named {input_filename}_dec.yuv.
  • Each submission is provided 2 CPUs and 12 GB RAM. In the GPU track, submissions can additionally use a L4 GPU with 24 GB memory.
  • There is a time limit of 5 hours for each submission. Note that to encourage development of low-complexity methods, the 25% slowest submissions will not be considered for a prize. This is independent of the time limit.
  • The decoder must be able to decode any subset of the compressed videos. Not all provided sequences may be considered for the final evaluation. The submission process will check for this.
Example submission

The devkit (available soon) provides an example submission using H.265. It also shows how to load raw video frames in Python.

* bpp: bits per pixel. One pixel consists of three color components.
* mbps: megabits per second. 0.05 mbps = 50 000 bits per second.

Sponsored by