Page 1 of 1
Possible remap bug
Posted: 2013-01-27T18:55:10-07:00
by spongemonkey
Q16 6.8.0-7 64bit on Windows
Remapping
this image with
this colour map results in an image which contains a colour that doesn't appear in the colour map (namely rgb(101,4,1))
commands used were:
Code: Select all
convert.exe InputImage.tif -remap ColourMap.tif Remapped.tif
convert.exe ColourMap.tif -unique-colors txt:- > map_colours.txt
convert.exe Remapped.tif -unique-colors txt:- > remapped_colours.txt
This isn't right is it? Let me know if those links are no good and I'll find somewhere else to upload them to, or I can email the files if not.
Thanks
Re: Possible remap bug
Posted: 2013-01-27T19:27:39-07:00
by fmw42
Re: Possible remap bug
Posted: 2013-01-27T19:58:36-07:00
by snibgo
Should dithering create a difference in the colours chosen? I can't see that. Besides, I've tested this with and without dithering, and the same problem occurs.
As far as I can see, the OP is doing this correctly, and yes, it creates a colour srgb(101,4,1) (out of 65535) that isn't in the map. The closest map colour is srgb(100,0,0). The other colours look ok, but I haven't done a thorough search.
I tested in Windows 7, IM v6.7.9 and 6.8.1-10.
I notice from the documentation (
http://www.imagemagick.org/script/comma ... .php#remap ) that "the closest color (in RGB colorspace) is selected to replace that pixel in the image". Perhaps this means that both the image and map are converted from sRGB to RGB before mapping, and the result is converted back to sRGB afterwards. Perhaps this conversion has a bug at these very low values.
Re: Possible remap bug
Posted: 2013-01-30T18:48:24-07:00
by spongemonkey
Does anyone in authority have any comment on this? I'm working on a project predicated on the notion that the colours are preserved, and will have to rethink the design radically if this assumption is unfounded
Cheers
Re: Possible remap bug
Posted: 2013-01-30T18:54:44-07:00
by magick
As you might imagine, your bug report is not our only one. When we find the time to properly investigate, we will comment. Perhaps by the end of this weekend.
Re: Possible remap bug
Posted: 2013-01-30T19:00:58-07:00
by spongemonkey
Thanks, I don't mean to sound impatient
Re: Possible remap bug
Posted: 2013-02-02T06:37:56-07:00
by magick
We need your images to reproduce the problem but the links do not work. Post new links or e-mail the images to bugs at imagemagick dot org.
Re: Possible remap bug
Posted: 2013-02-02T08:42:26-07:00
by spongemonkey
Emailed images
Thanks
Re: Possible remap bug
Posted: 2013-02-02T14:13:39-07:00
by magick
Remapping limits the colormap to 8-bits of precision. The mapping process utilizes an octree which is limited to 8-bits to limit resource consumption. For 16-bit images, some colors (those deeper than 8-bits) are coalesced into the same node. When that happens, the mean color-cube is returned and that color is used in the remapping process. Note the original image can be any depth but the colormap must be at most 8-bit. To get the expected results you need to ensure your colormap is at most 8-bits in depth. Try these commands:
- convert ColourMap.tif -depth 8 map.tif
convert InputImage.tif -map map.tif Remapped.tif
Re: Possible remap bug
Posted: 2013-02-13T05:45:48-07:00
by spongemonkey
I have everything working now. I'm using Magick++ and was making no progress for a long time as I was using
instead of
I guess this doesn't really belong in bugs then? Or would you prefer it stayed here and I marked it as [INVALID] or something?
Thank you!!