- Sep 3, 2016
- 2,020
- 4,050
Attached
And about lossy jpg - it looks like that one plugin causes bad plaette conversion. CMYK-->RGB. It is under investigation.
- Sep 11, 2016
- 594
- 1,035
Actually the problem is that there is no conversion done and the CMYK color profile is removed in order to save space (it's about 500KB). The only solution for lossless optimization of CMYK files I have right now is to export the color profile optimize the picture and reimport the color profile. Unfortunately there is no easy way to detect such images and automate the process.
P.S. By converting a picture from CMYK to sRGB you are changing it's colors and thus going the lossy path.
P.S. By converting a picture from CMYK to sRGB you are changing it's colors and thus going the lossy path.
There is much much better way in those Static 3DCgi games which The_Architect uses in his Hack'n Stalk V.2
Seperating background and characters. So you can use same static background many times without size penalty.
In poplar games. Like BB and others. Developers uses same room same camera angle multiple times however in every frame they use same backgrond.
Let say a living room displayed 20 different times with same angle, just characters moving around. In normal game there where 20 different pictures which copy of same background.
How ever in Hack'n Stalk V.2 have one static background and moving character sprites.
And instead of 20 large images for those scenes it has 1 image.
So ? With proper techiques those games may cut under half size.
Question is, Does any one care ?
Seperating background and characters. So you can use same static background many times without size penalty.
In poplar games. Like BB and others. Developers uses same room same camera angle multiple times however in every frame they use same backgrond.
Let say a living room displayed 20 different times with same angle, just characters moving around. In normal game there where 20 different pictures which copy of same background.
How ever in Hack'n Stalk V.2 have one static background and moving character sprites.
And instead of 20 large images for those scenes it has 1 image.
So ? With proper techiques those games may cut under half size.
Question is, Does any one care ?
- Sep 11, 2016
- 594
- 1,035
@hede98, here we are speaking about optimizing the image files regardless of the way the author decides to use them.
If they are not optimized even with the image layered technique you mentioned there won't be much of a difference + it makes the dev's life much more difficult because he have to compose each scene from multiple image files.
P.S. The most common DEV mistake is saving an uncompressed PNG file with the Alpha channel without using any transparency ...
If they are not optimized even with the image layered technique you mentioned there won't be much of a difference + it makes the dev's life much more difficult because he have to compose each scene from multiple image files.
P.S. The most common DEV mistake is saving an uncompressed PNG file with the Alpha channel without using any transparency ...
- Sep 11, 2016
- 594
- 1,035
Let's take My Girlfriend's Amnesia by Daniels K for example - the original "Final" version is 5 087 381 255 bytes and after looslesly compressing it's PNG files it's down to 4 532 394 381 bytes.
Let's do the math: 5 087 381 255 - 4 532 394 381 = 554 986 874 bytes saved with no quality lost at all ...
P.S. The same for all the versions together:
27,0 GB (28 995 919 923 bytes)
vs
24,1 GB (25 904 564 175 bytes)
archived
4,29 GB (4 613 519 128 bytes)
Let's do the math: 5 087 381 255 - 4 532 394 381 = 554 986 874 bytes saved with no quality lost at all ...
P.S. The same for all the versions together:
27,0 GB (28 995 919 923 bytes)
vs
24,1 GB (25 904 564 175 bytes)
archived
4,29 GB (4 613 519 128 bytes)
- Sep 11, 2016
- 594
- 1,035
@evoR can you provide the original picture the webp file was made from? Preferably put both the webp and jpg files in a zip and attach it here.
msfivh.webp == 254KB 1920 x 1080 px
Unoptimized_Studio.jpg == 293KB 1600 x 900 px
msfivh.webp == 254KB 1920 x 1080 px
- Sep 11, 2016
- 594
- 1,035
(Black = no difference; Blue = less than 25% difference; Red = more than 25% difference)
It seems the site is doing some nasty image optimizations to pictures we upload ...
See attached ZIP file for image DIFF.
P.S. The one in the zip is 21KB, and the one mangled by the site is 130KB ...
- Mar 22, 2018
- 482
- 5,596
That's a lot of difference. Also, my settings were not for lossless. I just set quality to 80%.
For some reason when I ran the conversion with lossless in Output -> Settings, the filesize increased about 40%, whatever the reason for that might be. Do you have an idea?
For some reason when I ran the conversion with lossless in Output -> Settings, the filesize increased about 40%, whatever the reason for that might be. Do you have an idea?
- Sep 11, 2016
- 594
- 1,035
That's normal when you are going from a loosy format (JPG) to a loosless one, the PNG version for example is a bit bellow 3MB.
Keep in mind that by selecting quality = 80% you are telling the WebP compressor that it's Ok to loose ~20% of the source file quality when producing the new one thus all the blue color in the diff.
P.S. It's a very bad idea to keep original assets in JPG or loosy WebP format because if you need to change something you will loose even more quality each time you edit the file.
Keep in mind that by selecting quality = 80% you are telling the WebP compressor that it's Ok to loose ~20% of the source file quality when producing the new one thus all the blue color in the diff.
P.S. It's a very bad idea to keep original assets in JPG or loosy WebP format because if you need to change something you will loose even more quality each time you edit the file.
- Sep 3, 2016
- 2,020
- 4,050
xnconvert uses old(er) WebP version with suboptimal settings for lossless. I already contacted developer about it. Current version is 0.6.1 with commandline:
* lossless performance and compression improvements + a new 'cruncher' mode
(-m 6 -q 100)
EDIT: It looks like that for lossless it is better to use:
"-lossless -q 100 -m 6" and don't use -z since it is redudant then
-lossless -q 100 -m 6 gives ~0,6% gain over -lossless -q 100
* lossless performance and compression improvements + a new 'cruncher' mode
(-m 6 -q 100)
EDIT: It looks like that for lossless it is better to use:
"-lossless -q 100 -m 6" and don't use -z since it is redudant then
-lossless -q 100 -m 6 gives ~0,6% gain over -lossless -q 100
- Mar 22, 2018
- 482
- 5,596
@gue5t Which format would you choose to always save as, BMP or PNG? Another example, this time I used 100% quality for the WebP.
About the render, the model ended up having graininess probably because I divided the maps of the model too by two in Scene Optimizer to see the effects. Or not enough lighting? Or because its 5k samples?
BMP: 4,19MB
WebP: 777KB
About the render, the model ended up having graininess probably because I divided the maps of the model too by two in Scene Optimizer to see the effects. Or not enough lighting? Or because its 5k samples?
BMP: 4,19MB
WebP: 777KB
- Sep 3, 2016
- 2,020
- 4,050
I actually verified this. In this example there is LOSSY -q 100 - and comparer shows 0.01% loss. !!! In case of using -losless -q 100 -m 6 we have LOSSLESS image, but larger:
1 919 560 WebP lossless
796 206 WebP -q 100 lossy
4 400 694 BMP
- Sep 3, 2016
- 2,020
- 4,050
- Sep 11, 2016
- 594
- 1,035
Yep it's a match and definitely better than the PNG version's 2,709,525 bytes.
Will have to do some more tests with it.
P.S. From the quick look I had at the WebP doc's you should probably add -mt to the parameters, and also test with "-lossless -q 100 -z 9 -mt"
Will have to do some more tests with it.
P.S. From the quick look I had at the WebP doc's you should probably add -mt to the parameters, and also test with "-lossless -q 100 -z 9 -mt"
- Sep 3, 2016
- 2,020
- 4,050
-mt is multithread, ofc it should be always used.
-z is useless when you set both q and m, because z is preset for q and m.
So rather: "-lossless -q 100 -m 6 -mt"