Dealing with new 0-1 color range
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
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: 3468
- 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:
or if you prefer to just convert the value to whole numbers again:
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
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.
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: 3468
- 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.
Re: Dealing with new 0-1 color range
OK, let's hope such a function arrives at some point. Thanks for the reply.
Re: Dealing with new 0-1 color range
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).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
Code: Select all
function WHY(float) return math.floor(float*255+0.5) end
- Pebsie
- Party member
- Posts: 144
- 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? :'(
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.
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.
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.
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.
- 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
Re: Dealing with new 0-1 color range
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: No registered users and 13 guests