Mirror of forum.nim-lang.org

2648 :: Best way to represent pixel data in Nim

• def_pri_pub (orginal) [2016-12-05T02:36:59+01:00] view original

  I want to work on a stb_image wrapper. I'm trying to figure out the best (and most efficient) way of storing pixel data in Nim's data structures.

  stb_image stores the pixel data in an unsigned char * type. I had a chat with the person who wrote the nimPNG package and he says that using Nim's string would be a good container. But when I was working with stb_image in Nim (for another project) I was using a seq[uint8] type (thread link here, final mini-wrapper here. Which one would be better to work with?

---

• Arrrrrrrrr (orginal) [2016-12-05T10:27:56+01:00] view original

  strings and seq[uint8] are almost identical. For some reason strings are more popular when it comes to stream bytes. But at any rate, i think you will find no advantages in one over the other.

---

• Krux02 (orginal) [2016-12-06T16:45:16+01:00] view original

  There is a huge difference between seq[uint8] and string, and that is what people expect the type is for. People expect strings to be contain text, and text only. People expect that a string contains only valid codes for letters, as well as they expect that the string ends on a 0. People also know that strings can contain multibyte characters, so indexing into a string is not really the best idea. seq[uint8] is a sequence of 8 bit unsigned integers, indexing is ok, but each component is an 8 bit integer in the range 0..255. seq[byte] can be any data, the usage has not yet been decided. seq[tuple[r,g,b,a: uint8]]: now people actually expect each element in the seq to be a pixel with 32 bit per pixel including an 8 bit alpha channel.

---