Fri, Nov 22, 12:13 PM CST

Renderosity Forums / Bryce



Welcome to the Bryce Forum

Forum Moderators: TheBryster

Bryce F.A.Q (Last Updated: 2024 Nov 21 4:12 am)

[Gallery]     [Tutorials]


THE PLACE FOR ALL THINGS BRYCE - GOT A PROBLEM? YOU'VE COME TO THE RIGHT PLACE


Subject: My Bryce compresses images.


xenic101 ( ) posted Thu, 13 October 2005 at 10:48 PM ยท edited Fri, 22 November 2024 at 11:59 AM

!!! Working in Bryce 5.5c !!!! I have not tried this with other versions.

I took an image, Paulsjs75's cat head. copy and saved it as a .bmp, .png, and .jpg. These file types are un-compressed, lossless-compressed, and lossy-compressed.
In a new instance of bryce I created a sphere of default grey material. I then changed the diffuse channel to an image texture and loaded one of the image types. The second image space was cleared to white. I entered the material library, saved the material and then exported it. Here's the file size comparison:

original image size: :exported Bryce mat file bmp 9.00Mb 5.19Mb png 2.87Mb 6.25Mb jpg 893kb 5.25mb
I also did a difference check between a copy'd extraction from each mat and the original file that produced it. There was none.
So Bryce does compress, losslessly.

I repeated this with a solid black image. original image size: :exported Bryce mat file bmp 780kb 2.15kb jpg 4.86kb 37.8kb So Bryce compresses images losslessly.

Why the file size explosion AS describes? I'm not completely sure. (But I have an idea.)

Let's try AgentSmith's experiment, I'll ccp it here so you don't need to link. Take a blank bryce scene, put a sphere in it and save the scene. That .br5 scene file should equal about 251kb.
Now I'll apply a 1024x1024, 200kb .jpg to that sphere, and re-save the scene. It won't equal 451kb...in fact, it equals about 2,682kb (2.6Mb)
You will get about the same .br5 file size if you use (import) a .jpg versus a .bmp/.tif/etc.

AS

I did this, I'm going to use the same 9Mb cat head picture from before. Because it's big, so the difference should be obvious.
Sphere with matte grey material= 122kb.
Sphere with 9Mb image material= 5.29Mb.

Go figure. Maybe it's just my Bryce that does it.
Message2284579.jpg


AgentSmith ( ) posted Thu, 13 October 2005 at 10:59 PM

Hmmmm, does what? I must have been bad at making my point originally, lol. But, I was JUST talking about .br5 files sizes only. Yeah, I know about exportation of .mat files and their sizes. My point in the other thread was between using a compressed .jpg and an uncompressed image as a texture, I was just meaning that a user (given the choice) might as well use an uncompressed image, since Bryce won't be able to keep .jpg images at the size internally as they are originally, and uncompressed images won't have jpg artifacts. That's all. In the past some users thought if they imported a .jpg instead of a .bmp, their .br5 file sizes would be smaller. I was just tryting to point out that wouldn't be true. VERY unfortunately, not true, lol. Maybe a Bryce 6 will be able to use external .jpg's, and cut down on our file scene sizes. AS

Contact Me | Gallery | Freestuff | IMDB Credits | Personal Site
"I want to be what I was when I wanted to be what I am now"


Incarnadine ( ) posted Thu, 13 October 2005 at 11:01 PM

Interesting results.

Pass no temptation lightly by, for one never knows when it may pass again!


xenic101 ( ) posted Thu, 13 October 2005 at 11:11 PM

This is true, and I agree. However there seems to be the opinion that Bryce uncompresses images. That's not accurate. When a compressed file is read, it gets uncompressed. By any program, it still takes up all 24bits per pixel in memory. (give or take a few bytes). Bryce then saves it using a lossless compression scheme. Let's face it, do you really want your hi-resoulution texture map ruined by using a lossy compression scheme? For that reason, yes, don't bother compressing image files before using them as a texture in Bryce or anywhere. If you save it as a .jpg, you are going to lose detail. With regards to the .br5 size question, same point. I used a 9Mb image as a texture on a sphere and got a 5.29Mb .br5 file. Looking at your example, you show a file size increase of 4 times the image's size. When I tried it, the file size increased by just over half the image's size. Why?


AgentSmith ( ) posted Thu, 13 October 2005 at 11:29 PM

I gotcha. Why? The image I used to test was 1024x1024, as a jpg, I intentionally saved it so it would be 200kb, but as an uncompressed .bmp it is 3,145,782kb Since Bryce DOES use some sort of lossless compression, I would hazard a guess it has to do with the color data. Meaning you can convert 10 different images, which are all the same dimensions, as jpgs, and get 10 VERY different file sizes, even when ther are all saved at the same jpg quality. If there are more colors (more data), the jpg will be larger. Just a guess in the dark. AS

Contact Me | Gallery | Freestuff | IMDB Credits | Personal Site
"I want to be what I was when I wanted to be what I am now"


xenic101 ( ) posted Thu, 13 October 2005 at 11:34 PM

Makes, sense. Interesting point from all these numbers: Because of the 'fuzz' that jpg's are renown for, when Bryce resaves the image losslessly, it's bigger than if it hadn't been saved as a jpg in the first place.


Gog ( ) posted Fri, 14 October 2005 at 9:48 AM

It's not about number of colours, in jpg it's about how fast they change, a 2 colour image that swapped every pixel to create a dither pattern will still be huge as jpg uses a length - string compression. For example, colour the next 100 pixels in x colour, now some of the pixels may have slightly different shades, but they'll be blocked to make the compression more effective, hence the loss.

----------

Toolset: Blender, GIMP, Indigo Render, LuxRender, TopMod, Knotplot, Ivy Gen, Plant Studio.


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.