Black&white TGA files

[A.D. Fundum]

Is there an OS/2 app which can write 1bpp or black&white TGA files,
i.e. the third byte of the created TGA file equals 3 or 11?

PMView doesn't save another 1bpp file (1BPP.PCX) as a 1bpp TGA file.
GBM's editor claims that the output "file format doesn't support this
bits per pixel", even if the original 1bpp 1BPP.PCX file is
"converted"/mapped to a 1bpp file.

Untested one-liner showing the value of the first three bytes,
assuming a 1bpp file called "X.TGA". The second byte has to be 0 (no
color map), the third byte has to be 3 or 11.

REXXTRY f='X.TGA';DO 3;SAY C2D(CharIn(f,,1));END

Please note both black and white may be a color and PMView uses a
color map (second byte is 1), but 1bpp should ignore such an issue.
And 3 or 11 does imply a "black-and-white image" anyway.

FTR: IMHO it's a GBM bug, since the "Save as..." TGA file format does
seem to support a black-and-white image, i.e. 1bpp. The GBM Editor
assumes a "map" of 8bpp. And it's maybe a PMView bug, it doesn't save
a 1bpp black-and-white PCX source file as a 1bpp black-and-white TGA
file. Instead PMView uses a color map. Hence the question, are there
GA graphical OS/2 apps capable of properly saving a 1bpp
black-and-white TGA file: second byte 0, third byte 3 or 11?


--

[mentoruccio]

Post by A.D. Fundum
Is there an OS/2 app which can write 1bpp or black&white TGA files,
i.e. the third byte of the created TGA file equals 3 or 11?
PMView doesn't save another 1bpp file (1BPP.PCX) as a 1bpp TGA file.
GBM's editor claims that the output "file format doesn't support this
bits per pixel", even if the original 1bpp 1BPP.PCX file is
"converted"/mapped to a 1bpp file.
Untested one-liner showing the value of the first three bytes,
assuming a 1bpp file called "X.TGA". The second byte has to be 0 (no
color map), the third byte has to be 3 or 11.
REXXTRY f='X.TGA';DO 3;SAY C2D(CharIn(f,,1));END
Please note both black and white may be a color and PMView uses a
color map (second byte is 1), but 1bpp should ignore such an issue.
And 3 or 11 does imply a "black-and-white image" anyway.
FTR: IMHO it's a GBM bug, since the "Save as..." TGA file format does
seem to support a black-and-white image, i.e. 1bpp. The GBM Editor
assumes a "map" of 8bpp. And it's maybe a PMView bug, it doesn't save
a 1bpp black-and-white PCX source file as a 1bpp black-and-white TGA
file. Instead PMView uses a color map. Hence the question, are there
GA graphical OS/2 apps capable of properly saving a 1bpp
black-and-white TGA file: second byte 0, third byte 3 or 11?

Did you try ImageMagick from Paul Smedley? There's much software (even
if commandline driven) to convert between image formats.

I don't know if Embellish can do it.

Mentore

[A.D. Fundum]

Post by mentoruccio
Did you try ImageMagick from Paul Smedley?

No, but that's just because I have the other ones (NConvert,
Embellish) already installed.

Post by mentoruccio
There's much software to convert between
image formats.

The underlying issue is a conversion (of formatS) to another format.
If I don't support a format, the user has to use those tools.

Post by mentoruccio
I don't know if Embellish can do it.

Yes, thanks, unlike NConvert "saving as ..." the 1bpp PCX file as a
1Bpp TGA file. Byte 2 is 0 (no color map), byte 3 is 3
(black-and-white, but no RLE). There are 39440 pixels and 18 header
bytes, the TGA file size of Embellish is 39458 bytes.

NConvert's (bitmap, 8 pixels per byte) header byte 17&18: 1, 32.
Embellish's (bytemap, 1 pixel per byte) header byte 17&18: 8,0.


--

[A.D. Fundum]

Post by A.D. Fundum

Post by mentoruccio
Did you try ImageMagick

Embellish's (bytemap, 1 pixel per byte) header byte 17&18: 8,0.

After downloading about 30 MB of *nix-directory structures and 20
minutes of installing, ImageMagick's convert.exe also produced such a
bytemap (1 pixel per byte) without using RLE.


--

[Ruediger Ihle]

Post by A.D. Fundum

Post by A.D. Fundum

Post by mentoruccio
Did you try ImageMagick

Embellish's (bytemap, 1 pixel per byte) header byte 17&18: 8,0.

After downloading about 30 MB of *nix-directory structures and 20
minutes of installing, ImageMagick's convert.exe also produced such a
bytemap (1 pixel per byte) without using RLE.

Browsing the web for TGA specs, I've seen no indication that the
1 bit/pixel variant is valid (however, it might be an extension
to the original format specs). Have you found any program that
actually can read it ? According to the docs, "Each pixel is
stored as an integral number of bytes", which means 1 byte per
pixel. Even if more would fit in. Furthermore, the docs say that
the data types 3 and 11 are used for "storing raster images where
each pixel can be represented by a grey-scale value". I.O.W, the
byte does not just specify an on/off info but levels of grey.

[A.D. Fundum]

Post by Ruediger Ihle
Browsing the web for TGA specs, I've seen no indication that
the 1 bit/pixel variant is valid

Having read descriptions, as opposed to reading perhaps more accurate
specs, I saw tables claiming TGA supports 1bpp. I also read that a
pixel always takes a byte if RLE is used. I also read both
"black-and-white" and grey regarding type 3, but that's determinable
by the number of bpps in the header (if the format byte is 3 or 11,
1bpp can indicate b/w and >1bpp can indicate greys).

Post by Ruediger Ihle
Have you found any program that actually can read it ?

No, i.e. the 1bpp TGA file produced by NConvert if the input file is a
1bpp PCX file.

Post by Ruediger Ihle
I.O.W, the byte does not just specify an on/off info but levels of

grey.

If so (1Bpp), NConvert has a bug because it produces a 1bpp TGA file
and GBM has a bug because it cannot save a 1bpp PCX file as a 1Bpp
(AKA 8bpp) TGA file. Perhaps GBM's error message has to be a warning,
at best. PMView doesn't use the data type 3 or 11 when a
black-and-white source file is used, it adds unneeded bytes after the
18 bytes header.

BTW, it's also unclear (to me) how RLE has to be interpreted if the
first byte is <128. Embellish seems to support types 3 and 11.

So AFAICT it's okay to support mode 3 (no RLE), maybe support mode 11
(RLE, if fully understood), and to assume 8bpp indeed, and to allow
pixel values of 0x00 XOR 0xff (black-and-white only, elliminating
greys). This approach will reject TGA files produced by e.g. PMView
(type not 3 or 11), NConvert (1bpp) and GBM (no file), but the user
should be able to solve that by converting the files to another
supported format.


--

[Heiko Nitzsche]

Post by Ruediger Ihle
Browsing the web for TGA specs, I've seen no indication that the
1 bit/pixel variant is valid (however, it might be an extension
to the original format specs). Have you found any program that
actually can read it ? According to the docs, "Each pixel is
stored as an integral number of bytes", which means 1 byte per
pixel. Even if more would fit in. Furthermore, the docs say that
the data types 3 and 11 are used for "storing raster images where
each pixel can be represented by a grey-scale value". I.O.W, the
byte does not just specify an on/off info but levels of grey.

Yeah, I seem to have overseen the

"Each index is stored as an integral number bytes"

in the recently posted GBM beta. I used the normal logic where bpp
defines the index width for a pixel (e.g. 4bpp mean 4bits per pixel).

Using a whole byte for a 1bpp pixel would be a huge waste of memory.
But if it really turns out to be the spec, I'll have to rework the
beta implementation again.
Then the funny thing is that XnView/nconvert actually reads the 1bpp
TGAs just fine when created as 1 bit per pixel instead of 1 byte per
pixel. Unfortunately the TGA spec is quite a bit fuzzy, so figuring
out what is correct is almost impossible.

[A.D. Fundum]

Post by Heiko Nitzsche
"Each index is stored as an integral number bytes"

FTR: that, an index, may apply to the color map. Not to pixels. It
doesn't read "Each pixel is stored as an integral number of bytes". In
a situation where the type is 3, the color map is 0 and the number of
bpps (according to the header) is 1, 1bpp is possible. But not when
using RLE, which implies the use of (at least) 1 byte for the data
byte.

You can distinguish between the "color depth" and "color map" by
looking for a 15bpp, which certainly applies to the color map.

Post by Heiko Nitzsche
figuring out what is correct is almost impossible.

Regarding NConvert, a case of YMMV? Acoording to the "Technical
details" section of the unreliable Wikipedia, TGA does support a color
depth of 1 bpp (and 2, and 4, and ...). Please note the color depth is
not the color map, which is 8+ bpp indeed (and supports 15bpp):

http://en.wikipedia.org/wiki/Comparison_of_graphics_file_formats

But according to this Wikipedia resource, it's a byte for type 3 (and
11):

http://en.wikipedia.org/wiki/Truevision_TGA

Go figure.

Again FTR, it'll be a gain if GBM would convert/save a true 1bpp BMP
input file to a 8bpp TGA file. The file can be saved indeed. Or use
type 1 and a greyscale color map, yet another option. That way 1bpp
isn't even possible, because 1bpp requires type 3.

I think I'm going to support 1bpp upto and including 8bpp, so long as
the rest of the header makes sense. If the type is 3, there's no color
map, and the number of bpps is 1, I don't have a reason to refuse to
interprete the file produced by e.g. Embellish. In case of GBM, it's
possible to avoid the discussion by using 8bpp anyway, undrestandably
waisting more bytes than needed.


--

[Heiko Nitzsche]

Post by A.D. Fundum

Post by Heiko Nitzsche
"Each index is stored as an integral number bytes"

FTR: that, an index, may apply to the color map. Not to pixels. It
doesn't read "Each pixel is stored as an integral number of bytes". In

Here is what is documented in the above official spec:
(found here: http://googlesites.inequation.org/tgautilities)

Image Data - Field 8:
"This field contains (Width)x(Height) pixels. Each pixel specifies
image data in one of the following formats: a single color-map index
for Pseudo-Color; Attribute, Red, Green and Blue ordered data for
True-Color; and independent color-map indices for Direct-Color. The
values for Width and Height are specified in Fields 5.3 and 5.4
respectively.
The number of attribute and color-definition bits for each pixel are
defined in Fields 5.6 and 5.5, respectively. Each pixel is stored
as an integral number of bytes."

Especially the last sentence says that each pixel will always be stored
in at least 1 byte. Field 5.5 (Pixel Depth) would describe the number
of valid bits in a data byte that encode the palette entry or the
grey code.
For type 3 or 11 this would mean that if field 5.5 (Pixel Depth, or bpp)
contains a 1, each image data byte represents 1 pixel, having only 1
and 0 as valid values (for type 3 it means 0=black, 1=white). For 4bpp
still a byte per pixel is stored with valid values 0-15 (0=black,
1=(gray 17), 2=(gray 34), 3=(gray 51), 4=(gray 68),..., 15=white(255 gray)).
For 8bpp the direct greylevel (0-255) is stored.

Finally this would mean that XnView/nconvert (and the beta GBM) creates
illegal 1bpp TGA files (8 pixels in 1 data byte). Embellish always creates
always 8bpp full greylevel files, even if source data is black and white
(it stores 0 for black and 255 for white).

Indeed the Embellish approach seems to be the most compatible and reasonable.
Doing the extra conversion for 1bpp or 4bpp would have no benefit in terms
of data size but it may cause more compatibility issues with other programs.
I'm not sure why the definition for 1-7bpp should be used at all for type 3
or 11 as it provides no real benefit. The only reason could be some weired
simplification for old greyscale TGA graphics hardware which might have had
such addressing modes. For palette images it does make sense as it saves
entries in the color table. Maybe that's what it is designed for.

For the final GBM TGA codec I'll most probably follow the Embellish approach
when writing greylevel TGA 1bpp and 4bpp files (always expand to 8bpp). For
reading I'll add support for real 1bpp and 4bpp (as described above). Because
also 1bpp and 4bpp would have a byte per pixel, I'll most probably also be
able to reuse the existing RLE decoder, so type 11 reading should be reasonable
also for 1bpp and 4bpp.

Post by A.D. Fundum
Again FTR, it'll be a gain if GBM would convert/save a true 1bpp BMP
input file to a 8bpp TGA file. The file can be saved indeed. Or use

Yeah, it will be possible and done.

Post by A.D. Fundum
type 1 and a greyscale color map, yet another option. That way 1bpp
isn't even possible, because 1bpp requires type 3.

Following the above spec interpretation it is also possible to write a
1bpp or 4bpp color mapped file (type 1). 1bpp does not automatically
imply that it is black/white, it could also be green/red if a palette
is provided.

A type 3 compatible source image color map is already detected in beta
GBM. If it is not compliant, a color mapped file (type 1) is written
(that's why the gbmbpp -m hint).

Post by A.D. Fundum
I think I'm going to support 1bpp upto and including 8bpp, so long as
the rest of the header makes sense. If the type is 3, there's no color
map, and the number of bpps is 1, I don't have a reason to refuse to
interprete the file produced by e.g. Embellish. In case of GBM, it's
possible to avoid the discussion by using 8bpp anyway, undrestandably
waisting more bytes than needed.

As I analyzed (see above), Embellish seems to always write 8bpp
greylevels TGAs. I wasn't able to create a 1bpp file that stores
more than 1 pixel. If you have found such a case, please let me
know how to get there.

[Heiko Nitzsche]

Now I found a case where multiple pixels may be stored
in a byte following the Pixel Depth size.

It is obviously done in the RLE encoding scheme (see last
3 pages in the referenced original TGA spec). Also RLE
compression of non-byte pixel depths (e.g. 1bpp) seems
to be possible but because of complicated decoding
(non-aligned pixel access) it's probably not often
supported by graphics programs.

Unfortunately all spec document examples use only pixel
depths of 8 or 24. So it isn't really clarifying our
assumptions regarding pixel depths lower than 8.

[Heiko Nitzsche]

OK, now I had a look at the TGAutils code package
from the link posted before and the code clearly
creates and expects full byte(s) per pixel, even
for RLE encoded data:

TGAPACK.C:1142
--------------
bytesPerPixel = (sp->pixelDepth + 7) >> 3;
bCount = sp->imageWidth * bytesPerPixel;

Very useful. Also a RLE encoder is included.

[Steve]

Post by Heiko Nitzsche
The number of attribute and color-definition bits for each pixel are
defined in Fields 5.6 and 5.5, respectively. Each pixel is stored
as an integral number of bytes."
Especially the last sentence says that each pixel will always be stored
in at least 1 byte. Field 5.5 (Pixel Depth) would describe the number
of valid bits in a data byte that encode the palette entry or the
grey code.
For type 3 or 11 this would mean that if field 5.5 (Pixel Depth, or bpp)
contains a 1, each image data byte represents 1 pixel, having only 1
and 0 as valid values (for type 3 it means 0=black, 1=white). For 4bpp
still a byte per pixel is stored with valid values 0-15 (0=black,
1=(gray 17), 2=(gray 34), 3=(gray 51), 4=(gray 68),..., 15=white(255 gray)).
For 8bpp the direct greylevel (0-255) is stored.
Finally this would mean that XnView/nconvert (and the beta GBM) creates
illegal 1bpp TGA files (8 pixels in 1 data byte). Embellish always creates
always 8bpp full greylevel files, even if source data is black and white
(it stores 0 for black and 255 for white).

Right. That's how I would interperate it.

Post by Heiko Nitzsche
Indeed the Embellish approach seems to be the most compatible and reasonable.
Doing the extra conversion for 1bpp or 4bpp would have no benefit in terms
of data size but it may cause more compatibility issues with other programs.
I'm not sure why the definition for 1-7bpp should be used at all for type 3
or 11 as it provides no real benefit.

Again I agree. I have not seen any real discussion, before this one, on any
other than 8-bit monochrome TGA images.

The only reason could be some weired

Post by Heiko Nitzsche
simplification for old greyscale TGA graphics hardware which might have had
such addressing modes. For palette images it does make sense as it saves
entries in the color table. Maybe that's what it is designed for.
For the final GBM TGA codec I'll most probably follow the Embellish approach
when writing greylevel TGA 1bpp and 4bpp files (always expand to 8bpp). For
reading I'll add support for real 1bpp and 4bpp (as described above). Because
also 1bpp and 4bpp would have a byte per pixel, I'll most probably also be
able to reuse the existing RLE decoder, so type 11 reading should be reasonable
also for 1bpp and 4bpp.

Thank you for your efforts.

Regards,

Steve N.

[A.D. Fundum]

Post by Steve

Post by Heiko Nitzsche
Indeed the Embellish approach seems to be the most compatible and reasonable.

Having seen GBM's latest TGA files (some files in the WPI archive are
one hour older than existing files, ed.), it works and it makes sense.
The only complaint could be the waste of bytes, but that never was an
issue regarding GBM and ignores possible nett RLE gains.

Post by Steve
I have not seen any real discussion, before this one, on
any other than 8-bit monochrome TGA images.

The reason this specific, so-called discussion started was because GBM
produced an error message instead of a file, while the TGA file format
does support black&white images. It's not impossible to save such a
file (with any number of bpps). GBM now works good, it's output makes
sense.

If people like you are the ones to go by, because of having read real
discussions, those people may have missed that all verified resources
mention, or don't exclude, e.g. 1bpp w.r.t type 3. Several of those
resources are a few decades old, and just looking for a 1bpp file
format revealed a few (possible) issues. Most;likely it says a lot
about the quality of the discussions you had to read. Can you, instead
of referring to unknown "real discussions", explain why a black&white
file has to be saved as a bytemap with a file format that supports
1bpp? That'll be more interesting if you want to start a discussion
(albeit I may not join it, OS/2 implementations now work good enough,
e.g. GBM no longer displays the earlier error message).


--

[A.D. Fundum]

GBM's implementation of color images also matches "common" TGA/2 file
formats, albeit I haven't verified the size of the small color table.
Depending on released new versions, the OS/2 implementations are more
consistantly. It seems most developers are avoiding issues
(excellent!): the fact that a 1bpp b&w image can be read doesn't mean
that a 8bpp b&w image cannot exist.

I may have claimed that I'm going to support reading all bpps in the
range 1-8. But of course I'll limit that to 1, 2, 4 and 8, based on
several references. Reading the TGA file also allows for more
flexibility than writing such a 1 bpp file, because writing a 1bpp
file can (!) cause issues. Just trying to read such a file introduces
less problems.


--

[A.D. Fundum]

There's much software (even if commandline driven)
to convert between image formats.

BTW: speaking of image formats and *nix, I've noticed you didn't
include your earlier ITECAD *.ICO files with your latest port of
ITECAD.

Even if the effort is near meaningless, I think it's a good idea to
OS/2'ify ports. For example(s) by including icons, preferably with the
same name as the EXE, and by removing unneeded directories like a
"/os2/" in a directory structure (unless removing those is an unfair
PITA). I'ld recommended to add those icon files to ports, certainly if
that's a matter of a lazy screenshot or an image conversion.


--

[mentoruccio]

 > There's much software (even if commandline driven)
 > to convert between image formats.
BTW: speaking of image formats and *nix, I've noticed you didn't
include your earlier ITECAD *.ICO files with your latest port of
ITECAD.
Even if the effort is near meaningless, I think it's a good idea to
OS/2'ify ports. For example(s) by including icons, preferably with the
same name as the EXE, and by removing unneeded directories like a
"/os2/" in a directory structure (unless removing those is an unfair
PITA). I'ld recommended to add those icon files to ports, certainly if
that's a matter of a lazy screenshot or an image conversion.

Hm. I see your point and agree... I've been kind of sloppy in this
regard. FTR, in porting IteCad I made the wrong assumption, simply
associating the .ICO file to the OS/2 executable and leaving it to the
WPS to display the program icon. I must admit it's the lazy way :) I
will correct it on the next IteCad version, modifying
the .pro / .rc / .ico files.

I'm porting other QT based software, so I will pay more attention to
this issue. Thanks a lot :)

Mentore

[Steve]

Post by A.D. Fundum
FTR: IMHO it's a GBM bug, since the "Save as..." TGA file format does
seem to support a black-and-white image, i.e. 1bpp. The GBM Editor

Hi,

In the TGA format the "Black and White" format is an
8-bit monochrome image. The document describing
the file format specifies that a pixel must be an integer
value of bytes. So, a feature, not a bug.

Regards,

Steve N.

[A.D. Fundum]

The document describing the file format specifies
that a pixel must be an integer value of bytes. So,
a feature, not a bug.

I'm afraid it's still a bug (or a quick&dirty
one-size-fits-all-solution), because the bytemap (a) doesn't use the
1bpp header, and (b) it adds a color table to the file. It explains
the situation, but it doesn't justify it, the bytemap file is larger
than needed and the assumed number of colors (8) is wrong.

I don't want to support colors (b). But I have to support colors just
to check if it's actually a 1bpp bitmap (a). If I want to support
colors in the first place, the situation is reversed and it would look
like a(n unreliable, readers still require a true 1bpp algorithm)
"feature" indeed.

Please note GBM doesn't "save as ..." the 1bpp PCX source file at all,
so it's not using the "feature", and there's an error message claiming
that TGA doesn't support 1bpp files. The TGA file format supports 1bpp
files, not to mention the "feature".


--

[A.D. Fundum]

The document describing the file format specifies
that a pixel must be an integer value of bytes. So,
a feature, not a bug.

FTR: there's OS/2 software producing TGA bitmaps (NConvert, 1 bit per
pixel) and TGA bytemaps (Embellish, 1 byte per pixel).


--

[Peter Brown]

Hi

Post by A.D. Fundum
Is there an OS/2 app which can write 1bpp or black&white TGA files,
i.e. the third byte of the created TGA file equals 3 or 11?
PMView doesn't save another 1bpp file (1BPP.PCX) as a 1bpp TGA file.
GBM's editor claims that the output "file format doesn't support this
bits per pixel", even if the original 1bpp 1BPP.PCX file is
"converted"/mapped to a 1bpp file.
Untested one-liner showing the value of the first three bytes,
assuming a 1bpp file called "X.TGA". The second byte has to be 0 (no
color map), the third byte has to be 3 or 11.
REXXTRY f='X.TGA';DO 3;SAY C2D(CharIn(f,,1));END
Please note both black and white may be a color and PMView uses a
color map (second byte is 1), but 1bpp should ignore such an issue.
And 3 or 11 does imply a "black-and-white image" anyway.
FTR: IMHO it's a GBM bug, since the "Save as..." TGA file format does
seem to support a black-and-white image, i.e. 1bpp. The GBM Editor
assumes a "map" of 8bpp. And it's maybe a PMView bug, it doesn't save
a 1bpp black-and-white PCX source file as a 1bpp black-and-white TGA
file. Instead PMView uses a color map. Hence the question, are there
GA graphical OS/2 apps capable of properly saving a 1bpp
black-and-white TGA file: second byte 0, third byte 3 or 11?
--

I don't know but suspect nconvert may be able to. I can only suggest you
download and give it a try
http://www.xnview.com/en/download_nc.html

Regards

Pete

[A.D. Fundum]

Post by Peter Brown
I don't know but suspect nconvert may be able to.
I can only suggest you download and give it a try
http://www.xnview.com/en/download_nc.html

What you suspect is right. NConvert saves a 1bpp PCX source file as a
1bpp (not 1Bpp!) TGA file, but it doesn't use RLE:

nconvert -out tga test.pcx

But using NConvert has no use in this specific case. Because I would
be able to support PCX _xor_ TGA instead of both file formats, and
it's assumed the user already has the conversion tool... ;-)

The second byte of NConvert's file is 0 (no color map), and the third
byte is 3 (black-and-white, no RLE, albeit the original file format
uses RLE). The output file is a 1bpp bitmap, it isn't a 1Bpp bytemap
(39440 pixels, 4930 data bytes and 18 header bytes).


--

[A.D. Fundum]

Post by A.D. Fundum
Is there an OS/2 app which can write 1bpp or black&white TGA
files, i.e. the third byte of the created TGA file equals 3 or 11?

Is there an OS/2 app which can write 1bpp (or 1Bpp) TGA files using
RLE encoding, i..e the third byte of the created TGA file equals 11?


--

[Heiko Nitzsche]

Post by A.D. Fundum
Is there an OS/2 app which can write 1bpp or black&white TGA files,
i.e. the third byte of the created TGA file equals 3 or 11?
PMView doesn't save another 1bpp file (1BPP.PCX) as a 1bpp TGA file.
GBM's editor claims that the output "file format doesn't support this
bits per pixel", even if the original 1bpp 1BPP.PCX file is
"converted"/mapped to a 1bpp file.
Untested one-liner showing the value of the first three bytes,
assuming a 1bpp file called "X.TGA". The second byte has to be 0 (no
color map), the third byte has to be 3 or 11.
REXXTRY f='X.TGA';DO 3;SAY C2D(CharIn(f,,1));END
Please note both black and white may be a color and PMView uses a
color map (second byte is 1), but 1bpp should ignore such an issue.
And 3 or 11 does imply a "black-and-white image" anyway.

No, according to the spec also grayscale images (e.g 4bpp or 8bpp) may
be type 3 or 11. But I also found that almost no image viewer is able
to read them. PmView and XnView/nconvert at least read 8bpp graylevel
variant, XnView/nconvert also 1bpp BW.

Post by A.D. Fundum
FTR: IMHO it's a GBM bug, since the "Save as..." TGA file format does
seem to support a black-and-white image, i.e. 1bpp.

Latest official GBM simply does not support 1bpp TGAs, this is also
documented. The error message is standard error message for all
unsupported (often mean simply not implemented) image formats or
color depths. There are simply too many image formats and subformats
around. No bitmap editor or viewer will support all of them ever.

Post by A.D. Fundum
Instead PMView uses a color map. Hence the question, are there
GA graphical OS/2 apps capable of properly saving a 1bpp
black-and-white TGA file: second byte 0, third byte 3 or 11?

I was following the discussion here and also was contacted by someone
(potentially the initial poster?) regarding the missing TGA 1bpp support.
I spent some time on TGA codec in GBM and it now supports 1,4 and 8bpp
grayscale images with type 3 (read/write). So when saving a black&white
PCX file as TGA a type 3 TGA file without palette is written. Though
to make this work it has to be ensured that the source image really is
grayscale. If it's not fully clear, mapping it with gbmbpp is the way
to go:

gbmbpp -m bw src1bpp.pcx dst1bpp_bw.tga
gbmbpp -m 4g src4bpp.pcx dst4bpp_gray.tga
gbmbpp -m 8g src8bpp.pcx dst8bpp_gray.tga

The enhanced TGA codec still only writes uncompressed images (no RLE)
and because of time contraints it probably will for a longer time,
if not ever.

If want give the new GBM a try, get it here:
http://heikon.home.tlink.de/temp/gbm175b_gbmv159.zip

It is still a beta, so please don't distribute it widely. If you find any
bugs in the new TGA codec, please let me know. I've also included an updated
GBMV2 in the package, so you can have a look at the online help for the new
options and the description of supported formats.

[Heiko Nitzsche]

As I just figured out, the TGA spec seems to request the use of
a full byte per pixel (see other post). The current beta GBM
implementation does use less than a byte for 1bpp and 4bpp images.

While the byte spec seems to be a huge waste of memory for 1bpp
and even for 4bpp images, I might have to rework the beta GBM
implementation to follow the standard (which is a bit fuzzy).

[A.D. Fundum]

Post by Heiko Nitzsche
While the byte spec seems to be a huge waste of memory for
1bpp and even for 4bpp images, I might have to rework the
beta GBM implementation to follow the standard (which is a
bit fuzzy).

FTR: read all formats, save 8-16-24-32 color depths? That way you'll
support all reasonable formats, while you avoid getting in trouble
foir creating unreadable files (PMView avoids type 3).

FTR/2: an ancient book about TGA files reads "Bits_per_pixel is the
number of bits per pixel in the image data, usually 8, 16, 24, or 32.
Usually. USUALLY. It also reads "Each pixel is stored as one to four
bytes. The pixel format depends on the image type (what about
USUALLY?! ed.). The pixel size is given in the Bits_per_pixel field in
the file header.".

I think I'm going to support all color depths upto and including 8bpp,
assuming all other settings match that (I won't check the variable
file size, too much effort). But I'm in read-only (!) mode.

An implied conversion of a 1bpp file to a file 8bpp waists bytes, but
it's safe in case "usually" is not accurate, and "one to four bytes"
covers 8bpp too.


--

[A.D. Fundum]

Post by Heiko Nitzsche

Post by A.D. Fundum
And 3 or 11 does imply a "black-and-white image" anyway.

No, according to the spec also grayscale images (e.g 4bpp or
8bpp) may be type 3 or 11.

Right, sorry.

Even is type 3 is called "black-and-white", it supports those greys. I
should have used "greyscale" instead of quotes.

Or I should have written that if the type is 3, no color map is in
use, and the number of bits per pixel according to the header is 1,
it's a black-and-white image.

It's clear now that "black-and-white" may mean greyscale, some
descriptions are wrong there. You CAN use 8bpp there.

Post by Heiko Nitzsche
But I also found that almost no image viewer is able
to read them.

Maybe Embellish, which saves 1bpp TGA files.

Post by Heiko Nitzsche
Latest official GBM simply does not support 1bpp TGAs, this is
also documented.

FTR: the file can be saved. If needed, a bit-to-byte-conversion
warning (that you'll have to use 8bpp instead of the original 1bpp)
would be better than the current (documented) error message.

Post by Heiko Nitzsche
was contacted by someone (potentially the initial poster?)

Guilty.

Post by Heiko Nitzsche
http://heikon.home.tlink.de/temp/gbm175b_gbmv159.zip
It is still a beta, so please don't distribute it widely.

--