Previous Message | Next Message Previous in Topic | Next in Topic Previous by Same Author | Next by Same Author Previous Page (August 2003) | Back to Main IMAGEJ Page
	Reply | Post a New Message | Join or Leave IMAGEJ, or Change Options | Search
	Chronologically | Most Recent First | Wrap Text (Proportional Font) | Don't Wrap Text (Non-proportional Font)

References: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-1
User-Agent: IMP/PHP IMAP webmail program 2.2.7
Message-ID:  <[log in to unmask]>
Date:         Thu, 28 Aug 2003 11:21:54 -0500
Reply-To:     ImageJ Interest Group <[log in to unmask]>
Sender:       ImageJ Interest Group <[log in to unmask]>
From:         Jonathan McKamey <[log in to unmask]>
Subject:      Re: bmp saving in 1.31e
In-Reply-To:  <[log in to unmask]>

> I have one application that refuses to open them, but does open images
> saved in Graphic
> Converter and Photoshop.  It may well be that the problem does not
> reside with ImageJ, but the issue seems to be bits 34 and 35 in the

I asume you mean bytes 34 & 35?
I believe this is wrong but I may be wrong myself .
Image size is bytes 35-38, but that information is _compressed_ size of
image, and 0 is valid if  if compression (byte 31-34) = 0

> header which are supposed to report "size of image data in bytes (including
padding)"

>
> In all cases I am looking at 640 by 480 images.
> When I examine bits 34 and 35 I see:

again, bits or bytes, and is 34 & 35 the right place to look?

In any case, I am working from notes and memory, so I may be completely wrong on
all accounts, in which case, Ignore me.

Center for Information Technology National Institutes of Health Bethesda, Maryland 20892 301 594 6248 (v) 301 496 8294 (TDD) Comments and Assistance Accessibility