The argument of which produces the better quality is pointless. You can produce the same quality with integers as you can with floating points as long as you use a sufficient amount of bits for your maths. One can use integers to implement floating points and it is a common practise on hardware that has no float point operations.
If you do not know how to use integers efficiently then you will need to use float points, of course. It is what floating points were designed for as these take care of precision issues through a non-fixed, floating representation so that you do not have to.
The argument between integer versus floating points, however, is still about speed. Integer operations are often faster, because they can use less bits and they allow you to trade quality for speed in addition.
I suggest that you use floating points. The speed difference between integers and floating points is often not huge, especially when instruction sets like SSE can be used and most compilers will try to use these automatically. Writing, debugging and maintaining precise integer code on the other hand is more difficult and as a result are integers mostly used when quality is not an issue.
I saw omp > used my brain. I removed openmp option while configuring and the program compiles and runs perfectly.
I just wanted to know if this is indeed the right way to compile a libraw program.
Thanks and Regards.
Sorry, but the method you are trying to use is wrong. Please have a look at how it is accomplished in, say, Fuji S5. You need to replace noisy and blown pixels altogether. There is no point in mixing good with bad.
If you are smart, do it on per channel basis.
Finally, you may want to check if you understand white balance well enough. Raw without white balance application looks green, search for UniWB.
Well, looks like the greens that appear are those of the raw nature of the files, I mean:
If I catch any raw file, and modify the values of all cells ('or pixels') such as multiplying by a value less than 1, it appears greenish around the resulting raw file. All this before demosaicing.
I have a suspicion it's because in a raw, there are 2 green cells for each cell red and blue.
Anyone can confirm me this?
Can you lower the brightness of a raw without the appearance of these greens, or what is the same I can multiply by something less than 1 without getting this effect?
Unfortunately, KDE/digiKam has moved to git repsitory, so I'm unable to find right place to point to.
Try to download entire digiKam source distribution (e.g. from here: http://www.digikam.org/drupal/download) and find .h file with extensions list (rawfiles.h or so).
Thanks for reply.
I've need this list to filter files that could be opened by libraw in my application.
And official raw camera use official extension (cr2,crw, ...).
There is no such list in LibRaw distribution, because LibRaw does not rely on file extension.
You may use list from digiKam distribution, although it may be incomplete.
For example, some cameraw write .tif or .tiff files, adding this extension to list is not good idea in general case.
No zeroes.. but why my cuestion ? Because, long ago, I was debugging the raw-demosaicing to tiff process into dcraw, and I could see these zeroes into memory, but of course, these zeroes are not in the raw file.
Thanks already so far. But there are reasons I *want* to delete LibRaw (partly architectural, partly to get rid of as many unnecessary resources as possible).
So I would like to understand if I can get somehow the image data without copying (i.e. take over the pointer ownership) ?
Or , alternatively, is there a call that frees all allocated data, except for the image ?
The argument of which produces the better quality is pointless. You can produce the same quality with integers as you can with floating points as long as you use a sufficient amount of bits for your maths. One can use integers to implement floating points and it is a common practise on hardware that has no float point operations.
If you do not know how to use integers efficiently then you will need to use float points, of course. It is what floating points were designed for as these take care of precision issues through a non-fixed, floating representation so that you do not have to.
The argument between integer versus floating points, however, is still about speed. Integer operations are often faster, because they can use less bits and they allow you to trade quality for speed in addition.
I suggest that you use floating points. The speed difference between integers and floating points is often not huge, especially when instruction sets like SSE can be used and most compilers will try to use these automatically. Writing, debugging and maintaining precise integer code on the other hand is more difficult and as a result are integers mostly used when quality is not an issue.
peterdk, do you can show(or upload) you config.sub and configure? thanks!
What camera do you use?
You may set output_color field of processing parameters structure to 0 to get raw color
I saw omp > used my brain. I removed openmp option while configuring and the program compiles and runs perfectly.
I just wanted to know if this is indeed the right way to compile a libraw program.
Thanks and Regards.
To get linear and balanced (not green) data, you need to
1) subtract black level from raw data
2) apply white balance
Ummm, let's me think about that...
RFC[] are calculate using: (for 3 images, sorted by exposition, lower exposition first, and so ... )
RFC[0]= 1.0 always
RFC[1]= SUM_A / SUM_B * RFC[0]
RFC[2]= SUM_B / SUM_C * RFC[1]
SUM_A is R,G1 and B from image 0
SUM_B is the same from image 1
SUM_C is the same from image 2
Then this must be refact so RFC[0] + RFC[1] + RFC[0] = 1.0 ?
Sorry, but the method you are trying to use is wrong. Please have a look at how it is accomplished in, say, Fuji S5. You need to replace noisy and blown pixels altogether. There is no point in mixing good with bad.
If you are smart, do it on per channel basis.
Finally, you may want to check if you understand white balance well enough. Raw without white balance application looks green, search for UniWB.
1) You do your calculations before white balance procedure, or after that?
2) What WB method is used
Yes, m1 = 1 - m2. But drFC1*m1 + drFC2*m2 will generally not being equal to 1.0
Thanks, lexa.
I do this when is it a mixed pixel.
// It's a mix pixel from various images gray16_pixel1 = *vct_gray16ViewSrc_iterator[i-1]; gray16_pixel2 = *vct_gray16ViewSrc_iterator[i]; drFC1 = vectorRFC[i-1]; drFC2 = vectorRFC[i]; m2 = static_cast<double>(*dbl_vct_it) - static_cast<double>( i ); m1 = static_cast<double>(1) - m2; mul1 = drFC1 * m1; mul2 = drFC2 * m2; gray16_pixel1 = gray16_pixel_t(round( static_cast<double>(gray16_pixel1) * mul1 + static_cast<double>(gray16_pixel2) * mul2 ) );If you look m1 and m2 they are weight compensed to 1 in a cell. see m1= 1 - m2
Sorry, when you talk about 'pixel' ... it is a cell, like 'R' or is it about four cell like the group(R,G1,B,G2) ?
NOTE: I use gray16_pixel_t because are simple values, from 0 to 65535 and dont have components (like red,green,blue)
Well, looks like the greens that appear are those of the raw nature of the files, I mean:
If I catch any raw file, and modify the values of all cells ('or pixels') such as multiplying by a value less than 1, it appears greenish around the resulting raw file. All this before demosaicing.
I have a suspicion it's because in a raw, there are 2 green cells for each cell red and blue.
Anyone can confirm me this?
Can you lower the brightness of a raw without the appearance of these greens, or what is the same I can multiply by something less than 1 without getting this effect?
Thank you.
I guess, for correct output you need to have sum of weight factors equal to 1.0 in each pixel
thanks
You can start with list from digiKam sources.
Unfortunately, KDE/digiKam has moved to git repsitory, so I'm unable to find right place to point to.
Try to download entire digiKam source distribution (e.g. from here: http://www.digikam.org/drupal/download) and find .h file with extensions list (rawfiles.h or so).
Thanks for reply.
I've need this list to filter files that could be opened by libraw in my application.
And official raw camera use official extension (cr2,crw, ...).
LibRaw does not contains complete color library.
You may consider use of lcms2 and try to set Lab as output profile.
There is no such list in LibRaw distribution, because LibRaw does not rely on file extension.
You may use list from digiKam distribution, although it may be incomplete.
For example, some cameraw write .tif or .tiff files, adding this extension to list is not good idea in general case.
Yes:
1) the imgdata.image[] (constructed by raw2image() call) have 4 components per pixel and only one non-zero component
2) the rawdata.raw_image have only one non-zero component per pixel
Ok, thanks, Lexa
No zeroes.. but why my cuestion ? Because, long ago, I was debugging the raw-demosaicing to tiff process into dcraw, and I could see these zeroes into memory, but of course, these zeroes are not in the raw file.
No, there are no such call.
No, channel maximum is absolute value, you dont need to add maximum.
For the whitelevel can I then assume that the
whitelevel
Alex,
Thanks already so far. But there are reasons I *want* to delete LibRaw (partly architectural, partly to get rid of as many unnecessary resources as possible).
So I would like to understand if I can get somehow the image data without copying (i.e. take over the pointer ownership) ?
Or , alternatively, is there a call that frees all allocated data, except for the image ?
Jos
You don't need to delete LibRawProcessor (if you plan to process another image).
There are two calls:
LibRaw::free_image() - frees image[] array. You may call raw2image() again and you'll get another image[] allocated.
LibRaw::recycle() - frees all allocated data for file (it will be called automatically on next open_file())
Pages