Hi!
> Yes, I think that how you describe luminance and lightness is right,
> and sounds good improve the doc.
>
> To be clear the correction table for PWM values can be calculated with
> this code.
>
> OUTPUT_SIZE = 65535 # Output integer size
> INPUT_SIZE = 2047
>
> def cie1931(L):
> L = L*100.0
> if L <= 8:
> return (L/902.3)
> else:
> return ((L+16.0)/116.0)**3
>
> x = range(0,int(INPUT_SIZE+1))
> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
Can we just generate the table on the fly? Should not be hard to do in
fixed point, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Pavel,
2017-12-15 21:57 GMT+01:00 Pavel Machek <[email protected]>:
> Hi!
>
>> Yes, I think that how you describe luminance and lightness is right,
>> and sounds good improve the doc.
>>
>> To be clear the correction table for PWM values can be calculated with
>> this code.
>>
>> OUTPUT_SIZE = 65535 # Output integer size
>> INPUT_SIZE = 2047
>>
>> def cie1931(L):
>> L = L*100.0
>> if L <= 8:
>> return (L/902.3)
>> else:
>> return ((L+16.0)/116.0)**3
>>
>> x = range(0,int(INPUT_SIZE+1))
>> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
>
> Can we just generate the table on the fly? Should not be hard to do in
> fixed point, right?
This was discussed a bit in previous RFC which had the code to
generate the table on the fly, see [1]. The use of a fixed table or an
on the fly table is something that I'll let the maintainers to decide.
I've no strong opinion on use the on the fly table if someone takes
care to review deeply the fixed point maths :)
[1] https://lkml.org/lkml/2017/9/4/335
Regards,
Enric
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2017-12-18 11:40:59, Enric Balletbo Serra wrote:
> Hi Pavel,
>
> 2017-12-15 21:57 GMT+01:00 Pavel Machek <[email protected]>:
> > Hi!
> >
> >> Yes, I think that how you describe luminance and lightness is right,
> >> and sounds good improve the doc.
> >>
> >> To be clear the correction table for PWM values can be calculated with
> >> this code.
> >>
> >> OUTPUT_SIZE = 65535 # Output integer size
> >> INPUT_SIZE = 2047
> >>
> >> def cie1931(L):
> >> L = L*100.0
> >> if L <= 8:
> >> return (L/902.3)
> >> else:
> >> return ((L+16.0)/116.0)**3
> >>
> >> x = range(0,int(INPUT_SIZE+1))
> >> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
> >
> > Can we just generate the table on the fly? Should not be hard to do in
> > fixed point, right?
>
> This was discussed a bit in previous RFC which had the code to
> generate the table on the fly, see [1]. The use of a fixed table or an
> on the fly table is something that I'll let the maintainers to decide.
> I've no strong opinion on use the on the fly table if someone takes
> care to review deeply the fixed point maths :)
You are free to pre-compute the table at boot. And you can even
compare the built-in and pre-computed table at boot, to make sure you
made no mistakes :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Dec 18, 2017 at 11:40:59AM +0100, Enric Balletbo Serra wrote:
> Hi Pavel,
>
> 2017-12-15 21:57 GMT+01:00 Pavel Machek <[email protected]>:
> > Hi!
> >
> >> Yes, I think that how you describe luminance and lightness is right,
> >> and sounds good improve the doc.
> >>
> >> To be clear the correction table for PWM values can be calculated with
> >> this code.
> >>
> >> OUTPUT_SIZE = 65535 # Output integer size
> >> INPUT_SIZE = 2047
> >>
> >> def cie1931(L):
> >> L = L*100.0
> >> if L <= 8:
> >> return (L/902.3)
> >> else:
> >> return ((L+16.0)/116.0)**3
> >>
> >> x = range(0,int(INPUT_SIZE+1))
> >> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
> >
> > Can we just generate the table on the fly? Should not be hard to do in
> > fixed point, right?
>
> This was discussed a bit in previous RFC which had the code to
> generate the table on the fly, see [1]. The use of a fixed table or an
> on the fly table is something that I'll let the maintainers to decide.
> I've no strong opinion on use the on the fly table if someone takes
> care to review deeply the fixed point maths :)
The last time we discussed this we concluded we would introduce linear
interpolation to make it easier enlarge the small tables we typically
see in devicetree.
Having done that it seemed attractive (at least to me) to reuse any
interpolation code we get and then simply provide a "sane" default look
up table for use by DT authors who don't really know how to map PWM on/
off times to luminance.
I did review the original fixed point code for the first RFC. IIRC some
of the low level functions *looked* they could overflow but, on closer
inspection, were never actually overflowed in practice due to the
number ranges used by the callers. To be honest part of the attraction
of a LUT instead was that I wouldn't have to closely review nor ensure
all the fixed point code was properly commented ;-) .
The other item in favour of LUT was that (as Doug A. pointed out) PWM
duty-cycle to luminance is not strictly linear. Whilst at the moment I
am OK to discount this effect it is possible we might want to combined
the luminance to human perception values with values read out from
graphs in a datasheet.
Enric: Having said all that I don't want to give you a really heavy
handed steer here. If you think the code was cleaner or clearer
when using the formulae then I'd be happy to review the fixed
point code.
Daniel.