Dealing with new 0-1 color range

[mr_happy]

How do I detect pixels in an image which are set to, say, (128, 0, 0, 0) in a paint program when newImageData:getPixel doesn't return 0.5 for the red component?

[zorg]

Would be nice to have :getRawPixel that returns bytes/shorts/whatever, basically integers, huh?

If 255 is 1, then 128/255 is around 0.50196078431 whereas 129/255 is about 0.50588235294...
the differences between values is in the neighbourhood of 0.0039 or 0.004 (1/255) so you could check this with an appropriately horrid one-liner function:

Code: Select all

function why(float, int) return math.abs(float - (int/255)) < 0.004 end

or if you prefer to just convert the value to whole numbers again:

Code: Select all

function WHY(float) return math.floor(float*255) end

[mr_happy]

Yes, I was hoping there was some other way I'd missed. The change to 0-1 means expensive extra code for such a simple operation and makes it much harder to visualize colours when you've been working with 0-255 since the year dot! I can't see the logic for changing, unless it's shader related...

[zorg]

It is shader related. Also, it's not really too expensive, but if internally it's converted to the nearest integer anyway (which i'm assuming), there really should be a function to get that raw value, and not convert to and from a double prec. float.

[mr_happy]

OK, let's hope such a function arrives at some point. Thanks for the reply.

[pgimeno]

or if you prefer to just convert the value to whole numbers again:

Code: Select all

function WHY(float) return math.floor(float*255) end

I'd recommend this approach but adding rounding (just in case default rounding falls short of an integer by just a tiny bit during the conversions).

Code: Select all

function WHY(float) return math.floor(float*255+0.5) end

[Pebsie]

Shader related? So there's no chance that it's going to get reverted back to 0 to 255? :'(

[raidho36]

No, because it means that shaders internally use 0-1 range and 0-255 is just an 8 bit integer format still commonly used for image file storage. Anyway if you need to check a color against specific value it's because you're doing something very wrong there. You must never read from GPU, only write to it.

Also, if changes are a problem to you, just don't update.

[grump]

Here's a quick hack that adds five functions to love that work with colors in the 0-255 range. I'm gonna use them while porting stuff from 0.10.2.

• love.graphics.setRawColor
• love.graphics.rawClear
• love.ImageData:getRawPixel
• love.ImageData:setRawPixel
• love.ImageData:mapRawPixel

Code: Select all

local function rgba2raw(r, g, b, a)
	return
		math.floor(r * 255 + .5),
		math.floor(g * 255 + .5),
		math.floor(b * 255 + .5),
		a and math.floor(a * 255 + .5)
end

local function color2raw(r, g, b, a)
	if type(r) == 'table' then
		r, g, b, a = unpack(r)
	end

	return rgba2raw(r, g, b, a)
end

local function raw2color(r, g, b, a)
	if type(r) == 'table' then
		r, g, b, a = unpack(r)
	end

	return r / 255, g / 255, b / 255, a and a / 255
end

local function mapRaw(fn, x, y, r, g, b, a)
	return raw2color(fn(x, y, rgba2raw(r, g, b, a)))
end

local ImageData = debug.getregistry().ImageData

function ImageData:getRawPixel(x, y)
	return color2raw(self:getPixel(x, y))
end

function ImageData:setRawPixel(x, y, r, g, b, a)
	return self:setPixel(x, y, raw2color(r, g, b, a))
end

function ImageData:mapRawPixel(fn)
	return self:mapPixel(function(x, y, r, g, b, a)
		return mapRaw(fn, x, y, r, g, b, a)
	end)
end

function love.graphics.setRawColor(r, g, b, a)
	return love.graphics.setColor(raw2color(r, g, b, a))
end

function love.graphics.rawClear(r, g, b, a, stencil, depth)
	r, g, b, a = raw2color(r, g, b, a)
	return love.graphics.clear(r, g, b, a, stencil, depth)
end

It's mostly untested though. I probably missed a function or three, and there's always room for improvement. If there is any interest from the community, I'll make a lib and put it on github.

[Dr. Peeps]

...if you need to check a color against specific value it's because you're doing something very wrong there....

I'm totally pro-normalization: 0-1 allows for any image bit depth while 0-255 is 24-bit specific and archaic, and of course it means no translation to/from shaders, etc.

But I've done a lot with integer-based image colours in the past (especially palette-based graphics in the olden days): using images as maps, where each colour means a certain terrain; using special colours in animated images that can be replaced via code (for example, a character's clothing could be "128", and this colour could then be replaced with whatever colour you wanted the character to wear); old-school colour cycling so parts of an image would look animated or pulsating; palette-based lighting effects; and so on.

Of course, an easy solution to some of these "problems" is to convert your image to a byte array upon loading, and reference it that way. But yeah, no help from the GPU there.