#3DSr3 corrupted *.GIF
16 messages in this thread
>>You have to do it the latter way… render the targas out and then compile
them into a flic. There's no way to retain the temp files.
– G<<
While on this topic, I'm having constant problem when VP rendering FLC or FLI
to *.GIF. On all of my four diverse PCs, they give me same problem: Most seq.
#'d *.GIFs are corrupted. (I like to render to *.GIF because it saved huge
amount of diskspace over the Targas) . Another thing I have to do is to
re-rendered the finished seq # *.GIF [in Vpost] without saving to disk so I
could verify the integrity of the file. Is this fixed on r4 or not yet? (I'm
anxious to get r4 very soon)
– SPECT
Hi Spect,
<< Another thing I have to do is to re-rendered the finished seq # *.GIF [in
Vpost] without saving to disk so I could verify the integrity of the file. Is
this fixed on r4 or not yet? (I'm anxious to get r4 very soon) >>
This is not a problem that is known about by me..
Send me the project file and the resultant gifs to review. What is corrupt
about the gifs?
jonas[adesk]
>>Send me the project file and the resultant gifs to review. What is corrupt
about the gifs?<<
Thanks for the concern.
I'm sending you via E-mail the zip'd file called "JR-BUG1.ZIP". It contained
my "AF-SC-NF.prj", "SSAR-LVE.prj" files. These were the VPost test file of all
of the seq #'d GIFs. It have numerous entry & map-paths; "ASOFT-B1.prj" is the
actual project file recreated for this. It have only one entry on the queue.
Then you'll see "CHOP0177.gif, CHOP0178.gif, CHOP0179, CHOP0504.gif,
CHOP0505.gif, CHOP0506.gif. The corrupted ones are: CHOP0178.gif, CHOP0505.gif.
The rest of the GIFs are perfect. I want to give this so that you can compare
byte size, ect… This was re-rendered & recreated today for the purpose of
showing you the problem. There are a total of 600 frames, out of the whole,
only two are corrupted. I don't think you can test any of the uploaded *.PRJ
files since it's not feasable to upload more than 1 gig of the required map
files. Rather, it's for you to see how it was done.
|| History of the problem: The original source were off the CD-ROMs, HDs.
They're perfect. I'd view them via the VIEW FLIC in 3DSr3. I then convert these
FLI/FLC to the *.GIF. This when the problem start. Some of these are fine, but
for strange reasons, some are corrupted. This I mean that anywhere any of those
file will have a bad *.GIF file. All of these rendering were done on 4 PCs [not
simultanously because of the hardware lock & I don't yet have Novel network
set-up]. The PCs are very diverse. They have IDE, SCSI-II; PCI, VLB, & ISA
buses. RAM ranges from 32 Mb to 128 Mb. All PCs were thoroughly diagnosed & all
are ok. [It's not accurate to pre-conclude that the problem is of the hardware
because it's evidented that this is happening on all of the four PCs] However,
all of these computer uses SMARTDRV.exe driver as a software based caching to
enhances disk performance.
AUTOEXEC.bat: Typically regular, no special or abnormal drivers used or loaded.
CONFIG.sys: " " "
"
|| To reproduce this problem: Find any FLI/FLC sources & render them as *.GIF
[source files should be at least 80 frames]. Try several of them (5 or more].
The easiest way to verify the integrity of the files: Add the new map-path
location where you'd saved them. Go to VPost and put the 1st four character of
the seq#'d names plus an " * ". Then press the ALT key on VPost to set the
correct range of frame. Do this for all of your rendered seq.#'d GIFs. You
don't have to move the bars in VPost where its indicating when the bitmap file
should start. This might not be accurate if two corrupted files coincidently
happened at the same frame. My orig. PRJ file also have the BEEP.IXP ipas
[shareware]. This is a handy sound feature that I used to make an audible beep
as this inevitably boring test progresses] Render them without saving to disk.
I bet you'll see the message: "Bitmap xxxx####*.GIF is corrupted". If none of
them aren't corrupted, then I just don't know what to say.
|||||| Side notes: This problem also occured on regular mesh scenes by
rendering without VPost. Try that if your VPost passed all of the file
integrity test mentioned above.|||||||
|| Reasonings for doing this: My main reason for doing to GIFs. 1)
Significantly smaller disk space consumption. 2) The IFL (image file list)
format only takes the 1st frame of the FLC, so I must use the seq. # frames to
have more than one sequence of animated maps. I just don't want several gigs of
composited FLCs where w/ IFL, I could select & re-use the component files for
my scene, thus requiring much lesser disk space to hold them.
|| If this problem is not solved, then I have to alway verify the integrity of
the GIFs by using VPost. Countless hours spending on putting on the queue &
waiting for the corrupted file to appear. Then I have to take note on those
pesky corrupted files. This could take days. Then re-render them again to make
sure they're ok. When they aren't, I have to go to XTree Gold 3.0 to copy the
previous good one & renamed to the next sequentially # frames. What a pain. I
have yet to test the TIFFs, TGAs, BMPs, JPGs ! ! ! !
Regards,
SPECT
As Jonas says, there are no open problems in our gif reading/writing code.
Those routines are completely stable, so if you're getting corrupted files, you
need to start looking carefully at your hardware.
– G
>>you need to start looking carefully at your hardware.<<
Gary:
Yes, I t h o r o u g h l y diagnosed my 4 PCs using QA Plus, MSD, and other
softwares, plus scanning all of my IDE & SCSI-II hard drives, and there are no
problems. However, all of my PCs are using the SMARTDRV.exe . I couldn't find
any documentation(s) in the 3DS's Installation Guide about the Smartdrive
driver. I followed all of the instructions (not to use Memmaker, use HIMEM.sys,
ect…) I also didn't modify any of the CFIG386.exe settings.
Most of these FLI/FLC to *.GIF conversions in VPost took only 1 sec/frame on
the Pentium PCs. I noticed a 6-10 second delay between completed rendering &
writting to disk cycle. D o y o u think the SMARTDRV.exe might c a u s e
t h e c o r r u p t i o n to the *.GIF ? [I have yet to test without using
the smartdrv.exe driver]
– SPECT
T-Spect Le,
<< D o y o u think the SMARTDRV.exe might c a u s e t h e c o r r u p t i
o n to the *.GIF ? >>
There have been successful users of smartdrv over the last year and there have
been some that were not. In a production environment, some would rather invest
in more hardware rather than use additional compression techniques. 3DS users
tend to tax their environments and an intermittant problem is hard to tolerate
when it affects production. Trying to diagnose a failing machine is also
difficult when you add the layer of possible errors during compression.
I have heard of individuals who compress the drive that they keep the system's
static files and executables. However, these individuals keep the swap file and
images on an uncompressed drive. This seems to balance the two naturally.
jonas[adesk]
Hi Jonas,
>>There have been successful users of smartdrv over the last year and there
have been some that were not. In a production environment, some would rather
invest in more hardware rather than use additional compression techniques. 3DS
users tend to tax their environments and an intermittant problem is hard to
tolerate when it affects production. Trying to diagnose a failing machine is
also difficult when you add the layer of possible errors during compression. <<
None of my PC hard drives are compressed, which is DOUBLESPACING. From your
message [correct me if I'm wrong], I think you're referring SMARTDRV.exe as
disk compression. It's a RAM to disk caching method. I'm not fully sure if
SMARTDRV.exe uses compression during the cache cycle. Anyhow, I did try to
DOUBLESPACE my hard drive last year. The results were so "traumatic" that I
vowed never to use it again.
– SPECT
The bottom line is that, out of almost 40,000 licensed 3DS users, you are the
only person who has ever reported a problem with gif writing. You've sent Jonas
a project file for him to look at, and he'll start on it to see if reproducing
it is possible.
Re smartdrive… a cache on certain machines could certainly cause the problem.
Try uninstalling it and see what happens.
– G
>> The bottom line is that, out of almost 40,000 licensed 3DS users,
you are the only person who has ever reported a problem with gif writing. <<
Well, not really. You probably don't remember that I also have
complained about corrupted GIFs… and in the meantime it looks as if some of
my TIFs are corrupted too… Some lines in an image are damaged (showing a
colorful variety of beautiful pixels <g>). It is definitely _NOT_ the hardware
(thorough checks of the data integrity of the used
harddisks/controllers/networks showed no errors – no smartdrv on the network) –
so what's left?
Interesting anyway to learn that someone else encounters the same
problems as I do – one could think that there's more to it than pure
coincidence…?
Volker
PS: The errors show up not only during VideoPost but also during "normal"
Keyframer renderings (one out of 200 images or so) – haven't seen it happen
with a 3D modeler rendering (but usually I don't render some hundred pictures
from the 3D modeler…)
If you're getting a "colorful variety of beautiful pixels" in your gif and/or
tif files, I personally guarantee you that you've got some sort of hardware
problem, or memory management incompatibility. This problems is similar to the
"Invalid .3DS (or .PRJ) file" corruption that some folks get. I've hard of
problems with .TGA file writing as well, when the HD controller had a slight
incompatibility to Phar Lap.
You need to look deeper into your hardware configuraton to find the problem.
– G
Volker,
>> Some lines in an image are damaged (showing a colorful variety of beautiful
pixels <g>). It is definitely _NOT_ the hardware <<
I've had similar problems in the past, with the occasional corrupted .tga file
– and it turned out to be nothing to do with the software. I did some checking
of my network, replaced my network cards and upgraded from Lantastic 4.0 to 5.0
and the problem went away. While I sympathize with your problem, I would bet
money that it IS your hardware or network.
It certainly was in my case.
>> Some lines in an image are damaged (showing a colorful variety of
>> beautiful pixels <g>)
I had a similar problem with JPG's that were related to a bad hard drive. I
performed a surface scan on the disk and found several bad clusters. Once the
bad sectors were locked out, the problem went away.
I ran into another problem displaying files on a Targa board because of a
memory conflict. Excluding D000-DFFF cleared up that problem.
Yet another problem was traced back to a faulty network card that corrupted
image files on their way to the server.
SPECT,
I don't know about your corrupt GIF file problem. If I were you I would run
some tests without smartdrive to see if it was part of the problem.
As an aside, you might get better quality with similar compression ratios using
compressed TIFFs instead of GIFs. GIFs are reduced color pallette dithered
files. When you render with them they must be redithered and repalletted.
This can cause visual artifacts. TIFFs use a similar compression scheme as
GIFs but they are 24-bit files. They may not compress as much as GIFs but they
will compress much more than TGA files do. I always try to keep as much image
quality as possible as far into the process as I can.
Terry Gilbert
Forcade & Associates
Terry:
Thanks for the reply to the GIF problem.
>>As an aside, you might get better quality with similar compression ratios
using compressed TIFFs instead of GIFs.<<
Have you try to render in 3DSr3 to *.TIF or *.TGA w i t h o u t using the
"compression" option in 3DS? I found out that the majority of the time by
using PKZIP compression software, you get almost 46% ratio than with the LZW
compression (20-30% ratio) used in TIFFs (I don't know what Targa uses) THIS
VARIES from image to image.
SPECT
>> Terry:
Thanks for the reply to the GIF problem.
>>As an aside, you might get better quality with similar compression ratios
using compressed TIFFs instead of GIFs.<<
Have you try to render in 3DSr3 to *.TIF or *.TGA w i t h o u t using the
"compression" option in 3DS? I found out that the majority of the time by
using PKZIP compression software, you get almost 46% ratio than with the LZW
compression (20-30% ratio) used in TIFFs (I don't know what Targa uses) THIS
VARIES from image to image.
SPECT <<
Yes the compression does vary from image to image. TGA compression is a
simple RLE scheme that works best for flat areas. Any patterns will defeat the
compression. I'm not sure which compression 3DS uses for its TIFs (packed
pixel maybe). The LZW compression that Photoshop uses is basically as good as
the LZ variant the Pkzip uses.
The advantage to using compressed TIFs (of whatever compression scheme) is that
they maintain 24-bit color and the compression is reasonably good if not always
the best. JPEGs are usually the best compression but the artifacts can be a
problem. For achival/transport purposes PKzip is a good choice but if you are
going to be working with the files then the less compact compressed TIFs are
probably better.
You will have to decide on which compromise of quality, size and convenience is
best for you.
Terry Gilbert
Forcade & Associates