doubt about x265 no-lossless compress

[rafacharkman]

in x265 has anyway to compress the videos just only removing the bits not being used in image?

I would also like to know if it is possible to do this kind of check(real bitrate of the image) and then compress the image by setting a minimum bitrate adjustable and the maximum bitrange being the real value of the bitrate image or less (no more than that)

My goal is to compress the video based only on the absolute value of the image(lossless) together with x265 quality-based rate control

[Asmodian]

x265 will never compress to a higher bitrate than "the real value of the bitrate image." It does not add extra filler bytes.

Simply use "--lossless", or what do you mean? :confused:

[rafacharkman]

x265 will never compress to a higher bitrate than "the real value of the bitrate image." It does not add extra filler bytes.

Simply use "--lossless", or what do you mean? :confused:

for example, I have a video to compress and the current bitrate is 42.000.000 bits but it's not the real bitrate of the image(i guess) which should be around 10.000.000 bits. '--lossless' leaves huge file size unnecessarily(more than 42.000.000) and '--cu-lossless' is very heavy in general.

I want(if it's possible) to use only the real bit value of each frame that exists in the image and discard the rest. if possible too, delimit that each frame have at least X bits.

[Cary Knoop]

You are confused, a decoded RGB frame consists of width*height*bit-depth*3 pixels.

[rafacharkman]

You are confused, a decoded RGB frame consists of width*height*bit-depth*3 pixels.

I guess kkk

Each image uses a certain amount of pixels which as you mentioned(width * height), but each image has a pixel table that you use to define which color will be used in each pixel. This table defines the actual bits of the image. When you reduce the table, it simplifies the image pixels, but when you add in table, doesn't change the image because the machine only uses pixels that it knows where to put it (unless an algorithm judges and puts it but not ideal)

Is it possible to find this value proportional to color table image and use it in compress without put more bits than the color table supports? this value in this case would be considered 'lossless compression'.

I say this because it is easy to detect in very large files, where you have a gradient in a scene but it is not clean, so I know the image contains more bits than the color table registers.(in this case, the table has been simplified and it's not a original and it's just allocating 'empty bits' in the file)

[Cary Knoop]

Each image uses a certain amount of pixels which as you mentioned(width * height), but each image has a pixel table that you use to define which color will be used in each pixel. This table defines the actual bits of the image. When you reduce the table, it simplifies the image pixels, but when you add in table, doesn't change the image because the machine only uses pixels that it knows where to put it (unless an algorithm judges and puts it but not ideal)

Is it possible to find this value proportional to color table image and use it to compress, without put more bits than the color table supports? this value in this case would be considered 'lossless compression'.

I say this because it is easy to detect in very large files, where you have a gradient in a scene but it is not clean, so I know the image contains more bits than the color table registers.(in this case, the table has been simplified and need less than proportional to the image)
I think you don't know what you are talking about.

[rafacharkman]

I think you don't know what you are talking about.

How does color distribution work in the image? if I understand that maybe I can understand where I'm missing

[MeteorRain]

You were looking for color palette compression. Yes you *can* do that to reduce the size, but why using such low-efficiency technology when we have much better entropy encoding?

Let's say your image is 40MiB. After color palette compression you make it 30MiB. While x265 along with motion estimation and entropy encoding can make it 15MiB. Why bother using the worse one?

Color palette is no more than a low-efficiency entropy encoding.

[benwaggoner]

You were looking for color palette compression. Yes you *can* do that to reduce the size, but why using such low-efficiency technology when we have much better entropy encoding?

Let's say your image is 40MiB. After color palette compression you make it 30MiB. While x265 along with motion estimation and entropy encoding can make it 15MiB. Why bother using the worse one?

Color palette is no more than a low-efficiency entropy encoding.
Ah, I remember the good old days of optimizing GIF, Smacker, and Apple Graphics codec content. I was able to get several hours of reversible LEGO assembly instructions videos on the very first Mindstorms CD-ROM through clever 3-bit palletization techniques automated through DeBabelizer.

Palletization can be a valuable technique for some very specific kinds of content, like screen recordings or Flash-style animation. But applying it in preprocessing before using HEVC or other modern codec will generally worsen results by adding shaper edges. Some of the Screen Content Coding Extensions to HEVC can make encoding palletized content more efficient, but I'm not sure how common those features are supported in real-world encoders and decoders.

[Asmodian]

How does color distribution work in the image? if I understand that maybe I can understand where I'm missing

It assigns every pixel a 24 or 30 bit color value, 8 or 10 bits per R, G, or B component. Actually it is usually 12 or 15 bits per pixel due to subsampled chroma. 8 or 10 bits per component for Y, Cb, and Cr but with Cb and Cr only having one value for every four pixels (half the resolution in both dimensions).

If you are still interested look into CABAC (https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding) which is the better arithmetic coding method used in both H.264 and H.265. Then start looking into quantization and residual coding. There is no 'color table' in modern high bit depth image/video formats and image and video compression has come a long way. The amount of compression already done by HEVC while in its 42Mbps form will shock you. :)