JPG and PNG

I was going to ask why the Unity editor doesn't support jpg/png formats as texture import settings when clearly the engine supports these; but instead Im just going to bump *this* topic over at unity feedback. There you can also find the exact arguments I was going to use to why we need them.

Thank you for your support!

 

???

You can drag and drop png and jpg in and they are correctly converted to internal format.
It makes no sense to have them as color format, because the color formats you choose are about the representation on the graphics chip, there is no jpg and png on graphics chips, there is DXT and plain byte data only (on desktops)

 

Maybe In my statement I wasn't clear enough, click the link and read the info there and you would understand.
Of course Unity can import jpgs pngs but what we don't want is unity to convert it to it's internal format at all, this is important because unitys formats are huge if you want good quality (16, 24 or 32 bits textures) and when making iPhone games you probably want to get under the 20 mega bytes limit for 3g downloads.
And I quote from the link: "I know that DXTs/PVRTCs are better and easier to use for GPUs and loaded much quicker, but they are much larger than JPGs/PNGs. Especially for mobile download apps often app size matters more than loading time.".

Hope I made myself clear

 

Um.. I am sure this wont answer your question, but I recently did a bit of work in this area.. I will show you my links through the reference...

http://unity3d.com/support/documentation/ScriptReference/WWW.html
http://unity3d.com/support/documentation/ScriptReference/WWW-texture.html
http://unity3d.com/support/documentation/ScriptReference/Texture2D.html
http://unity3d.com/support/documentation/ScriptReference/Texture2D.Compress.html

This is runtime importing though. I am looking at the texture importer in the editor and it says all my textures are compressed. Even png's which come in as DXT5's

I dont know if it helps but it looks like things are already working in your favor.

 

Well you are under a few misserable missassumptions:

You are right that theoretically the files are larger.
I say theoretically because on many platforms the assets are 7z compressed upon, while a PNG sizewise is nothing but BMP compressed with ZIP only. As such a PNG is always worlds larger than the internal representation 7z compressed.
Also please do not missconclude the size in the build basing on the data you get to see in the editor, the size you see there is the size it will have in RAM (from where its assigned as "texture data to render" to the 3D API) and VRAM, in these 2 places it can never be JPG or PNG at all, jpg / png is only the format on the harddisk (in any engine)
The formats that a texture can be in RAM for rendering use and VRAM is the ones you can choose as format in the import dialog.


If you want to keep the files in their raw format and pay the price for it with longer loading times (as you would have if unty kept them like this internally) you can always keep them external and load with WWW from file:// or store them as text assets, load them from there and and apply it to a texture2d, both is possible. So nothing preventing you from doing it


Also somewhen in the near future Substance is going to happen for various cases will easily remove the need to use either of them if the texture you want to do was parametrical generated from the start in photoshop etc

 

It's not possible to use PNG or JPG for platforms like iOS, unless you want them to be uncompressed in RAM, because run-time compression to PVRTC takes far too long. Treating PNG or JPG like native formats would be a mistake and cause confusion, since they're not supported by hardware. That's not to say support couldn't be streamlined, but having them as choices along with DXT etc. wouldn't work well.

--Eric

 

I was never under the impression that jpgs or pngs are formats the hardware is able to use directly for rendering, but I see how you thought i was based on my previous posts. I Im already aware of using the WWW class to load in jpgs/pngs - in fact that's what im doing right now in our current project.

My complaint though is the exact same as in the link I posted but it seems nobody is reading that, so I might as well post the whole thing here as a quote (read the bold part):

 

So... this is not a scripting question? This appears to be in the wrong forum. It should be in Unity Support Forum.

We are all looking at this as if you are asking a scripting question, that is why you are not getting the response back that you want.

 

Posting it does not changing it that you don't seem to understand what that dropdown is about.
You still missconcept it as being related to how its stored on the disk (the place where jpg and png exist), but the problem is that dropdown is about the RAM and VRAM representation.

Thats why I'm opposing your whole point of it showing up in there, it would be bullshit as it mixes disk representation with RAM - VRAM representation.

What you want basically would require an additional import setting, one dedicated at disk representation.
That one naturally would need FAT warnings that using PNG will be larger on anything but standalone windows - osx, cause png is always larger than the internal representation + LZMA compression (factor 2-4 depending on image size), which is used aside of standalone windows - osx for the assets on build and a warning that using JPG on mobile gets punished with 2-4 times as high loading times

 

That's the part I don't agree with, because that's not how things work. Streamlining JPG/PNG importing isn't a bad idea, but it should be a separate thing.

--Eric

 

Yes that's right, I just wasn't sure at first where to put it.

Okey I get it now, sorry for my confusion - I had no idea how unity stored it's assets internally after a build. I thought I would save space keeping my image files in jpg/png formats rather then letting unity store them using it's internal compression methods (which I was completely unaware of).

Thanks for explaining this to me, I feel kind of silly thinking that unity would store images/assets without compression, it just wouldn't make any sense

 

Okey, now Im really confused... I just did a test build for iPhone with my current project at work including all images and assets, and the resulting iPhone app size is 250 megabytes. Weird I said to myself, we certainly don't have that much stuff in our project to make up for 250 meg's, so I removed all those images from the unity project I used to load in runtime from disk and made a new build. Before building this time though, I put all those images in the Data/ folder in the xcode project, to get them included in the app as well. This time the resulting app size is now 70 megabytes instead.

So what is going on here? Am I looking at this in the wrong way or Is there a setting I missed? Is it a bug? If unity truly runs some kind of awesome compression on my assets I certainly can't notice that

PS. I tried a mac universal build and same result. And if it makes any difference, a lot of these images where put in the Resources folder in unity.

Thanks!

 

Sounds like you are doing something wrong if the difference is that large or you compare low quality jpg in the xcode project vs the same dropped into the project and not set to compressed. JPG will always grow in size if not set to compressed but thats to expect as JPG is a destructive compression (like hardware compression too, just that hardware compression loads faster than anything else as it can be pushed through to GPU without any processing while jpg loads slower than anything else). If you had 32bit PNG (8bit per channel) the build should be smaller.

Perhaps you also took out models and not only the images? Models can rather easy cause some major growth (I've seen models in the multi hundred mb size)

As for Universal Binary Mac there its expected within boundarys as you get 2 builds in 1 folder basically (PPC vs X86 byte ordering etc)