Crazy resolution

KGhaleonKGhaleon Member Posts: 1,346 ■■■■□□□□□□
This was fun(not really), so I thought I'd share.

So I was contacted by users who said that after having their computers replaced, a certain function on one of the new machines would no longer work. They worked in an engineering department and would daily upload engineering drawings to a server where users could view them off a webpage. The drawings that they were uploading from one computer were no longer being accepted, but this was only affecting a single person.
Basically, they were scanning these drawings which were then turned into .tiff files, but the server would not accept them. The admin looked at the files and said the compression on the file was weird.

I had her login to a different computer which users had no problems with, and she still was
not able to upload any .tiffs. >=(

I took a step back and began troubleshooting from the beginning. I ensured that when she was scanning the drawings that she followed the exact same process as everyone else in the room. There was an application on all their computers which would take the drawing being scanned and turn it into the .tiff, which was then stored on the local hard disk. She would go into it, make sure it looks good and rename the file appropriately, then send it across the network to their department lead who was responsible for uploading the files to the server. Noone had a problem except this one user.

I checked the compression on both machines involved, and there was nothing specific setup. The scanner was fine and worked for everyone else. I had a random user from that area follow the same process and scan a drawing from this woman's computer and it came out fine. No issues, she sent it to their admin who uploaded it to the server.

I couldn't see there being anything wrong with her account, but I mentioned it to our server admin and we went over the .tiffs together. While on the server in a unix environment we ran tiffdump, which showed that the compression level on tiffs from all users in that department was always a "4." However this problem user was uploading tiffs that were displaying a compression of "5." This was the only difference we could see, and the server was not accepting them.

For some time I tried various things, such as reinstalling the app that creates the tiff on the client machine, or playing with the permissions and folders where the tiffs were being dropped, etc.

Yesterday I grabbed a windows copy of tiffdump and went to each computer checking the file compression. It was a 4 after she scanned it. I watched as she went through the process of renaming and transferring to their lead admin. I checked it again after it was on the admins machine and it was a 5. o_o;

I had already checked the lead admins machine and found nothing peculiar, so we tried sending the file to different directories hoping the compression wasn't being inherited from somewhere. No luck.

Finally I returned to the original users machine and went to check the file that was listed as a 4 earlier...but this time it was a 5. O_O; (raging sounds)

I sat down with the user and we went through the process again, having her scan the drawing. After scanning it was a compression of 4...but I decided to check the compression just before she sent it off this time...and I found that it was a 5. (confusion)

I thought maybe when she renamed the file that it was changing the compression, so we went back through and I checked it...and it didn't change when she renamed it. (confusion)

Finally I realized what was happening. The name she gives the .tiff file comes from some numbers that are written on the drawing itself, so she needed to open the file and view the drawing before she could give it a proper name. She would double click on the .tiff and open it in Windows picture and fax viewer, where she would flip the image so that she could view the tags.

This action in Windows picture and fax viewer changed the compression level of the file when she manipulated the image. It was a quick and simple task, which didn't require any writing to the file...and yet it did actually change the file. I met with the server admin and we tried uploading the .tiff before and after she opened it in Windows picture and fax viewer...and that was indeed the source of the problem.

I changed her default viewer to Microsoft office document imaging(which everyone else in the department used), and she has had no problems since then. I'm flabbergasted.

Microsoft, why must you make me question my faith.
Present goals: MCAS, MCSA, 70-680

Comments

  • ULWizULWiz Member Posts: 722
    It was nice to read this story too see a tech step through the process and work with the user to solve the issue. I was confused on the issue as well until i read the last part. User error is common in our field.

    Good Job
    CompTIA A+ Nov 25, 1997
    CompTIA Network+ March 7, 2008
    MCTS Vista 620 June 14, 2008
    MCP Server 290 Nov 15, 2008
    MCP Server 291 In Progress (Exam 12/28/09)
    Cisco CCENT In Progress
    MCP Server 291 In Progress
    C|EH In Progress
  • skrpuneskrpune Member Posts: 1,409
    oh. my. god. I can't believe you had the patience & tenacity to go through all that and find the solution. Hats off to you sir! icon_cheers.gif
    Currently Studying For: Nothing (cert-wise, anyway)
    Next Up: Security+, 291?

    Enrolled in Masters program: CS 2011 expected completion
  • undomielundomiel Member Posts: 2,818
    Something to remember about the picture & fax viewer is that every rotation will resave the image by default. I discovered this several years ago much to my consternation. Those jpegs are lossy enough, no need to make matters worse with clicking rotate several times!
    Jumping on the IT blogging band wagon -- http://www.jefferyland.com/
  • tierstentiersten Member Posts: 4,505
    What undomiel said. When you rotate in that viewer, it is actually saving it each time.

    TIFF itself is a messed up format. The compression schemes used in it aren't particularly well supported in apps. There are also a wide variety of optional tags inside the TIFF file which may be totally ignored by another app or cause it to choke when loading. Add that to the endian issues...
  • 120nm4n120nm4n Member Posts: 116
    I found this one out when my wife would look at pictures on her xD card. She would rotate the picture on her computer, and when she would attempt to look at the pictures on her camera again, the camera would say that the pictures were corrupt.
    WIP: MCITP: EA
    70-620 - Done
    70-647 - In Progress
    70-649 - Soon.
  • tierstentiersten Member Posts: 4,505
    The compression tag you're seeing doesn't mean what level of compression but actually what compression algorithm is being used. 4=CCITT Group 4 fax and 5=LZW. LZW is the compression algorithm inside GIF which caused all the patent issues a few years back. The LZW patents have expired now but it isn't too surprising that apps still don't support it.
  • KGhaleonKGhaleon Member Posts: 1,346 ■■■■□□□□□□
    tiersten wrote: »
    The compression tag you're seeing doesn't mean what level of compression but actually what compression algorithm is being used. 4=CCITT Group 4 fax and 5=LZW. LZW is the compression algorithm inside GIF which caused all the patent issues a few years back. The LZW patents have expired now but it isn't too surprising that apps still don't support it.

    Interesting to know, that may have been a likely reason why the server would not work with the files. Picky Unix.
    Present goals: MCAS, MCSA, 70-680
  • tierstentiersten Member Posts: 4,505
    KGhaleon wrote: »
    Interesting to know, that may have been a likely reason why the server would not work with the files. Picky Unix.
    The OS whether its UNIX or Windows doesn't care what is inside the file. It is whatever app they're using.
Sign In or Register to comment.