|
rearrange pixels of first image in brightness order >>
|
|
|
The first step is to sort each image's pixels in order of brightness. To remember the original order, another array the length of the number of pixels in the images is initialized from 0 to n -1. This array gets sorted in parallel with the first image, acting as a breadcrumb trail so the first image can be 'unsorted' later.
|
| |
|
rearrange pixels of second image in brightness order >>
|
|
|
There seems to be something wrong with my brightness sorting. I'm using Processing's brightness() function to check pixel orders. It's likely my quicksort has some anomalies, but the overall order is generally acceptable.
|
| |
|
|
superimpose second image's brightness-sorted-pixels over first image's brightness-sorted-pixels >>
|
|
|
Next, the sorted second image's pixels are laid over the sorted first's. Even though each pixel might not be the best match between images, the gradients match up, so the best overall pixel remapping for brightness has occurred.
|
| |
|
|
sort first image back into original order >>
|
|
|
Finally, the temp array from step 1 is sorted back to its original order, while the pixel array of image 1 is sorted in parallel. This undoes the first step's sorting, effectively restoring the first image. Image 2's pixels have now been resorted to resemble image 1. The process takes about 5 seconds on images of this size and simplicity of color. Larger images, or those with lots of choppy color variations not only take longer - they crash Processing! I could probably reduce this effect by sorting smaller segments of larger or more complex images at a time, but I'm too lazy.
|
| |
|
A comparison shot of the remapping of the first image's pixels to the second image.
|
| |
|
Reversing the input images maps the dinner scene's pixels to the EL wire portrait.
|
| |
|
