I updated to the latest and see the same artifact. Is the thumbnail processed properly for you? No additional steps necessary to handle it as opposed to other bitmap thumbnail formats (which work for me)?
Some kodak files are very special in respect of thumbnails:
- the thumbnails are actually RAW data
-unpack_thumb() process them
- thumbnail.tformat is BITMAP for these images, not JPEG
Also, LibRaw 0.17 (alpha) has fixed several bugs relates to kodak thumbs.
So,
- upgrade to 0.17 (or Github master branch)
- ensure, that you handle thumbnail.tformat right
I've made the tests for OpenMP with the model 1 (which is the model that I use most often).
I never use model 0 because it makes the accuracy of tracked displacement worse; and never go after model 3.
I understand that fallback to AHD is automatic when 'libraw can not do otherwise'.
But my question was about the value stored by user_qual after dcraw_process.
I've made this test: set user_qual to 18 (to be sure to activate the fallback to AHD), call of dcraw_process, and then display the value of user_qual which were still 18. So, is there a solution to know if the fallback has actually happened?
Yes, fallback to AHD (user_qual=3) is explicitly stated in docs:
===
Values 5-9 are useful only if "LibRaw demosaic pack GPL2" compiled in (see README.demosaic-packs in your distribution for details). Value 10 is useful only if LibRaw compiled with "LibRaw demosaic pack GPL3". If some interpolation method is unsupported because LibRaw compiled without corresponding demosaic pack, AHD interpolation will be used without any notice.
=== http://www.libraw.org/docs/API-datastruct-eng.html#libraw_output_params_t
Right! I've made my tests too quickly.
Is user_qual set to 3 by libraw if the user set it to 9 for example (without additional demoniac packs)?
Anyway, it is now clear. Thank you very much for answering.
If you build libraw *without* additional 'demosaic packs', then interpolations from 5 to 10 are not compiled in (and library will fallback to user_qual=3, AHD interpolation)
OpenMP accelerated are:
ppg interpolation (user_qual = 2) and AHD (user_qual=3)
Yes, 'model 1' means 'iProcessor.imgdata.params.user_qual = 1' in my question.
Thank you for replying, it's good to know (I didn't find this information in the documentation).
After some rapid tests, it appears indeed that 'only' the interpolations 5 to 9 are OpenMP accelerated.
Thank you again!
Hi, I just found out I forgot to respond, so I'm gonna do it now and try to remember where the problem was and what was the solution. :)
In the end it was (as it usually is with the stuff you're learning to use) my own fault (that much I remeber).
I'm not sure if it was because I was setting the values of gama etc. before LibRaw::unpack() or had error in build settings causing the new code to be built elsewhere and was always running the old project. (Or maybe both, so many things happen when you're trying to figure something out :))
Well, both would be nice to know about. The situation has changed for me since asking this question :) Right now color profile could help me a bit more.
Calculated temperature *will* differ from camera because camera and LibRaw uses different color profile (because color profile is used for xy-calculation)
The only way to check results is to compare to Adobe software (Lightroom or Camera Raw) with same color profiles (so, for example, DNG file with built-in camera matrices: ACR/Lr uses embedded color datain DNG case and LibRaw may be forced to do the same)
I've modified mem-image sample, added line:
printf("Type=%d\n",thumb->type);after the line
And, yes, mem-image -e writes thumbnail as expected (in PPM format because it it bitmap).
Also, our FastRawViewer (that uses LibRaw::unpack_thumb to extract thumbnails) works fine with these files.
I updated to the latest and see the same artifact. Is the thumbnail processed properly for you? No additional steps necessary to handle it as opposed to other bitmap thumbnail formats (which work for me)?
For both these images, thumbnail type is 2 (LIBRAW_IMAGE_BITMAP)
Checked with LibRaw 0.16 and with current (0.17) version.
I pulled these from a forum topic for testing:
http://s3t.it/data/uploads/rt_kodak_dcs_14nx_raw_photodesk.zip
It should work.
Could you please provide some file(s) for testing (Dropbox or google drive is a good way for file sharing)
Currently I'm checking:
libraw_processed_image_t *image = rawProcessor->dcraw_make_mem_thumb(&result);
...
bool isJpeg = image->type == LIBRAW_IMAGE_JPEG;
This doesn't work for kodak?
Some kodak files are very special in respect of thumbnails:
- the thumbnails are actually RAW data
-unpack_thumb() process them
- thumbnail.tformat is BITMAP for these images, not JPEG
Also, LibRaw 0.17 (alpha) has fixed several bugs relates to kodak thumbs.
So,
- upgrade to 0.17 (or Github master branch)
- ensure, that you handle thumbnail.tformat right
I've made the tests for OpenMP with the model 1 (which is the model that I use most often).
I never use model 0 because it makes the accuracy of tracked displacement worse; and never go after model 3.
Thanks :)
Good question :)
I'll add bits to imgdata.process_warning field in coming LibRaw 0.17
I understand that fallback to AHD is automatic when 'libraw can not do otherwise'.
But my question was about the value stored by user_qual after dcraw_process.
I've made this test: set user_qual to 18 (to be sure to activate the fallback to AHD), call of dcraw_process, and then display the value of user_qual which were still 18. So, is there a solution to know if the fallback has actually happened?
LibRaw's dcraw_process() call is mostly identical to dcraw's processing.
Highlight recovery is applied after white balance and demosaic
Yes, fallback to AHD (user_qual=3) is explicitly stated in docs:
===
Values 5-9 are useful only if "LibRaw demosaic pack GPL2" compiled in (see README.demosaic-packs in your distribution for details). Value 10 is useful only if LibRaw compiled with "LibRaw demosaic pack GPL3". If some interpolation method is unsupported because LibRaw compiled without corresponding demosaic pack, AHD interpolation will be used without any notice.
===
http://www.libraw.org/docs/API-datastruct-eng.html#libraw_output_params_t
Right! I've made my tests too quickly.
Is user_qual set to 3 by libraw if the user set it to 9 for example (without additional demoniac packs)?
Anyway, it is now clear. Thank you very much for answering.
If you build libraw *without* additional 'demosaic packs', then interpolations from 5 to 10 are not compiled in (and library will fallback to user_qual=3, AHD interpolation)
OpenMP accelerated are:
ppg interpolation (user_qual = 2) and AHD (user_qual=3)
Yes, 'model 1' means 'iProcessor.imgdata.params.user_qual = 1' in my question.
Thank you for replying, it's good to know (I didn't find this information in the documentation).
After some rapid tests, it appears indeed that 'only' the interpolations 5 to 9 are OpenMP accelerated.
Thank you again!
'model 1' is 'VNG interpolation', right? This interpolation is not OpenMP accelerated in LibRaw.
Libraw contains several demosaic methods. Which one do you use?
The camera to sRGB matrix is in imgdata.color.rgb_cam[3][4] array.
This is 'device link'profile, you may multiply this matrix to another one (e.g. srgb to Adobe RGB) to get different output color space.
Hi, I just found out I forgot to respond, so I'm gonna do it now and try to remember where the problem was and what was the solution. :)
In the end it was (as it usually is with the stuff you're learning to use) my own fault (that much I remeber).
I'm not sure if it was because I was setting the values of gama etc. before LibRaw::unpack() or had error in build settings causing the new code to be built elsewhere and was always running the old project. (Or maybe both, so many things happen when you're trying to figure something out :))
Well, both would be nice to know about. The situation has changed for me since asking this question :) Right now color profile could help me a bit more.
Calculated temperature *will* differ from camera because camera and LibRaw uses different color profile (because color profile is used for xy-calculation)
The only way to check results is to compare to Adobe software (Lightroom or Camera Raw) with same color profiles (so, for example, DNG file with built-in camera matrices: ACR/Lr uses embedded color datain DNG case and LibRaw may be forced to do the same)
Thank for reply.
I looked to DNG SDK but I am not able move cam_mul[] to DNG SDK required parameters dng_xy_coord. Calculated temperature is different than on camera.
What is right way how convert cam_mul to xy or XYZ?
Thank you
Ladislav
You may use code from Adobe DNG SDK sources.
For bayer image, use imgdata.rawdata.raw_image array to access unprocessed values decoded from raw file
Pages