Replies: 4 comments 2 replies
-
I'm fairly sure that 0x30 is actually "0", and that 0x33 is "3", as shown in hexed.it here: |
Beta Was this translation helpful? Give feedback.
-
PS might prompt you to write ".\main.exe" in place of "main.exe". After 12 hours I finally realized I was writing it with the double quotes. Please don't be like me and take things too literally. |
Beta Was this translation helpful? Give feedback.
-
there maybe some encoding problem. if you find the file is right but can`t open the .ppm picture, you might to check the file encoding, I has this problem and use the windows api |
Beta Was this translation helpful? Give feedback.
-
noob question but was anyone able to solve this issue with another method? I followed the post, as well as all the comments |
Beta Was this translation helpful? Give feedback.
-
(See issue #636 for more context.)
Several readers have reported problems with invalid PPM files generated from their raytracers on Windows. The short answer is that there are several ways to have text files output as UTF-16, or even UTF-16 with a leading BOM, which is unrecognized by most PPM readers.
If your PPM file shows as invalid, view the hex contents of the file and verify that the first bytes are 0x50, 0x30 ("P3"), and the next two should be either 0x0d 0x0a (CRLF), or just 0x0a (LF). If not, your build or run environment is probably outputting Unicode text as either UTF-16 or UTF-16 with a leading BOM. The BOM will appear as either 0xFE, 0xFF, or 0xFF, 0xFE. For example, one reader was generating the following bytes in their PPM output:
In either event, you'll need to figure out how to configure your project to output ASCII or UTF-8.
See issue #636 for discussion on this topic. Both readers reported that the problem manifested when using PowerShell. To resolve it, there were two options:
PS: C:\raytracing\main\Release> main.exe | set-content image.ppm -encoding String
Beta Was this translation helpful? Give feedback.
All reactions