I’m trying to view the raw pixel values. I can get the Navigator pane to show 0-255, but can’t seem to get it to show in greater resolution. Is there any way to do this? Or is it that my images are simply only 8-bits?
On a related note, is there any way to show the color depth in the image. I see this feature request from a few years ago, but not sure whether or not it was ever implemented:
Left-click in navigator changes the display range of the vales in RT5
I can get it to cycle through 0-1, %, 0-255, but not anything higher. It’s a .CR2 image.
If you want raw pixel values, then you’re best off using dcraw -D to get unscaled raw pixel values.
The version is 5.0-r1-gtk3 running on W10. This is what I see:
You get the largest resolution (4 digits) when viewing in [0;1] range. That’s about 40x the precision of the [0;255] range you mentioned in first post.
Thank you for the help.
I’m being a bit OCD here, but I’d like to be certain that I’m getting the full depth. When I show in 0-1, casual mousing around seems to suggest that it’s scaling from 8-bits to float via value/255.0 division. For example, I can get .5607, .5648, and .5686, but can’t seem to get any intermediate values between those. Those numbers happen to be .0039 apart, and 1/255 happens to equal .0039.
I’ve uploaded an image here:
https://drive.google.com/file/d/0B_YUjY4N7ZJxVDhWS0dGRHF0ek0/view?usp=sharing
if it makes any difference.
(The image is of a Secchi disk in water colored with food coloring. We’re developing a model to map RGB values to absorbance at 440 nm. So I take a picture, then run the water through a spectrophotometer. Of course, still need to adjust for exposure.)
If nothing else, I can look through the code and try to figure out where to just add some printf’s, though I’d rather not do that at this stage. Another solution would be just manually figure out the rectangle coords of the desired region, use dcraw to dump to ASCII PPM, then write a script to average the values in the rectangle. Though, it’d be clunky.
If this is for science, I’d suggest the latter. It’s easier to review the methodology that way. You could use Matlab or Octave for the data extraction processing.
Yeah, eventually we’ll develop custom code for it, but I was hoping to just get some quick numbers to make sure that we are on the right track, especially with the model we are developing to map pixel values to absorbance. (I’ll actually probably go with Python or C++ for the extraction from PPM. I know C++ is not the right language, but I know it a lot better than anything else.)
Okay, I browsed through the code, and it’s definitely downsampling to 8-bits before it converts to float. 
void Navigator::getRGBText (int r, int g, int b, Glib::ustring &sR, Glib::ustring &sG, Glib::ustring &sB)
{
switch (currentRGBUnit) {
case (Options::NavigatorUnit::R0_1):
sR = Glib::ustring::format(std::fixed, std::setprecision(4), r / 255.f);
sG = Glib::ustring::format(std::fixed, std::setprecision(4), g / 255.f);
sB = Glib::ustring::format(std::fixed, std::setprecision(4), b / 255.f);
break;
case (Options::NavigatorUnit::R0_255):
sR = Glib::ustring::format(std::fixed, std::setprecision(0), r);
sG = Glib::ustring::format(std::fixed, std::setprecision(0), g);
sB = Glib::ustring::format(std::fixed, std::setprecision(0), b);
break;
case (Options::NavigatorUnit::PERCENT):
default:
sR = Glib::ustring::format(std::fixed, std::setprecision(1), r * 100.f / 255.f) + Glib::ustring("%");
sG = Glib::ustring::format(std::fixed, std::setprecision(1), g * 100.f / 255.f) + Glib::ustring("%");
sB = Glib::ustring::format(std::fixed, std::setprecision(1), b * 100.f / 255.f) + Glib::ustring("%");
}
}
I also found this:
guint8* pix = cropHandler.cropPixbuftrue->get_pixels() + vy * cropHandler.cropPixbuf->get_rowstride() + vx * 3;
...
pmlistener->pointerMoved (true, cropHandler.colorParams.output, cropHandler.colorParams.working, mx, my, pix[0], pix[1], pix[2]);
in cropwindow.cc, which suggests that all the UI pixels are in 8-bits. It seems to be using GTK for that, which would be why all the UI stuff is in 8 bits. Adding simple prints of the raw pixel values is going to harder than I had hoped. Ah well.
You’re right. I will look whether there is a way to show full precision raw values too.
I bet @ilias_giarimis would also be very happy
@KenC It turned out that it is quite easy to show the original raw values. I will add that to the pixelshift branch because in this branch you also can zoom to 1600%.
Cool! I’ll be on the lookout for the commit.
Having spent way longer fkn with Secchi disks than I’d like to admit, I’m curious what/why you’re doing this? (I’m an ocean engineer by training and my wife is a marine biologist - so I have to ask. 
especially after I showed this to her).
@KenC
I committed to pixelshift branch
To see the raw values you have to select Demosaic method ‘none’ and preferably also disable all preprocessing steps like auto ca-correction and so on.
Then the navigator shows the raw value after black level subtraction in the range of the original raw data.
You have to select the [0-255] range in navigator to get the raw values in full range 
Edit: I added another commit because I forgot to round instead of truncate.
Haha. We’re developing a water quality app, leveraging the camera, for volunteers, interested public, etc. Idea is to use an image of a Secchi disk, lowered part-way into the water. RGB gives us 3 values, which should allow us to map back to absorbance at the wavelengths commonly used for WQ (perhaps using some remote-sensing-like techniques, or maybe we’ll just do something like some black-box curve fitting). My background is CS, but I have some side projects, mainly with limnologists. But I’ve never taken an actual Secchi reading in my life. 
Won’t be as good as a real lab, of course, for a variety of reasons, but it’s something.
I can PM/email more if you are interested, though I can’t seem to figure out how to PM on pixls.us.
Awesome, it’ll probably be a few weeks before I get back to this, due to day job, but I’ll let you know.
