0

I get weird results when displaying a PPM:

pixeldisplay

(this is actually an upscaled PNG)

And here's what the file looks like:

textdisplay

The dimensions are fine (10 rows, 8 columns), just the colors are wrong (or am I wrong?).

As it says in the 3rd line of the file, I want to use a value from 0 to 255 per channel. Using an usual rgb color space like (255, 255, 255) for white, (0, 0, 0) for black, (255, 0, 0) for red and so on. But those colors in the image are apparently not the same as in the file.

Already at the first look, the image seems way to dark.

Do I misunderstand the format? Is the file not interpretated this way?

Rbt
  • 3
  • 2
  • 1
    Please post the actual data, rather than a picture of it. It's only ASCII text after all. – Mark Setchell May 27 '20 at 16:02
  • What software did you use to make the image from the data? – Mark Setchell May 27 '20 at 16:03
  • Thanks for the answers so far. @Mark Setchell, what do you mean by "actual data", the 2nd file is what I see when opening it in a non-image-editor? – Rbt May 27 '20 at 19:02
  • @Mark Setchell: the image was produced using Krita, but looks the same in Gimp or ImageGlass. – Rbt May 27 '20 at 19:04
  • 1
    It's a PNG image, not a text file. Try loding the PNG file into a TEXT EDITOR and selecting the `255`. You can't because it's pixels not numbers. – Mark Setchell May 27 '20 at 19:09

1 Answers1

0

This document: http://netpbm.sourceforge.net/doc/ppm.html describes the PPM image format.

When the "magic" value P6 is found at the beginning of the file, the color of the pixels is stored as binary data. Quoting the previously mentioned document (emphasis mine):

[...] A raster of Height rows, in order from top to bottom. Each row consists of Width pixels, in order from left to right. Each pixel is a triplet of red, green, and blue samples, in that order. Each sample is represented in pure binary by either 1 or 2 bytes. If the Maxval is less than 256, it is 1 byte. Otherwise, it is 2 bytes. The most significant byte is first.

The file showed by the asker seems to contain their decimal textual representation instead.

So, the string "\n224 93 229..." (yes, I suspect the windows endline sequence "\r\n") is interpreted as (assuming that the file was saved in ASCII format) {10, 50, 50}, {50, 32, 32}, {57, 51, 32}, ....

Note the blackish pixel in the middle, which probably correspond to the end of the first line, it may be a {13, 10, 32} ("\r\n ").

If you change the magic value to P3, it should be interpreted correctly.

Bob__
  • 12,361
  • 3
  • 28
  • 42
  • thanks for that, that solved it. Just for completness I played a bit around to get the P6-binary version working as well. I got colors, but never the ones I expected. What would a color look like in the binary version? – Rbt May 27 '20 at 19:40
  • @Rbt How do you write those files? Are you using [write](https://en.cppreference.com/w/cpp/io/basic_ostream/write)? – Bob__ May 27 '20 at 19:48
  • Not exactly, I used std::ofstream and: file << a_fully_formated_image_string; – Rbt May 27 '20 at 19:56
  • @Rbt See e.g. https://stackoverflow.com/questions/28896001/read-write-to-ppm-image-file-c or https://stackoverflow.com/questions/41589811/trying-to-write-a-ppm-image-in-c – Bob__ May 27 '20 at 19:57
  • @Rbt If you are performing a single call to write a single huge string into the file, the numbers representing the color values in this string shouldn't be formatted as text (e.g. "200 128 04"), but you have to put the actual value (e.g. str[i] = 200; str[i + 1]= 128...). – Bob__ May 27 '20 at 20:00