I don't really get your argument, to be honest.
Quote:
Originally Posted by DanilaZabiaka
I made comparison in this thread about video compression
|
Ok...
Quote:
Originally Posted by DanilaZabiaka
Shortly, video compression brokes details.
|
A lossy compression
breaks details, ok, fair enough...
Quote:
Originally Posted by DanilaZabiaka
In real world surfaces are not from regular colors.
|
What do you mean? Light coming from a source goes through a Bayer filter which is the de-facto standard way of arranging color filters on a square grid of photosensors. Do you have a better idea?
Quote:
Originally Posted by DanilaZabiaka
There is 'original' png lossless Mario 194KB
|
Why are you using a synthetic picture made in Computer Graphic as an example? Didn't you just say "real world surfaces"? O_o
Quote:
Originally Posted by DanilaZabiaka
Gif uses dithering and with small size 63kb it looks more natural
|
Uh? I mean, leaving aside the fact that when you go from a certain bit depth to a lower bit depth you should always use some kind of dithering algorithm to avoid having a terribly bad banding, in the case of gif the problem is that it's a palette-based codec, so the colors used in an image have their RGB values defined in a palette table that can hold up to 256 entries, so if you don't use dithering of some sort, your image will probably look like crap.
Still, there have been way better codecs than gif for ages, from the evergreen JPEG with a reasonably high quantizer, to JPEG2000 which uses the Wavelet Transform and deals with the whole picture together to avoid blocks/macroblocks during the compression, to more recent codecs like HEIF (H.265 for images). Keep in mind that gif was born in 1987, what do you expect?
Quote:
Originally Posted by DanilaZabiaka
If you apply noise shader to original png size now is 653kb
|
So...? It's normal as .png is a lossless compression codec, so it has hard time compressing the image if you introduce noise which has no correlation, especially in the dark areas where you had a solid black with a lot of correlation between pixels before and no correlation now, that's why it's bigger than before.
I don't see the problem.
Quote:
Originally Posted by DanilaZabiaka
I also edit color levels - imho its very important, because 0-255 color range is too big and its not realistic
|
What? Why? Why did you touch levels? 0-255 bit too big? That's clearly a joke, right? That's 8bit Full Range (PC Range). It's kinda considered the very bare minimum these days as we're kinda used to get 10bit footages as 8bit footages are prone to have banding.
Quote:
Originally Posted by DanilaZabiaka
What about VIDEO compression?
|
What about it?
Quote:
Originally Posted by DanilaZabiaka
I converted noisy image png->mp4 and get that result
|
png is a codec, .mp4 is a container.
What's inside that container? Perhaps you mean H.264?
Quote:
Originally Posted by DanilaZabiaka
In png its 339KB, im mp4 its 11kb, but it has not noise
|
Uh... 'cause it has been averaged as you didn't have enough bitrate? Besides, luma and chroma are wrong in your (I supposed H.264) encoded image, so there was clearly a wrong flag set during the encode or a wrong level conversion.
Quote:
Originally Posted by DanilaZabiaka
You can restore this with shader also
|
Why would you want to do that? Why not spending enough bits on the encode to retain grain in the first place?
Quote:
Originally Posted by DanilaZabiaka
So, if it will be normal practice for players and will be included in GUI you can control noise level, black/white level, etc
It help cartoons to look more 'natural' like in analog time
|
Oh I see, you just want some dynamic grain added to your cartoons and you don't understand why they don't do it, right? Well, the answer is because it pretty much fucks up motion-compensation as the codec doesn't find any correlation between adjacent pixels in the same frame and it doesn't understand that a pixel is "moving" when it analyses the next frames, therefore it tends to put more Intra frame than needed and uses more bits than needed. You may however find a bit of static grain added to some cartoons to cover up things and give depth to surfaces, but that's STATIC grain.
If you like grain so much, you can add it yourself in real time while watching your favorite show. PotPlayer and Avisynth come into help as you can use a custom avisynth script like so:
Code:
LoadPlugin("C:\Encoding\plugins\AddGrainC.dll")
Import("C:\Encoding\plugins\addgrain.avs")
potplayer_source()
AddGrainC(var=5.0, uvar=0.0, constant=true)
You can increase "var" to increase the grain and you can set "constant" to "false" to make it dynamic grain.
Quote:
Originally Posted by DanilaZabiaka
I dont get why technogeeks fuck with renders, hdr, etc
Why you just cant reduce levels NOT 'BRIGHTNESS' - its just color offset, which destroys color. Digitally, intensivity of pixels is 0-255
'brighntess' algorithm works like. If you wanna make picture darker in dark room, for example -30, 255->225, but for example 20 turns to zero
Or if you increase brighntess + 30, you move black point to 30, but also 230 will be 255. Its just wtf, it does not have any sense
It looks normal if you increase black point in bright room and decrease in dark room, but players dont provide this out of box. MPC has 'levels' shader, but its broken, and it could be in GUI like sliders to control this for your taste
|
Nonsense... If you're watching TV, there's a fairly good chance that someone like me or other people spent HOURS grading something the way it is to make it look in a certain way, according to the producer and the art director using the tools we have available. 16-235 Limited TV Range 8bit for the old SDR contents, 64-940 Limited TV Range for the new 10bit footages, leaving aside HDR which uses special color curves and it's far more complicated than "adjusting levels".
As I said, you should NOT change levels, but still if you really want to you can do it in PotPlayer with a GUI since it seems you like GUIs...
I won't reply any further...
Good evening...