Hi, I would like to know why a small file of texture becomes a huge amount of MB??
See the two red circles in the image bellow.
Thanks in advance
Texture_Overload
Forum rules
Please add your OS and Hardware Configuration in your signature, it makes it easier for us to help you analyze problems. Example: Win 7 64 | Geforce GTX680 | i7 3770 | 16GB
Please add your OS and Hardware Configuration in your signature, it makes it easier for us to help you analyze problems. Example: Win 7 64 | Geforce GTX680 | i7 3770 | 16GB
Most textures are stored compressed on disk, but they are then uncompressed when loaded into memory.**STK** wrote:Hi, I would like to know why a small file of texture becomes a huge amount of MB??
See the two red circles in the image bellow.
Thanks in advance
Textures have to be stored uncompressed while rendering, but you can reduce the amount of memory used, but reducing the texture size (i.e. width and height in pixels).**STK** wrote:Ok I see, so octane is decompressing the image file, but is there a work around in order to keep it compressed so the amount of render file low?
Cheers,
Marcus
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
Ok thanks for the reply. For the record those images are already redused from 4000x4000 pix to 1500x1500 pix. A quick thought is octane to use compressed images in order to handle more complex senarios because I had to import 4 characters with the same amount of tex ram in a heavy scene...Keep the good work guys!
Dual Xeon E5540 CPU 2.53 - 1x GTX470 - win7 64 -12GB ram
"Using compressed images" - is there any software that does it? That would mean writing specific algorithms, that would decompress texture data on the fly ((greatly) sacrificing render speed), for all the possible formats out there - jpg, png, tiff, tga... A total waste of programmers time, IMO
For more complex scenarios there is (will be) the (updated) nodesystem and user ingenuity to reuse texture data
For more complex scenarios there is (will be) the (updated) nodesystem and user ingenuity to reuse texture data

SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
cgmo.net
Since video memory is one of the major limitations to GPU rendering at this time, image compression might be something worth looking into. If 1 GB of video memory could be turned into 2 GB or 5 GB that would be a turning point for many people that are sitting on the fence in regards to GPU rendering. It would also allow much more complex scenes to be created.
In addition, new and faster video cards are coming out every few months. But video cards with large amounts of memory are far and few in between.
I don't believe that you would need to worry about all of the compression formats out there. I would think that you would pick one compression format to use and that is the format that you would use to store the compressed image in video memory.matej wrote:That would mean writing specific algorithms, that would decompress texture data on the fly ... for all the possible formats out there - jpg, png, tiff, tga...
While you would probably lose a little performance in regards to rendering, I don't regard that as a reason not to do it. I would gladly sacrifice 10% or 20% of the speed, if I could gain 2x or 5x the amount of video memory.matej wrote: ((greatly) sacrificing render speed)
In addition, new and faster video cards are coming out every few months. But video cards with large amounts of memory are far and few in between.
As I also encountered memory limitations, I studied the thing a little in depth, and my advice would be TO NOT USE JPG images !
First, I thought that using compressed images would save some memory. In fact, it is often the opposite !
The reason is that when the original image contains few differences in a certain color, compression leads to create artifacts and pixellation in areas where the color is changing. This means that compression can generate more different colors than existing colors in the original image.
When the image is uncompressed by Octane, the image weight can be superior to the original uncompressed image ! So, I would rather advice you to use bmp images if you don't need transparency, or PNG or TGA images if an alpha layer is required. These formats are almost lossless, and generate no or few artifacts.
If you original texture is a JPG image coming from a digital camera or a JPG texture found anywhere, I would advice you to convert it in bmp before any modification, and keep it in that format or save it in PNG or TGA if you added a transparency in your image editing software.
As each compression adds new artifacts, if you save an image in jpg after working on it, the uncompressed image will be bigger after each new compression !
First, I thought that using compressed images would save some memory. In fact, it is often the opposite !
The reason is that when the original image contains few differences in a certain color, compression leads to create artifacts and pixellation in areas where the color is changing. This means that compression can generate more different colors than existing colors in the original image.
When the image is uncompressed by Octane, the image weight can be superior to the original uncompressed image ! So, I would rather advice you to use bmp images if you don't need transparency, or PNG or TGA images if an alpha layer is required. These formats are almost lossless, and generate no or few artifacts.
If you original texture is a JPG image coming from a digital camera or a JPG texture found anywhere, I would advice you to convert it in bmp before any modification, and keep it in that format or save it in PNG or TGA if you added a transparency in your image editing software.
As each compression adds new artifacts, if you save an image in jpg after working on it, the uncompressed image will be bigger after each new compression !
French Blender user - CPU : intel Quad QX9650 at 3GHz - 8GB of RAM - Windows 7 Pro 64 bits. Display GPU : GeForce GTX 480 (2 Samsung 2443BW-1920x1600 monitors). External GPUs : two EVGA GTX 580 3GB in a Cubix GPU-Xpander Pro 2. NVidia Driver : 368.22.