[sane-devel] constrain value related query
stef.dev at free.fr
Sun Aug 4 07:32:13 UTC 2013
On 02/08/2013 19:39, viresh wrote:
> On Wednesday 17 July 2013 07:17 AM, m. allan noah wrote:
>> I can confirm your findings- i think this is a bug in
>> On Tue, Jul 16, 2013 at 8:46 PM, Bureau <viresh_shirol at yahoo.co.uk>
>>> Hi all,
>>> During my backend testing efforts with tstbackend.c frontend that is
>>> available in the distribution ,I observed an issue in the
>>> sanei_constrain_value function.
>>> The details are as below.
>>> 1)I believe the specifications for SANE_Range are simple enough and
>>> there are no further rules on the values for min,max and quant members.
>>> 2)assuming #1 above is correct, my observation is that the
>>> constrain_value function returns values that are greater than the
>>> max specified for the range.
>>> 3)I am assuming that #2 item is either unknown or known but not
>>> fixed/valid scenario.
>>> 4)the issue
>>> the issue happens for constraint type RANGE when following
>>> condition is satisfied
>>> (max-min)%quant >=(quant/2)
>>> value to be set >=max
>>> Cause:Due to rounding done using quant/2 value,the final value put
>>> in array[i] overshoots the max value by at the max quant/2 units.
>>> 5>Why this is an issue for me
>>> for few reasons
>>> a)I blindly believed the value returned by constrain_value is
>>> actually constrained to the max. By this assumption,I did not have
>>> to check the values everywhere for their constraint-wise-correctness.
>>> b)the machine that I am writing the backend for seems to take tl br
>>> values in mm and seems to do some kind of validation using which it
>>> decides the actual scan size.So offset of value/s for tl br options
>>> would lead to heavy offsets when large resolution scan is done.
>>> c)the issue is very dominant,I believe,when the range type is
>>> SANE_Fixed. Note that in this case the quant value is sufficiently
>>> large leading to larger offsets.
>>> 6)Solutions possible
>>> a)temporary fix can just check whether the adjusted value is larger
>>> than Max for the range and set it to either max or one quant level
>>> Also,I can temporarily fix it in a local function.
>>> b)not very sure but If the rounding via quant/2 is removed we can
>>> safely say that the value is always safe. I think it's a subjective
>>> item and can not discuss further but I think flooring isn't that bad.
>>> 7)My test values(sorry to put them at the end)
>>> max=SANE_FIX(431.8);//ledger width
>>> quant=SANE_FIX(0.01);//tried .1,1.0 too
>>> value to be set (actually the issue was found when testing with
>>> tstbkend.c fronted) is 431.8. (or more ...as constrain value reduces
>>> it to max in that case)
>>> Query:how do I proceed with this?My main question is "am I doing
>>> something wrong??"
>>> this is my first post.I wanna thank you all and especially the ones
>>> who have authored the tstbackend frontend.Also,please note that I
>>> may ve wrong in using fractional quant values etc but i think there
>>> was no limitation w.r.t. in the spec. I apologize in advance if
>>> anyone feels any sentence in this post seems to show impoliteness in
>>> any way. ...I am newbie/noob u knw!!!!
>>> Thanks and regards,
>>> Sent from my iPhone
>>> sane-devel mailing list: sane-devel at lists.alioth.debian.org
>>> Unsubscribe: Send mail with subject "unsubscribe your_password"
>>> to sane-devel-request at lists.alioth.debian.org
> Hi Allan,
> Thanks for the quick response that day. And I am sorry for the late
> reply from my side.
> I am attaching the updated code based on the temporary solutions that
> I had mentioned in my original mail.
> I am not sure if this is the correct procedure to send the updated
> code but I am new to git as well.
> Also I believe newbies like me can not update the code tree directly
> Could you please review and include the changes in the next release?
> Please note that the changes in my backend code were external to
> i.e. though the logic was same as the attached file, the patch was
> external to constrain_value function.
> Apart from this, I would like to know if I could help the efforts in
> any way. I dont have any hardware to test any backends etc but I have
> some experience with opencv-v4l configuration which I think can be
> helpful in improving the v4l backend. (At least the man page says it
> is not so stable)
> Also as a plus point w.r.t scanners ,I have some 3+ years of
> experience on multi functional peripherals controller development(for
> one of the brands which do not have a sane backend of their own yet)
> which included work on UI to middleware.
> Let me know if I can be of any help in any way.
> Viresh M.Shirol
> P.S: rather large comment for 1 if block addition in the code but I
> think it explains why the changes were done clearly.
I have commit the fix in git tree. I have also added test cases in
sanei_constrain_test.c which detected the problem before fix, and are
now 'passing' with the fix.
I don't think there is a better way to change this. Since sane
'fixed' values are float values multiplied by 65536, there will be
always rounding issues. For instance the SANE_Range you used resolved to
min=0, max=28298444 and quant=655, so min+k*quant will always be
different from max.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sane-devel