CDR Tickets

BZDATETIME::2010-04-08 11:05:36
BZCOMMENTOR::Bob Kline
BZCOMMENT::1

Can you give me an example of an image for which the dimensions were not calculated?

BZDATETIME::2010-04-08 11:13:36
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::2

(In reply to comment #1)
> Can you give me an example of an image for which the dimensions were not
> calculated?

Here are examples (from Bach).

668842. Normal female urinary anatomy-Spanish
668844. Normal male urinary anatomy-Spanish
668855. Extrahepatic bile duct anatomy-Spanish
668854. Gallbladder anatomy-Spanish

In all of the above, the media dimensions were manually entered. Let me know if you want us to remove the dimensions.

BZDATETIME::2010-04-08 16:41:30
BZCOMMENTOR::Bob Kline
BZCOMMENT::3

The problem was that Adobe was stuffing a lot of textual information up at the front of the file, and since I'm no longer reading the entire blob into memory at this point in the processing, I didn't have enough of the bytes at the head of the file to find the height and width. I implemented the quickest solution of just bumping up the number of bytes I read for this purpose. I expect that would solve the problem at least 99% of the time, and every once in a while the user would have to enter the dimensions by hand. This wouldn't be a serious drawback if only the problem occurred with new Media documents. However, it is at least theoretically possible that the user could save a Media document with a replacement image file that stored the dimension information too far distant from the head of the file for the DLL to find it, and the user might not notice that the incorrect dimensions were left in the Media document. Another problem that might occur is that the user stores an existing Media document with an image of a type other than the three from which I know how to extract dimension information (PNG, JPEG, and GIF) and incorrect dimension information is left in the document. Therefore, unless I am told to avoid doing any further work on this task, I plan to consider what I have done so far as a temporary solution, and replace it with a more sophisticated approach involving two improvements. The first change will be to replace the existing approach of reading in the front portion of the file and passing the buffer containing those bytes into the function which extracts the dimension information I will pass in a file handle and have the function read only the bytes it needs, skipping ahead in the file as needed until it finds the dimension information or reaches the end of the file and gives up. The second change will be to look for the HeightPixels and WidthPixels elements in the XML document before doing anything else. If I don't find them, then I'll stop. If I do find them, I'll remove any text content before I try to find the new dimension information. That way I'll avoid all possibility of leaving stale dimension information in the file.

If CIAT is eager enough to get the version of the DLL which has the temporary fix onto Bach they can test it on Mahler to the point where they're convinced that I haven't made things worse by breaking something else. Then when I've implemented the real fix they'll be asked to test that as well. Otherwise they can just wait until I've implemented and unit tested the final solution. Should be done some time next week.

BZDATETIME::2010-04-13 09:41:54
BZCOMMENTOR::Bob Kline
BZCOMMENT::4

I have implemented the more robust solution described above. Please test thoroughly (on Mahler).

BZDATETIME::2010-04-13 11:38:29
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::5

(In reply to comment #4)
> I have implemented the more robust solution described above. Please test
> thoroughly (on Mahler).

Tested on Mahler. Please promote to Bach.

BZDATETIME::2010-04-13 13:53:55
BZCOMMENTOR::Bob Kline
BZCOMMENT::6

Promoted to Bach; please check (and close if OK).

BZDATETIME::2010-04-14 12:00:09
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::7

(In reply to comment #6)
> Promoted to Bach; please check (and close if OK).

Verified on Bach. Issue Closed. Thank you!