How to slice an RGB image in CIE L* ranges?
1 view (last 30 days)
Show older comments
I have created a script where I can load an RGB image, convert it to CIE Lab (easy) and 'sliced' it in discrete levels. The code is not pretty (please forgive my Matlab ignorance) but it works. Below, for example, is the slice L* = 50. Each beige circle represents a pixel from the image, I have not bothered to change the default fill color, I was just elated to be able to superimpose the circles on the diagram :
I could not show the whole code for Matlab keeps flagging my question as spam?
So I attached the m file along... As you'll see, it's grossly inefficient... With the helpf of Chris and others, I got the main diagram to show up at lighting speed.
My question : are there better / faster / simpler ways to segment an image for the pupose of displaying it on top of an existing plot?
0 Comments
Accepted Answer
DGM
on 26 Jan 2022
Edited: DGM
on 27 Jan 2022
Here's an example of some concepts. I'm just attaching the files instead of trying to paste them. The RTE is buggy and likes to explode if I paste long things and then dare to scroll.
This shows one way to reduce the Lab image to a set of binned pixel lists. This also shows a way to make the slider snap to the bin center values. Note the use of nested functions to avoid dragging around a pile of globals. The gamut image and color point scatter creation are handled in a function so that the slider CBF can update them as needed.
Is there a particular reason why you're displaying the gamut slice using scatter() and square markers? I attached an alternative version that uses image() instead of scatter(). It's faster, even with 512 points instead of 65.
Still, the largest amount of time was being spent on the binning process, so the above example should help a lot in that regard.
Using logical masking to set the values of OOG points saves a lot of time as well.
Note that for a small number of L bins, the image points tend to appear OOG, even though they really aren't. The reason why should be pretty obvious geometrically. The attached code is fast enough that you can use a larger number of bins (e.g. 101) without much penalty.
The attached files are provided as demo scripts. In practice, all you'd have to do is remove the first couple lines and save the file. At that point, it'll be a proper function that can be called as needed. You can then flesh out the rest of the synopsis to suit your needs.
Also, I have no idea why the spam catcher flags some things...
4 Comments
DGM
on 29 Jan 2022
I think a lot of people would recommend using guidata() for the same purpose, but I like using nested functions. It's practice that's generally applicable beyond GUI code.
More Answers (0)
See Also
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!