[Flaming_Sword]

Just throwing this out there:

Would anyone find PNG support useful?

Does anyone use JPEG for their modding?

Would anyone care if JPEG support got removed?

[The E]

Remove jpg. Anyone using jpg for anything besides interface art should be shot. And even there, jpg suffers from a lack of transparency and introduces ugly artefacts. PNG FTW.

[Dragon]

TBP and Zatharas are using .JPG for some of their textures, I was using it a long time ago when making effects and textures, so changing it will require messing with something old that works perfectly  now. Plus I don't really see anything we can gain form removing .JPG, and it's most likely going to take time and effort, meaning delay in commiting changes. Adding PNG is obviously a good idea, as it's going to be a new feature that will allow new possiblities. So I vote to keep .JPG and add PNG.

[Spoon]

Add and Keep
It's not really an argument to say "I think .jpg sucks and everyone thinking about using it should be shot". To avoid total breakage of older mods/campaigns, just keep it. Unless it is in some way interferring with added .png support or something.

[TopAce]

Keep it. Definitely.

Why remove it?

[Getter Robo G]

Don't care, I use PCX. 


 

[shiv]

Remove jpg. Anyone using jpg for anything besides interface art should be shot. And even there, jpg suffers from a lack of transparency and introduces ugly artefacts. PNG FTW.

Agreed.

[Spoon]

Blueplanet has a few .jpg's in the interface folder
Edit: Though that's the old version I'm looking at here apparantly. So disregard me.

[FUBAR-BDHR]

TBP does?  I'll have to see about converting those.

So it does.  Mostly planets and skyboxes.  Wondering if that is causing slowdowns now. 

[Mongoose]

Seriously, what would be gained by removing it?  By all means add support for the superior format, but for the sake of not screwing over who knows how many older fan-made materials, leave .jpg in there too.  Isn't one of the primary goals of the SCP supposed to be maintaining backwards compatibility?

[pecenipicek]

PNG?!?


THE **** IS WRONG WITH DDS?!?




sorry for the shouting, but isnt png extremely inefficient for game usage?


also, DDS is superior to it in any way, except for the complexity of making a proper dds.

[Qent]

sorry for the shouting, but isnt png extremely inefficient for game usage?

Interface art?

[pecenipicek]

dds can do it too

just because artists are lazy, it doesnt mean that an truly inferior technology should make its way in.

[FreeSpaceFreak]

Don't remove anything, or things will break. PNG support would be nice though. Not as big a download as uncompressed DDS, and doesn't have compression artefacts like compressed DDS often has.

[The E]

dds can do it too

just because artists are lazy, it doesnt mean that an truly inferior technology should make its way in.

Except that uncompressed u8888 dds take up a lot more space than the equivalent pngs. Except that compressed dds introduces compression artefacts. Except that png is actually pretty workflow-friendly.

[pecenipicek]

Except its memory inefficient. And utterly useless in real-time or offline renderer.

[Zacam]

2_Options_Main. 1024x768. As a 32bit Color graphic.

Uncompressed DDS (u888): 2,363,392

TGA: Same as uncompressed DDS.

DXT1 DDS: 397,312 but has artifacting which will only get worse with successive edits and saves.

JPG, Quality 12 (no compression): 233,472 still introduces JPG Moire along edges and borders, will get worse with successive edits and saves, no transparency. More compression will mean significantly smaller sizes, but further reduction in quality.

PNG: 294,912 no compression artifacts. Successive edits and saves offer no change in quality, meaning that working copies can be refined without the massive space used by DDS. Transparency and Alpha-Blended transparency (gradient) supported. Smaller than DXT1 without any quality issues.

Further more: PNG implementation and support for rendering does not, when done properly, incur any more overhead for processing the PNG image than the DDS rendering code does in rendering DDS files. In a WORSE case scenarios, it's not going to consume any more over-head than the existing JPG/PCX libraries. And if it consumes as much as TGA does, I'll shoot somebody.

EDIT: And even more further more: Anybody assuming that just because JPG is in the engine means that OMFG somebody most be using it: Only TBP and Flames of War can be found to use JPG files, and ONLY as interface art. JPG, while usable on a model, most certainly NOT be. So JPG's only sad lonely existence is currently as an alternative interface format that you can't even EFF and have look good. The file count is so damn small that the fabrication of PNG replacements would be easy to accomplish.

[Nuke]

i can see a few places where youd want to use jpg. such as tech animations. since its animated the artifacts wont even be noticed. jpeg eff could be used to save drive space (memory usage in this case shouldnt even be an issue). another place is to make the mod download smaller using the better (but lossy) compression ratio no textures. have the engine convert those textures to the propper dds format and output the texture as a dds in the cache folder. that way mods can have their textures packed down in jpeg format. the engine would convert them to dds and use those from then on.

i really cant think of any reason to use png. if i want limited lossless compression i could use tga with rle. though i see very few uses for it. all model textures especially large textures should be compressed, as should animations. normal / height maps should be compressed if possible. all large effects should be compressed (thousgh sometimes it pays off to use a low res 8888 on some smaller effects). the only place you really need lossless is in the interface and hud, and tga or 888/8 dds works fine for that.

[The E]

i can see a few places where youd want to use jpg. such as tech animations. since its animated the artifacts wont even be noticed. jpeg eff could be used to save drive space (memory usage in this case shouldnt even be an issue). another place is to make the mod download smaller using the better (but lossy) compression ratio no textures. have the engine convert those textures to the propper dds format and output the texture as a dds in the cache folder. that way mods can have their textures packed down in jpeg format. the engine would convert them to dds and use those from then on.

The problem is that jpg does not support transparency. And using the "green is transparent" workaround that is available for pcx is definitely not a good idea if you are using a lossy compression.

[Zacam]

Jesus.

TGA existis because no image editior in the world needs any (or should need any) plugins or what not to use it. I'm fine with that. Even has transparency. But did you miss the file sizes listed above? F'ing huge wherever it is used.

Yes, at no compression the JPG is SLIGHTLY smaller. See the emphasis on slightly? Thought so. Now, have a transparency. Can't be done unless you make a SECOND jpeg for use as a mask. Assuming that mask support for the file in question is in the exe. JPG as an EFF compared to the other farmats is frankly a joke and I've NEVER seen it used. Anywhere. Period. Conversion of JPG in mem to a DDS? As in, -img2dds flag? Adds computational overhead and if it's for something that needs to be mip-mapped, it should be in DDS to begin with, and -img2dds adds compression on top of it, so an already compressed JPG will look even MORE like ass compared to a straight PNG.

For compressed container storage, both JPG and PNG have negligible differences between the resulting file size. I really cannot think of any reason why to use a jpeg where a PNG could be better served all the way around. No corruption of the image during frequent edits/saves for a texture usage that doesn't require or need being in DDS (compressed or otherwise, and the image quality vs a compressed DDS (See DXT1 above) is far superior).