Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Not all compression algorithms are equal, and mostly the older formats are crappier than newer ones. I don't have data for images, but for example for sound you can actually sometimes get smaller files with lossless flac compression than with 320 kbps mp3. Similarly, in video compression x265 codec gives you approximately the same file size at 720p as the x264 would give at 480p.
WebP is one of my favorites - but its not widely supported, even tho its probably the most widely used format without people realizing it (Facebook photos are all WebP)
I mean no offense but I think you have no idea what you're doing here.
I explain: this plugin is not lossless at all, it converts a 24-bit picture into a 8-bit one (from 24 millions colors to 256). That's a massive loss of quality even with "bestest" algo (which it is not since default one in Irfanview is better).
For an original PNG of 500KB:
SuperPNG version is 200KB: wrong colors visible everywhere where there is high contrast.
JPG is 30KB: virtually identical to original for a still image, since it's a movie, 0 loss.
I never used After Effects, but it's either complete shit when it comes to encoding mp4 or you didn't select the correct options.
Syl what if he just stripped the alpha channel, ICC profile and metadata? What kind of space savings does that get you? I don't know enough to evaluate what "Smart Quantization" does, but it appears that it can save a lot of space without producing results as you describe. It looks like a histogram of the colors in the image are generated, and then re-indexed to the smallest bit register (8 bit for example) that can still express them as unique, saving you the space 24 bit -> 8 bit time Y pixels gets you.
Personally, I'm not worried if Pyke and his bro fully understand the CS concepts or not, more that they produce a good result in the end.
Your probably right - Im just an artist, and honestly most technical talk tends to whoosh over me.
I can show you some numbers of a raw frame I just finished rendering from MAX.
The truth is that when rendering an animation the individual frame compression and artifacts aren't 'that' important because motion hides a LOT of errors. Most of the post work I do is to 'degrade' the frame. Motion blur, DOF, particles, 2D camera shake. There is always a trade off between compression quality and size, with motion hiding many of bad things that come with higher compression.
Your probably right - Im just an artist, and honestly most technical talk tends to whoosh over me.
I can show you some numbers of a raw frame I just finished rendering from MAX.
The truth is that when rendering an animation the individual frame compression and artifacts aren't 'that' important because motion hides a LOT of errors. Most of the post work I do is to 'degrade' the frame. Motion blur, DOF, particles, 2D camera shake. There is always a trade off between compression quality and size, with motion hiding many of bad things that come with higher compression.
So the image above is the 2.5MB 24-bit PNG (2nd line). That tells us that there is ~8MB of metadata in the 1st file. What??? That's insane. The only explanation I can come up with is that Adobe stores all the layers there. I'm starting to understand why this plugin seems useful.
The JPG file is compressed with 100% quality. That's overkill. 80% is perfect value, no visible difference, huge size reduction. Result: 200KB.
As for the last PNG, the 256 colors version, Irfanview produced a 1MB file. There is also no visible difference but it's a trick as there isn't any high contrast part. That's still 5 times the size of the JPG above.
So what now? I don't know what your pipeline is, but I'm guessing you will make a mp4 with the individual frames. In that case, the only useful file is the STRIPPED PNG, you can ignore everything else. Final file size will be approx.: Number of frames * 200KB / 10 (30MB/mn, 2GB/h).
As for the SuperPNG plugin, just untick the Quantize box and never look back. This option has no use whatsoever. No modern movie format supports 8-bit color (the encoder will just convert back to 24-bit).
Is that a rendering error on the left above the tree?
As for the SuperPNG plugin, just untick the Quantize box and never look back. This option has no use whatsoever. No modern movie format supports 8-bit color (the encoder will just convert back to 24-bit).
I must be misunderstanding this part, because aren't SDR 1080p blu-rays 8 bit AVC encoded and HDR 4k discs/streams often 10 bit HEVC, eg if using "HDR10"?
Not all compression algorithms are equal, and mostly the older formats are crappier than newer ones. I don't have data for images, but for example for sound you can actually sometimes get smaller files with lossless flac compression than with 320 kbps mp3. Similarly, in video compression x265 codec gives you approximately the same file size at 720p as the x264 would give at 480p.
A proper sound file analogy would be claiming that a 4kHz raw WAV file in a zip is equivalent to a 44kHz 256kbps mp3. They may have the same size, but I think we can all agree they will not have the same quality.
Syl what if he just stripped the alpha channel, ICC profile and metadata? What kind of space savings does that get you? I don't know enough to evaluate what "Smart Quantization" does, but it appears that it can save a lot of space without producing results as you describe. It looks like a histogram of the colors in the image are generated, and then re-indexed to the smallest bit register (8 bit for example) that can still express them as unique, saving you the space 24 bit -> 8 bit time Y pixels gets you.
Personally, I'm not worried if Pyke and his bro fully understand the CS concepts or not, more that they produce a good result in the end.
Look at the example in your link. That's the kind of image a PNG is designed for. It only has 1000 colors, so reducing that to 256 will not be noticeable.
Here, the screenshots have photographic quality, 50 000 colors per image. Reducing that to 256 (=removing 99.5% of the colors) and expecting same quality than a JPG, a format designed for photos, is just wishful thinking.
As for the SuperPNG plugin, just untick the Quantize box and never look back. This option has no use whatsoever. No modern movie format supports 8-bit color (the encoder will just convert back to 24-bit).
I must be misunderstanding this part, because aren't SDR 1080p blu-rays 8 bit AVC encoded and HDR 4k discs/streams often 10 bit HEVC, eg if using "HDR10"?
That's 8 bits per sample, that is 8 bits for red, 8 bits for green, 8 bits for blue, hence 24 bits. When I say 8-bit, that's 8 bits for all 3. So 24 16 millions possible values down to 256.
Movies actually don't use RGB values, but a special case of YUV called YV12 that uses 12 bits to encode 3 samples (luminosity, red and blue). Each one can have 256 values since they code for several pixels at a time. Yeah, that's complicated.
A proper sound file analogy would be claiming that a 4kHz raw WAV file in a zip is equivalent to a 44kHz 256kbps mp3. They may have the same size, but I think we can all agree they will not have the same quality.
Actually, depending on the content - for some low bass sounds, roughly - a 4khz wav may in fact sound better than a 44khz mp3, since lower sample rate only messes up the higher frequencies while mp3 compression affects all of them.
Here, the screenshots have photographic quality, 50 000 colors per image. Reducing that to 256 (=removing 99.5% of the colors) and expecting same quality than a JPG, a format designed for photos, is just wishful thinking.
Why do you assume that the color space will always be down-shifted to 8 bit? I read the link as if the bit register selected was dynamic depending on the color histogram generated for each source image. So some may be 16 bit, etc.
A proper sound file analogy would be claiming that a 4kHz raw WAV file in a zip is equivalent to a 44kHz 256kbps mp3. They may have the same size, but I think we can all agree they will not have the same quality.
Actually, depending on the content - for some low bass sounds, roughly - a 4khz wav may in fact sound better than a 44khz mp3, since lower sample rate only messes up the higher frequencies while mp3 compression affects all of them.
Yes, I know that. Again, photographic quality content can have any shape, any color, any gradient, etc... No special cases here. If the game was pixel-art or anime, I wouldn't be arguing.
Here, the screenshots have photographic quality, 50 000 colors per image. Reducing that to 256 (=removing 99.5% of the colors) and expecting same quality than a JPG, a format designed for photos, is just wishful thinking.
Why do you assume that the color space will always be down-shifted to 8 bit? I read the link as if the bit register selected was dynamic depending on the color histogram generated for each source image. So some may be 16 bit, etc.
Because that's just how it works. I didn't design the PNG format.
To be more precise: You're right, each image has its own palette, but 16-bits PNG doesn't exist.
There is: 48 bits, 24, 8, 4, 2 and 1.
Hmmm now that I look at the table, there is indeed 16 bits. Either 16 bits grayscale (65 000 shades of grey) or 8 bits grayscale (256 shades) + an alpha channel. Not really useful here.
Should be all done by Tuesday. Its a total of 14 minutes of cinematic work so far. If I can get to my B list (which I should get to by release, but they are things like establishing shots and minor 'wouldn't it be cool if' things) it will probably be about 20 - 25 minutes altogether.
Your probably right - Im just an artist, and honestly most technical talk tends to whoosh over me.
I can show you some numbers of a raw frame I just finished rendering from MAX.
The truth is that when rendering an animation the individual frame compression and artifacts aren't 'that' important because motion hides a LOT of errors. Most of the post work I do is to 'degrade' the frame. Motion blur, DOF, particles, 2D camera shake. There is always a trade off between compression quality and size, with motion hiding many of bad things that come with higher compression.
So the image above is the 2.5MB 24-bit PNG (2nd line). That tells us that there is ~8MB of metadata in the 1st file. What??? That's insane. The only explanation I can come up with is that Adobe stores all the layers there. I'm starting to understand why this plugin seems useful.
The JPG file is compressed with 100% quality. That's overkill. 80% is perfect value, no visible difference, huge size reduction. Result: 200KB.
As for the last PNG, the 256 colors version, Irfanview produced a 1MB file. There is also no visible difference but it's a trick as there isn't any high contrast part. That's still 5 times the size of the JPG above.
So what now? I don't know what your pipeline is, but I'm guessing you will make a mp4 with the individual frames. In that case, the only useful file is the STRIPPED PNG, you can ignore everything else. Final file size will be approx.: Number of frames * 200KB / 10 (30MB/mn, 2GB/h).
As for the SuperPNG plugin, just untick the Quantize box and never look back. This option has no use whatsoever. No modern movie format supports 8-bit color (the encoder will just convert back to 24-bit).
Is that a rendering error on the left above the tree?
We've managed to crawl out from behind our desks to post a backer update - woohoo!
I'm sure you've heard of game development "crunch time"? Well, Nic and I are crunching away. Grey, Wintery days here in SA are great for productivity, I can assure you.
We like to joke that we can see the light peaking through the forest (ever so slightly) at the end of this long journey.
Well, we better get back to the grindstone - chat soon!
