{"id":9,"date":"2026-11-12T20:24:17","date_gmt":"2026-11-12T20:24:17","guid":{"rendered":"https:\/\/blog.metu.edu.tr\/e160477\/?p=9"},"modified":"2026-11-12T20:24:17","modified_gmt":"2026-11-12T20:24:17","slug":"ceng-587-hw1-comparing-debevec-malik-and-mitsunaga-nayar","status":"publish","type":"post","link":"https:\/\/blog.metu.edu.tr\/e160477\/2026\/11\/12\/ceng-587-hw1-comparing-debevec-malik-and-mitsunaga-nayar\/","title":{"rendered":"CENG 587 HW1: Comparing Debevec & Malik and Mitsunaga & Nayar"},"content":{"rendered":"

<\/h2>\n
\n
This work is about comparing two algorithms of generating HDR image. To generate HDR image different exposed images are combined. A camera creates images by converting real light and exposure time into digital level via non linear function which is called the camera response function (CRF):<\/div>\n<\/div>\n

Z = f(E \u00b7 \u0394t)<\/p>\n

\n
Then to form HDR image from different exposed images, one needs to know the CRF to inverse the process and obtain the light value for each pixel.<\/div>\n<\/div>\n

In this homework I compared two methods that find f\u207b\u00b9 from photos taken with different exposure times:<\/p>\n

    \n
  • Debevec & Malik (1997):<\/strong> It does not assume a formula for the curve. It finds all 256 values of g = ln f\u207b\u00b9 by solving one big linear system. There is a smoothness term with a weight \u03bb, so the curve does not become noisy. It needs the exposure times.<\/li>\n
  • Mitsunaga & Nayar (1999):<\/strong> It assumes f\u207b\u00b9 is a polynomial of order N. It only needs to find N+1 coefficients, so it is fast. It can also estimate the exposure ratios, so the exact exposure times are not necessary.<\/li>\n<\/ul>\n

    <\/h2>\n

    I chose Option 2<\/strong>. I compared two algorithms<\/strong>. For Debevec & Malik I used two different implementations and for Mitsunaga & Nayar one, so there are three versions in total:<\/p>\n\n\n\n\n\n\n\n
    Name<\/th>\nAlgorithm<\/th>\nSource<\/th>\n<\/tr>\n<\/thead>\n
    Debevec (OpenCV)<\/td>\nDebevec & Malik<\/td>\nOpenCV cv2.createCalibrateDebevec<\/code> (70 samples, \u03bb = 10)<\/td>\n<\/tr>\n
    Debevec (Piccante)<\/td>\nDebevec & Malik<\/td>\nPiccante HDR library (github.com\/banterle\/piccante), function gsolve<\/code>, converted from C++ to Python with the help of an AI assistant (256 samples, \u03bb = 20)<\/td>\n<\/tr>\n
    Mitsunaga (Piccante)<\/td>\nMitsunaga & Nayar<\/td>\nPiccante, function MitsunagaNayarClassic<\/code>, converted from C++ to Python with the help of an AI assistant (order N chosen from 1\u20133)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    I checked the Python versions by testing them on images with a known response curve (the virtual camera), and they recovered the correct curve.<\/p>\n

    Some details:
    \n– Sample selection.<\/strong> The Piccante versions choose sample pixels with histograms (the Grossberg\u2013Nayar idea): the brightness order of the pixels is the same in every photo, so the same percentile belongs to the same scene point. OpenCV picks 70 random pixel positions instead.
    \n– Same merging for all.<\/strong> I merged every curve to an HDR image with the same OpenCV function (MergeDebevec<\/code>) and tone mapped it with the same operator (Reinhard). So the differences in the results come only from the curves.
    \n– My computer:<\/strong> MacBook Air, Apple M4 chip, 24 GB RAM, Python 3.9, NumPy 2.0, OpenCV 5.0.<\/p>\n

    Metrics<\/h3>\n
      \n
    • log-RMSE:<\/strong> used when the true curve is known (virtual camera). It is the difference between my curve and the true curve in log scale. Lower is better.<\/li>\n
    • Consistency error (in stops):<\/strong> used for real cameras, because there the true curve is unknown. If the curve is correct, every photo gives the same light value for the same pixel. I measure how much these values change between photos. 1 stop = 2 times. Lower is better.<\/li>\n<\/ul>\n

      Problems<\/h2>\n
        \n
      1. The first code I found did not work.<\/strong> I first tried the VFX_HDR repository from GitHub. It did not run on my computer: first OpenCV was missing, and the code also uses np.warnings<\/code>, which does not exist in new NumPy versions. Its Debevec also uses only 25 pixels, so the curve is not accurate. I decided to use the Piccante library and OpenCV instead.<\/li>\n
      2. Setting up Python.<\/strong> The system Python on my Mac did not have OpenCV. I created a virtual environment (python3 -m venv .venv<\/code>) and installed the packages with pip install -r requirements.txt<\/code>.<\/li>\n
      3. Wrong EXIF times on the Nikon D2H.<\/strong> See Section 6.2. Because of this, I used “exposure doubles every photo” for all course sequences, as the readme says.<\/li>\n<\/ol>\n

        Virtual camera (true curve is known)<\/h2>\n

        The virtual camera images were rendered with the Radiance renderer, and we know their response: srgb<\/code>, linear<\/code>, and noise25\/50\/100\/150<\/code> (sRGB with more and more noise).<\/p>\n

        \"\"<\/p>\n

        \"\"<\/p>\n\n\n\n\n\n\n
        log-RMSE<\/th>\nDebevec (OpenCV)<\/th>\nDebevec (Piccante)<\/th>\nMitsunaga (Piccante)<\/th>\n<\/tr>\n<\/thead>\n
        sRGB camera<\/td>\n0.0239<\/td>\n0.0068<\/strong><\/td>\n0.0124<\/td>\n<\/tr>\n
        linear camera<\/td>\n0.0241<\/td>\n0.0057<\/td>\n0.0027<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
          \n
        • All three versions find the sRGB curve.<\/strong> Piccante’s Debevec is the closest. OpenCV’s Debevec is good until about z = 240 and then goes up, because its 70 random samples have very few bright pixels.<\/li>\n
        • For the linear camera, Mitsunaga is the best.<\/strong> A linear curve is exactly a polynomial of order 1, so the model fits it perfectly.<\/li>\n<\/ul>\n

          Effect of noise<\/h3>\n

          \"\"<\/p>\n\n\n\n\n\n\n\n\n\n
          log-RMSE<\/th>\nDebevec (OpenCV)<\/th>\nDebevec (Piccante)<\/th>\nMitsunaga (Piccante)<\/th>\n<\/tr>\n<\/thead>\n
          no noise<\/td>\n0.024<\/td>\n0.007<\/strong><\/td>\n0.012<\/td>\n<\/tr>\n
          noise 25<\/td>\n0.064<\/td>\n0.010<\/strong><\/td>\n0.019<\/td>\n<\/tr>\n
          noise 50<\/td>\n0.100<\/td>\n0.019<\/strong><\/td>\n0.092<\/td>\n<\/tr>\n
          noise 100<\/td>\n0.132<\/td>\n0.045<\/strong><\/td>\n0.543<\/td>\n<\/tr>\n
          noise 150<\/td>\n0.145<\/td>\n0.070<\/strong><\/td>\n0.626<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          Debevec gets worse slowly when the noise increases, because the smoothness term keeps the curve smooth. Mitsunaga breaks after noise 50\u2013100: noisy dark pixels pull the polynomial below zero. (I assume the noise sequences have the same sRGB response. The small errors at low noise support this.)<\/p>\n

          Effect of the parameters<\/h2>\n

          \"\"<\/p>\n

          Debevec \u2013 \u03bb and number of samples<\/strong>
          \n– Small \u03bb (1) lets the noise into the curve. Big \u03bb (100 or more) makes the curve too flat at the ends. Good values were \u03bb = 5\u201320<\/strong> for clean data and \u03bb = 20\u201350<\/strong> for the noisy phone images.
          \n– More samples helped OpenCV a lot (50 \u2192 200). Piccante was already good with fewer samples, thanks to the histogram sampling.
          \n– More samples make Debevec slower, because the linear system gets bigger.<\/p>\n

          Mitsunaga \u2013 polynomial order N<\/strong>
          \n– N = 1\u20132 is too simple and N = 3 was the best. Higher orders (N \u2265 4) gave much worse curves, so the automatic selection between 1 and 3 is a good choice.
          \n– Estimating the exposure ratios gave almost the same result as using the real ratios. The method really does not need exact exposure times when the data is clean.<\/p>\n

          Real cameras<\/h2>\n

          \u00a0Sample sequences<\/h3>\n

          All four sequences were run with “exposure doubles every photo” and resized to 1600 pixels.<\/p>\n\n\n\n\n\n\n\n\n
          Consistency error (stops)<\/th>\nDebevec (OpenCV)<\/th>\nDebevec (Piccante)<\/th>\nMitsunaga (Piccante)<\/th>\n<\/tr>\n<\/thead>\n
          Canon EOS 550D<\/td>\n0.168<\/td>\n0.167<\/strong><\/td>\n2.288<\/td>\n<\/tr>\n
          Minolta DiMAGE A1<\/td>\n0.129<\/td>\n0.126<\/strong><\/td>\n2.053<\/td>\n<\/tr>\n
          Nikon Coolpix E5400<\/td>\n0.095<\/td>\n0.092<\/strong><\/td>\n1.398<\/td>\n<\/tr>\n
          Nikon D2H<\/td>\n0.110<\/td>\n0.107<\/strong><\/td>\n0.161<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          \"\"<\/p>\n

            \n
          • The two Debevec versions give almost the same curve for every camera.<\/li>\n
          • Mitsunaga looks fine in the linear plot, but in the log plot it is almost zero below z \u2248 15. So dark pixels get almost no light, and the consistency error becomes very big.<\/li>\n<\/ul>\n

            6.2 Nikon D2H: wrong EXIF times<\/h3>\n

            The EXIF data of the D2H says 1\/400, 1\/320, 1\/200, 1\/160, 1\/100, 1\/80, 1\/40, 1\/20, 1\/10 s. The ratios between them are 1.25 and 1.6, but the images clearly get 2 times brighter every time, as the readme says. With the EXIF times, Debevec’s error was 0.259 stops; with doubling it was 0.107. So the EXIF times were wrong, and doubling was the right choice.<\/p>\n

            7. My phone’s response curve<\/h2>\n
              \n
            • Phone:<\/strong> Samsung Galaxy S20 FE<\/li>\n
            • How I captured:<\/strong>\u00a0 Samsung camera app, Pro mode, JPEG. ISO 500, white balance and focus fixed. I only changed the shutter speed: 1\/30, 1\/20, 1\/10, 1\/6, 1\/4, 1\/2, 1, 2, 4, 10 s (10 photos).<\/li>\n
            • Scene:<\/strong> In the 10 s photo 84% of the pixels are saturated, in the 1\/30 s photo almost none. So all pixel values from 0 to 255 are used.<\/li>\n<\/ul>\n

              \"\"<\/p>\n\n\n\n\n\n
              Consistency error (stops)<\/th>\nDebevec (OpenCV)<\/th>\nDebevec (Piccante)<\/th>\nMitsunaga (Piccante)<\/th>\n<\/tr>\n<\/thead>\n
              Samsung S20 FE<\/td>\n0.129<\/td>\n0.128<\/strong><\/td>\n0.771<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

              – The two Debevec versions are almost the same, so I take this as my phone’s curve.
              \n– My phone’s curve is not sRGB.<\/strong> When I fit a power function, the exponent is about 1.4 (blue), 1.6 (green) and 1.5 (red). For sRGB it is about 2.2. The phone’s curve is flatter in the middle and bends quickly near 255. I think this is because the phone applies its own tone mapping.
              \n– The blue channel is the hardest.<\/strong> The lamp light is orange, so blue values are low and noisy, and the curve has small steps.
              \n– Mitsunaga failed on the phone.<\/strong> It chose N = 2, the curve went below zero for dark values, and the HDR image got a purple color.<\/p>\n\n\n\n\n\n
              Debevec (Piccante)<\/th>\nMitsunaga (Piccante)<\/th>\n<\/tr>\n<\/thead>\n
              \n

              \"\"<\/p>\n<\/td>\n

              		\n

              \"\"<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

              8. Running times<\/h2>\n

               <\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
              Sequence<\/th>\nImages<\/th>\nSize<\/th>\nDebevec (OpenCV)<\/th>\nDebevec (Piccante)<\/th>\nMitsunaga (Piccante)<\/th>\n<\/tr>\n<\/thead>\n
              Virtual camera sRGB<\/td>\n9<\/td>\n1024\u00d71024<\/td>\n26 ms<\/td>\n168 ms<\/td>\n69 ms<\/td>\n<\/tr>\n
              Virtual camera linear<\/td>\n7<\/td>\n1024\u00d71024<\/td>\n24 ms<\/td>\n149 ms<\/td>\n57 ms<\/td>\n<\/tr>\n
              Virtual camera noise25<\/td>\n9<\/td>\n1024\u00d71024<\/td>\n27 ms<\/td>\n157 ms<\/td>\n59 ms<\/td>\n<\/tr>\n
              Virtual camera noise50<\/td>\n9<\/td>\n1024\u00d71024<\/td>\n26 ms<\/td>\n152 ms<\/td>\n54 ms<\/td>\n<\/tr>\n
              Virtual camera noise100<\/td>\n9<\/td>\n1024\u00d71024<\/td>\n27 ms<\/td>\n169 ms<\/td>\n52 ms<\/td>\n<\/tr>\n
              Virtual camera noise150<\/td>\n9<\/td>\n1024\u00d71024<\/td>\n27 ms<\/td>\n155 ms<\/td>\n53 ms<\/td>\n<\/tr>\n
              Canon EOS 550D<\/td>\n9<\/td>\n1600\u00d71067<\/td>\n28 ms<\/td>\n213 ms<\/td>\n113 ms<\/td>\n<\/tr>\n
              Minolta DiMAGE A1<\/td>\n13<\/td>\n1600\u00d71200<\/td>\n28 ms<\/td>\n304 ms<\/td>\n175 ms<\/td>\n<\/tr>\n
              Nikon Coolpix E5400<\/td>\n16<\/td>\n1600\u00d71200<\/td>\n31 ms<\/td>\n389 ms<\/td>\n244 ms<\/td>\n<\/tr>\n
              Nikon D2H<\/td>\n9<\/td>\n1600\u00d71060<\/td>\n27 ms<\/td>\n206 ms<\/td>\n108 ms<\/td>\n<\/tr>\n
              Samsung S20 FE (my phone)<\/td>\n10<\/td>\n1200\u00d71600<\/td>\n29 ms<\/td>\n244 ms<\/td>\n145 ms<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

              Times are the median of 3 runs on a MacBook Air (Apple M4, 24 GB RAM), only for finding the curve.
              \n– Debevec (OpenCV)<\/strong> is fast because it uses only 70 samples.
              \n– Debevec (Piccante)<\/strong> is the slowest: 256 samples make a big linear system.
              \n– Mitsunaga<\/strong> solves a very small system. Most of its time goes to making the histograms, so it gets slower with more and bigger images.<\/p>\n

              9. Conclusion<\/h2>\n
                \n
              • With clean data, both algorithms find the true curve. Mitsunaga is the best for the linear camera and it is fast.<\/li>\n
              • Noise makes the difference.<\/strong> Debevec stays good with noise. Mitsunaga breaks with medium and high noise.<\/li>\n
              • On all real cameras and my phone, Debevec was the most reliable.<\/strong> One polynomial cannot follow the dark part of real camera curves well.<\/li>\n
              • Sample selection matters.<\/strong> OpenCV and Piccante solve the same Debevec equations, but the results are a bit different because of the samples.<\/li>\n
              • EXIF times can be wrong (Nikon D2H).<\/li>\n
              • My Samsung S20 FE does not have an sRGB curve. Its curve is flatter, with an exponent of about 1.5.<\/li>\n<\/ul>\n

                Use of AI:<\/strong> I used an AI assistant (Claude) to convert the Piccante code to Python, help of AI is used for\u00a0 writing the comparison scripts I took the phone photos, ran all experiments on my own computer, checked the results and edited the post.<\/p>\n

                References<\/h2>\n
                  \n
                1. P. Debevec, J. Malik, “Recovering High Dynamic Range Radiance Maps from Photographs”, SIGGRAPH 1997.<\/li>\n
                2. T. Mitsunaga, S. K. Nayar, “Radiometric Self Calibration”, CVPR 1999.<\/li>\n
                3. F. Banterle et al., Piccante HDR library, https:\/\/github.com\/banterle\/piccante<\/li>\n
                4. OpenCV documentation, https:\/\/docs.opencv.org<\/li>\n
                5. M. Grossberg, S. Nayar, “What can be known about the radiometric response from images?”, ECCV 2002.<\/li>\n
                6. E. Reinhard et al., “Photographic Tone Reproduction for Digital Images”, SIGGRAPH 2002.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

                  This work is about comparing two algorithms of generating HDR image. To generate HDR image different exposed images are combined. A camera creates images by converting real light and exposure time into digital level via non linear function which is called the camera response function (CRF): Z = f(E \u00b7 \u0394t) Then to form HDR […]<\/p>\n","protected":false},"author":9678,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[1],"tags":[],"class_list":["post-9","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/posts\/9","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/users\/9678"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/comments?post=9"}],"version-history":[{"count":0,"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/posts\/9\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/media?parent=9"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/categories?post=9"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.metu.edu.tr\/e160477\/wp-json\/wp\/v2\/tags?post=9"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}