Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Vadim Pisarevsky <vadim.pisarevsky-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
Subject: Re: potential gamma bug present in OpenCV
Newsgroups: gmane.comp.lib.opencv.devel
Date: Monday 1st March 2010 12:33:51 UTC (over 6 years ago)
Hi,

Well, I'm strongly against such automatic gamma handling. And I would not
call the current implementation buggy. Many basic image processing
functions
in OpenCV can handle 16-bit, even 32-bit floating-point images, so we can
accurately represent scenes with a very wide dynamic range using gamma=1. I
do not mind if cvCvtColor (some of the conversions) will be extended to
support gamma, optionally. cvShowImage, cvSaveImage, cvLoadImage can be
extended too. But the other processing functions should process data as-is.
If the function is called cvAdd, it should do C = A + B, not C =
(((A/255)**(1/2.2) + (B/255)**(1/2.2))**2.2)*255. We just can not afford
it,
cpu-clock-wise and programming+debugging-time-wise. I myself never ever got
into this problem with gamma; I've seen only one such case in my practice,
on MacOSX, where the image codecs apply the gamma automatically - so we got
different results in different OSes. After we switched to libjpeg on
MacOSX,
the problem was eliminated completely.

Regards,
Vadim

On Mon, Mar 1, 2010 at 8:27 AM, Guy K. Kloss
<[email protected]> wrote:

> Hi,
>
> I'm presuming that OpenCV suffers from the same type of bug. I have NOT
> verified it, but extrapolating from colour handling in other places
within
> OpenCV lets me assume that image scaling, smoothing, etc. do not take
into
> account any influence of a gamma coefficient.
>
> This should be something that can be fixed easily, by adding a default
> gamma=2.2 parameter to some functions, that a user can override upon
need.
> It
> would be better than using no gamma correction *at all*.
>
> One may just now also argue in one of two ways *against* this:
>
>  * If all other software operates with this bug, why should we care to
>   introduce an incompatibility?
>
>  * Undoing a gamma correction before the operation, and adding it
> afterwards
>   again adds computational overhead that wasn't in there before (and
makes
>   OpenCV slightly slower than the previous version).
>
> However, I think it would be a worthwhile undertaking to add this
> correction
> to the code base (in case the bug is in OpenCV as well), to be rather
> correct
> than just make the same mistake the likes of PhotoShop are making.
>
> Any comments?
>
> Guy
>
> ----------  Forwarded Message  ----------
>
> Subject: [Image-SIG] gamma bug present in PIL 1.1.7
> Date: Mon, 01 Mar 2010, 16:44:20
> From: Bill Janssen <[email protected]>
> To: "[email protected]"

>
> The gamma bug detailed in http://www.4p8.com/eric.brasseur/gamma.html
> appears to be present in PIL 1.1.7.
>
> Bill
> _______________________________________________
> Image-SIG maillist  -  [email protected]
> http://mail.python.org/mailman/listinfo/image-sig
>
> -----------------------------------------
> --
> Guy K. Kloss
> Institute of Information and Mathematical Sciences
> Te Kura Pūtaiao o Mōhiohio me Pāngarau
> Massey University, Albany (North Shore City, Auckland)
> 473 State Highway 17, Gate 1, Mailroom, Quad B Building
> voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
> [email protected] http://www.massey.ac.nz/~gkloss
>
>
>
------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Opencvlibrary-devel mailing list
> [email protected].org
> https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
>
>
 
CD: 3ms