StripByteCounts changed after drawing text

[jzfields80]

before StripByteCounts (5 Long): 8232, 8232, 8232, 8232, 5488

after

StripByteCounts (10 Long): 7840, 7840, 7840, 7840, 7840, 7840, 7840,...


I wish I knew what that meant!?!?

Any help is greatly appreciated.


the upshot is that the image is corrupted, looks weird in our proprietary viewer.

The code i executed from VC6 (edited to protect the identity of the not so innocent)

LPCSTR pText;
MagickLib::ExceptionInfo myinfo;

Magick::InitializeMagick("C:\\code\\imagemagickwindows\\ImageMagick-6.3.4\\VisualMagick\\lib");
Magick::Image myImage;// = new Magick::Image();
myImage.read("jzf1.tif");
pWidth =50;
pHeight =100;
pText = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
std::list<Magick::Drawable> drawList;
drawList.push_back(Magick::DrawablePointSize(10));
drawList.push_back(Magick::DrawableText(pWidth, pHeight, pText));
myImage.draw(drawList);
myImage.write(jzf1texted.tif");

[magick]

Post a URL to one or two images that exhibit the problem so we can download them and reproduce the problem.

[jzfields80]

http://mybabyblogger.com/tiffs/110MHz-8 ... texted.tif

and

http://mybabyblogger.com/tiffs/110MHz-8 ... ayJZF1.tif

[magick]

The problem you reported is fixed in ImageMagick 6.3.5-1 Beta available sometime tommorrow. In the mean-time you can set the strip size like this:

• convert 110MHz-8mm-20um-trayJZF1.tif -define tiff:rows-per-strip=42 image.tif

[jzfields80]

kudos for the quick response. Perhaps you can help me a bit further.

When I load the tiff back into proprietary viewer.this is the image we get.
http://mybabyblogger.com/tiffs/whatnow.bmp
The file might take a while to d-load.
The image does look okay in the windows viewer so i know it is something that we aren't accounting for in our viewer but any changes that I make to the tiff file can't break backwards compatibility with older viewers....

I ran the convert command as you suggested... Wonder what else it might be?