file formats
category: general [glöplog]
For a small while now I've noticed that many demo groups use inappropriate file formats for certain textures. On many occasions JPEG is used for simple b/w text images, which bloats the file size and introduces artifacts. What's wrong with using 8 bit PNG for such pictures?
Out of curiousity I tried resaving a few files from one particular production. In the end I guestimated that the 3 megs of graphics could've been reduced to 1 meg. Even a few of the more complex images were smaller in 24 bit PNG. (And lossless too...)
It seems odd to me that someone can code C++, OpenGL, Direct3D, or whatever, but can't determine when it's better to use lossy or lossless image compression.
Or is there some reason to use JPEG exclusively that I just don't understand???
Out of curiousity I tried resaving a few files from one particular production. In the end I guestimated that the 3 megs of graphics could've been reduced to 1 meg. Even a few of the more complex images were smaller in 24 bit PNG. (And lossless too...)
It seems odd to me that someone can code C++, OpenGL, Direct3D, or whatever, but can't determine when it's better to use lossy or lossless image compression.
Or is there some reason to use JPEG exclusively that I just don't understand???
Most people seem to do either a batch convert 5 minutes before the deadline (to fit it into the size limit) or just use whatever format they get the files "delivered" in.
Oh. I see. (Sounds kinda like sloppiness to me...)
When using JPEGs for black/white alpha_masking_ you obviously don't care about the artifacts since you check if the intensity is >50% or <50%.
And normally I tend to use whatever fileformat the gfx-dudine gives me.
And normally I tend to use whatever fileformat the gfx-dudine gives me.
converting them to form an optimal situation is probably something you'd do for a final version or in case you're a perfectionist OR in case you have too much time on your hands (which most democoders dont have).
who cares, as long as it's < sizelimit :D
who cares, as long as it's < sizelimit :D
macaw: ?!? imo people using binary mask with nowadays hardware are dumb ass! the easiest way to remove some of the artifact with b&w jpg is to enlarge the range [16...240] to [0...255]
and ~90% jpg doesn't bring out many artifacts
and ~90% jpg doesn't bring out many artifacts
macaw: Yeah, but PNG would be considerably smaller in file size than JPEG, and no artifacts.
superplek: I don't see how picking the most appropriate format takes a lot of time. And in regards to overall size, what about the bandwidth of sites that host demos for download? A saving of 2 megabytes is pretty large.
superplek: I don't see how picking the most appropriate format takes a lot of time. And in regards to overall size, what about the bandwidth of sites that host demos for download? A saving of 2 megabytes is pretty large.
thom: I think it's worth using loseless compression formats only for pure bitmap & oldschoold edged stuffs
that story about "PNG vs JPG" puzzled me and I just did a test with a 512x512 b&w mask image
in 256 colors PNG » 12.1Kb
in 90% JPG » 11.8Kb ( I've seen no artifacts )
in 2 colors PNG » 4.4Kb
in 39% JPG » 4.3Kb ( few artifacts ( in fact, less than 1,500 pixel had an error between 8/256 and the highest error was 50/256 ) )
of course it's higly dependant on the picture but it shows that the size of that mask picture can be reduced by ~60% and keep it being a real mask ( and not just a binary mask )
that story about "PNG vs JPG" puzzled me and I just did a test with a 512x512 b&w mask image
in 256 colors PNG » 12.1Kb
in 90% JPG » 11.8Kb ( I've seen no artifacts )
in 2 colors PNG » 4.4Kb
in 39% JPG » 4.3Kb ( few artifacts ( in fact, less than 1,500 pixel had an error between 8/256 and the highest error was 50/256 ) )
of course it's higly dependant on the picture but it shows that the size of that mask picture can be reduced by ~60% and keep it being a real mask ( and not just a binary mask )
poi2: I disagree with your findings. Perhaps the program you're using doesn't have good PNG support?? The masks I tested had considerable savings vs. JPEG, often 1/3rd the size, or less. (8 bit PNG) Even 24 bit would've been smaller.
thom: I simply used photoshop :p, the 24bits png was ~35Kb, but as I said it higly depends on the picture
whatever, when I include some images by hand I prefer to stick to one single format ( or one format per type of usage ) so I don't have to remeber if it was in XXX or YYY
whatever, when I include some images by hand I prefer to stick to one single format ( or one format per type of usage ) so I don't have to remeber if it was in XXX or YYY
I've always thought that demos are supposed to be optimized, not only for hardware, but also for size.
Not because of some webserver or the people downloading it, but just because it is possible (or even impossible, in some cases). This would force the demomakers (both graphicians, musicians and coders) to do their work as small as possible, to actually consider size as one the main objectives for their project.
However, since demos nowadays seemingly are to be considered "art", this aspect of demomaking may have gotten lost somewhere along the way, since making things small doesn't have any artistic value. And that sucks, imho.
Not because of some webserver or the people downloading it, but just because it is possible (or even impossible, in some cases). This would force the demomakers (both graphicians, musicians and coders) to do their work as small as possible, to actually consider size as one the main objectives for their project.
However, since demos nowadays seemingly are to be considered "art", this aspect of demomaking may have gotten lost somewhere along the way, since making things small doesn't have any artistic value. And that sucks, imho.
The photoshop png encoder is bullshit :)
Just use pngcrush afterwards or similar tools.
Just use pngcrush afterwards or similar tools.
The old times are over unfortunatelly, the spirit of hardcore coding has been lost a bit :(
Big amount of CPU and HD space makes even good groups make things that would seem preety lame in the older times..
First of all, in most demos there are a lot of multiple files with gfx, music, e.t.c.. that everyone is able to open and see (Thus this is ideal for me to easilly have a look of antioptimizing in their files) and not inside a main dat file or with the Exe. If you look at the older demos, many of them were just one Exe file, or an Exe and a big Data file and not so many raw files.. (Ok, I did it too in my lame qbasic demos ;)
I see several bad things. For example scrollers. Some good sceners have an image file with fonts to use for their scrollie, BUT some others have for example a big 6400*32 image with all the specific scrolltext in one image, or for example another 320*1200 image which has a whole big snaphsot of their upscroller! The good way would be to have the fonts, read the next letter on the ascii of your scrolltext and output them at realtime at the corner and scroll the whole screen to the left, e.t.c.. anyways u got the point...
Several other things happens inside the images of even good demos. Things that can be optimised, but I know that massive CPU and HD and laziness of the coders makes this unecessary..
I totally agree that something could be done to gain important size in demos. But the spirit is not like the old days (You have to be perfectionist, or sick, or masochist to do these optimizes in the modern PC world they say) PCs have gone far away for such things, but I would also like to see hardcore old coding from time to time, everything beeing perfect,.. even the PNGs ;)
ryg: thx, I'll get pngcrush asap :p
as superplek and lug00ber have noticed the most important thing, is that people lack of time, and the time used before to optimize the filesize and make simple packages is now taken to do more artistic things.
but the hardcore times aren't over, else why would there still be 256B, 4Kb and 64Kb productions ? all the more that many productions in these categories are artistics and hardcoded ( the TOP3 productions on POUET are 2 64Kb and a 256B ^__^ )
as superplek and lug00ber have noticed the most important thing, is that people lack of time, and the time used before to optimize the filesize and make simple packages is now taken to do more artistic things.
but the hardcore times aren't over, else why would there still be 256B, 4Kb and 64Kb productions ? all the more that many productions in these categories are artistics and hardcoded ( the TOP3 productions on POUET are 2 64Kb and a 256B ^__^ )
fileformats don't kill demos, people do
poi2: I agree about 64K intros and such. They're the current technical shiznits.
In fact, with the general increasing quality of productions, I kinda think demos are replacing wild demos, 64K intros are replacing demos, and 4K intros are starting to look like 64K intros...
...or maybe not.
In fact, with the general increasing quality of productions, I kinda think demos are replacing wild demos, 64K intros are replacing demos, and 4K intros are starting to look like 64K intros...
...or maybe not.
a nice frame around your painting might make it look better if you know what I mean.. I'm no coder so I can't really judge quality of code but I don't like those blured weird-looking jpeg's that you see in some demos..
