New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How can I load an (sRGB-)image in HSV-color space? #14
Comments
This isn't really code I am familiar with (whilst we now maintain imager, we obviously didn't write much of the code base, and do not use all of its functionality). That said- from what I can see the display function expects images to be in a RGB colour space, and sRGB is just close enough that visually it still looks reasonable. So, I don't think there is actually a bug here, it is just being used incorrectly when trying ti directly display HSV. That's my quick assessment- I might be wrong. The display function itself is pretty low level (Cimg itself) so any bugs there should be communicated to the Cimg team (since we just use their header for imager). |
Although now I realise I cannot even display the images like this on my Mac version. It complains I don't have the X11 package installed (which I don't, but that isn't needed anymore and isn't available for R now). How did you get round that? |
I don't have an x11-package installed either. Are there any additional potential packages that might be at play here? However, bear in mind that at least the github-source of the package lists Line 25 in 6586883
Which bears the question of how I am satisfying this dep; because I sure don't recall setting it up - nor can I find it anywhere ¯\_(ツ)_/¯ I have created a small R-project that reproduces the issue on my end. Additionally, it contains the image in question - just in case that uploading to and downloading from a github-issue alters it (it shouldn't, but I've seen weirder shit). All packages installed during installation of |
In that case, a couple of things:
im <- imager::load.image(path)
im_srgb_to_rgb <- imager::sRGBtoRGB(im)
im_rgb_to_hsv <- imager::RGBtoHSV(im_srgb_to_rgb) (disregarding the small info-loss between srgb and rgb?). Does
|
I don't think the issue is in the load, but rather the display- that function only meaningfully displays RBG data. Again, this is just from having a cursory look at the lower level calls being made- the display itself is really handled by the Cimg library not imager. |
@Gewerd-Strauss what @asgr says seems to be right to me too. You are giving HSV values to I think it's safe to trust the HSV data. Given how the underlying CImg library is used so widely in many products, and this being is one of the core functions that the library would perform, you'd expect it to perform it correctly. If you want to double-check you can compare a couple of individual HSV pixel values in Alternatively you can alter the HSV values in a meaningful way, the display the HSV->RGB result and check that it makes sense. For example, you do |
Without getting into the colour space conversion issue (you might need to raise questions there with Cimg directly), the jpeg I inspect is identical between imager::load and jpeg::readJPEG. Note readJPEG uses a different structure where the x/y dimensions are swapped (neither is wrong, since matrices we display matrices in a transposed sense anyway). test_imager = imager::load.image('~/Downloads/309751145-e22f4886-1473-4925-977e-86dbbe5ab1db.jpg') test_base = readJPEG('~/Downloads/309751145-e22f4886-1473-4925-977e-86dbbe5ab1db.jpg') readJPEG does warn that other programs flip the ink scales. There are also many ways other programs might remap RGB (for reasons of dynamic range). Both imager::load and jpeg::readJPEG access the raw data as encoded in the file. |
@Gewerd-Strauss I think your coordinates are also wrong? The arbitrary pixel with RGB = (46, 125, 96) is not (2674,3872) but (2686, 3881) (0-indexed). When reading the image as read by > im[2687,3882,1,]
[1] 0.1803922 0.4901961 0.3764706 which is the RGB value you expect. Regarding the display, while I'm not completely sure, I'm half-guessing that Like @asgr says, I don't see an issue here. |
After a good amount of fiddling and more reading, I have successfully resolved the "issue", and will thus close this issue. |
Hello,
I am quite confused about how to control which color-space
imager::load.image()
loads images, or rather about how to properly convert them to a desired color-space.Assume the attached jpg-image is loaded via
imager
:Original
sRGB
-Image on disc, saved as 'example.jpg':Image as loaded and displayed via
imager::display(im)
(subset):Image after srgb2rgb:
Image after rgb2hsv:
This obviously does not seem to be right - at least to my eyes; the first transformation from SRGB to RGB works properly.
However, then converting to HSV results in the mess we see above. This also occures if we convert the loaded
im
directly to HSV. Note thatimager::spectrum(im)
returns 3, so the originally loaded images does have 3 channels. I would assume that therefore I should be able to convert SRGB > RGB > HSL.What exactly am I missing?
Any help is welcome.
Thank you.
Sincerely,
~Gw
As background, I must detect yellow & green pixels within comparable images; and from my understanding I'd much rather do so in HSV-color space than in RGB, because color-detection in RGB is rather annoying.
So the actual question really is how I can load an image as HSV as resource-efficient as possible, without apparently nuking the image?
The text was updated successfully, but these errors were encountered: