Dealing with new 0-1 color range

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
mr_happy
Citizen
Posts: 67
Joined: Fri Mar 18, 2016 8:57 pm

Dealing with new 0-1 color range

Post by mr_happy » Wed Apr 11, 2018 10:05 am

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?

User avatar
zorg
Party member
Posts: 2202
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Dealing with new 0-1 color range

Post by zorg » Wed Apr 11, 2018 10:17 am

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

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
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

User avatar
mr_happy
Citizen
Posts: 67
Joined: Fri Mar 18, 2016 8:57 pm

Re: Dealing with new 0-1 color range

Post by mr_happy » Wed Apr 11, 2018 10:38 am

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...

User avatar
zorg
Party member
Posts: 2202
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Dealing with new 0-1 color range

Post by zorg » Wed Apr 11, 2018 11:20 am

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.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

User avatar
mr_happy
Citizen
Posts: 67
Joined: Fri Mar 18, 2016 8:57 pm

Re: Dealing with new 0-1 color range

Post by mr_happy » Wed Apr 11, 2018 11:30 am

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

User avatar
pgimeno
Party member
Posts: 1008
Joined: Sun Oct 18, 2015 2:58 pm

Re: Dealing with new 0-1 color range

Post by pgimeno » Wed Apr 11, 2018 4:15 pm

zorg wrote:
Wed Apr 11, 2018 10:17 am
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
Party member
Posts: 114
Joined: Mon Nov 11, 2013 12:35 am
Location: Lincoln, United Kingdom
Contact:

Re: Dealing with new 0-1 color range

Post by Pebsie » Tue Apr 17, 2018 9:24 am

Shader related? So there's no chance that it's going to get reverted back to 0 to 255? :'(
Website: http://peb.si
Twitter: @Pebsiee http://twitter.com/pebsiee
Steam: pebsie

User avatar
raidho36
Party member
Posts: 1642
Joined: Mon Jun 17, 2013 12:00 pm

Re: Dealing with new 0-1 color range

Post by raidho36 » Tue Apr 17, 2018 10:37 am

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.
Last edited by raidho36 on Tue Apr 17, 2018 10:43 am, edited 1 time in total.

grump
Party member
Posts: 297
Joined: Sat Jul 22, 2017 7:43 pm

Re: Dealing with new 0-1 color range

Post by grump » Tue Apr 17, 2018 10:42 am

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.

User avatar
Dr. Peeps
Citizen
Posts: 57
Joined: Sat May 28, 2016 12:57 am
Location: British Columbia, Canada

Re: Dealing with new 0-1 color range

Post by Dr. Peeps » Tue Apr 17, 2018 8:01 pm

raidho36 wrote:
Tue Apr 17, 2018 10:37 am
...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.

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests