## 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
mr_happy
Citizen
Posts: 83
Joined: Fri Mar 18, 2016 8:57 pm

### Dealing with new 0-1 color range

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
Party member
Posts: 2484
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: Dealing with new 0-1 color range

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
Me and my stuff True 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.

mr_happy
Citizen
Posts: 83
Joined: Fri Mar 18, 2016 8:57 pm

### Re: Dealing with new 0-1 color range

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
Party member
Posts: 2484
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: Dealing with new 0-1 color range

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

mr_happy
Citizen
Posts: 83
Joined: Fri Mar 18, 2016 8:57 pm

### Re: Dealing with new 0-1 color range

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

pgimeno
Party member
Posts: 1442
Joined: Sun Oct 18, 2015 2:58 pm

### Re: Dealing with new 0-1 color range

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
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My NotABug.org repositories - portland (mobile orientation)
The MS-Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

Pebsie
Party member
Posts: 137
Joined: Mon Nov 11, 2013 12:35 am
Location: Lincoln, United Kingdom
Contact:

### Re: Dealing with new 0-1 color range

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

raidho36
Party member
Posts: 1685
Joined: Mon Jun 17, 2013 12:00 pm

### Re: Dealing with new 0-1 color range

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: 471
Joined: Sat Jul 22, 2017 7:43 pm

### Re: Dealing with new 0-1 color range

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
Citizen
Posts: 57
Joined: Sat May 28, 2016 12:57 am

### Re: Dealing with new 0-1 color range

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.

### Who is online

Users browsing this forum: Bing [Bot] and 3 guests