It appears if we render a TGA file (with compression set to on) tiled the stitched file does not have compression on, so the file size are coming out enourmous.
I’d imagine the file would look funy if you compressed individual tiles and then put them back together due to the nature of compression.
It’s a lossless compression so it shouldn’t have any effect.
My understanding was that uncompressed left the image exactly as it was whereas lossless compression used an algorithm to understand the image and rather than repeat the same colour data it stores the location and repeats it throught the image where needed. (why an all black image can be compressed lossless’ly to almost nothing)
This means if you comressed each tile it would be calculated differently for each tile, re-assembling it would mean the different calculations would have to be added together.
I’m sure it used to work, and it used to work fine back in the day with backburner, with no obvious differences in strips.
TGA use RLE compression.
en.wikipedia.org/wiki/Run-length_encoding
So only works well for files where you have block colour, and as we only really use TGAs for CC masks they tend to compress rather well.
Any update on this Russell?
We haven’t looked into it yet. If you want to post some sample tiles (ie: a collection of 4-8 tiles should suffice), we can use them for testing here to see what we can do about it.
Thanks!
- Ryan
See attached…
TGA’s save as 32bits/pixel, so RGBA…
Locally, I save the render with and without compression.
Local_compressed.tga 2,271 KB
Local_uncompressed.tga 3,601 KB
Then kicked it off to deadline with compression on.
deadline_render_0000.tga 3,601KB
I opened one of the tiles in photoshop and re-saved it, making sure compression is on, and it didn’t change file size.
So it’s the assembler that’s not putting compression on, I know it’s awkward to detect compression settings in files but I can’t see any reason not to have save compressed set to on by default in the assembler for TGA files.
deadline_tiles_test.rar (4.54 MB)
Thanks! I just tested them out, and it appears that Image Magick isn’t recognizing the compression level of the input images. It doesn’t even recognize the compression level of the local compressed image you included. We create the final image using the properties of one of the input tiles, so if no compression is detected, then no compression is applied.
I also tested forcing RLE compression to be enabled, but that surprisingly didn’t help either. I don’t know if maybe this is a bug in the version of Image Magick that our tile assembler uses, but whatever the problem is, it’s not obvious what the cause is…
Thanks for testing that Russell, it’s strange as I’m sure it’s been working before in previous Deadline versions… Think we’ll switch to PNG for the time being…
Did some more digging on this, apparently RLE encoding is not part of ImageMagick, it’s not complicated to add RLE encoding to the tga.c part of ImageMagik, but that’s not in my current skill set unfortunately. I’m trying to find another command-line tool which has RLE that I can use as a post-job completion script. Annoyingly there doesn’t even seem to be a way to save TGA files using Python… or this could be a lot simpler.
Any C coders feel like a challenge?
http://trac.imagemagick.org/browser/ImageMagick/trunk/coders/tga.c
http://rosettacode.org/wiki/Run-length_encoding/C
The code appears to be in this…
http://www.opensource.apple.com/source/tcl/tcl-20/tcl_ext/tkimg/tkimg/tga/tga.c