Page 1 of 2

[FIXED]possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-06T14:38:32-07:00
by fmw42
IM 6.7.6.9 Q16 Mac OSX Snow Leopard

-format %c histogram:info: does not seem to work. No output to terminal

But it works fine in verbose info:



convert rose: +dither -colors 12 -depth 8 1rose1.gif
convert 1rose1.gif -unique-colors txt:
# ImageMagick pixel enumeration: 12,1,255,srgb
0,0: ( 51, 51, 45) #33332D srgb(51,51,45)
1,0: ( 98, 57, 47) #62392F srgb(98,57,47)
2,0: ( 83, 76, 56) #534C38 srgb(83,76,56)
3,0: ( 94, 93, 79) #5E5D4F srgb(94,93,79)
4,0: (161, 59, 44) #A13B2C srgb(161,59,44)
5,0: (221, 54, 48) #DD3630 srgb(221,54,48)
6,0: (187, 72, 68) #BB4844 srgb(187,72,68)
7,0: (232, 81, 89) #E85159 srgb(232,81,89)
8,0: (110,147, 86) #6E9356 srgb(110,147,86)
9,0: (140,133,146) #8C8592 srgb(140,133,146)
10,0: (166,166,186) #A6A6BA srgb(166,166,186)
11,0: (245,243,239) #F5F3EF srgb(245,243,239)


convert 1rose1.gif -format %c histogram:info:
(no output)

identify -verbose 1rose1.gif
...
Histogram:
552: ( 51, 51, 45) #33332D srgb(51,51,45)
274: ( 83, 76, 56) #534C38 srgb(83,76,56)
332: ( 94, 93, 79) #5E5D4F srgb(94,93,79)
179: ( 98, 57, 47) #62392F srgb(98,57,47)
208: (110,147, 86) #6E9356 srgb(110,147,86)
117: (140,133,146) #8C8592 srgb(140,133,146)
276: (161, 59, 44) #A13B2C srgb(161,59,44)
121: (166,166,186) #A6A6BA srgb(166,166,186)
167: (187, 72, 68) #BB4844 srgb(187,72,68)
555: (221, 54, 48) #DD3630 srgb(221,54,48)
238: (232, 81, 89) #E85159 srgb(232,81,89)
201: (245,243,239) #F5F3EF srgb(245,243,239)
...

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-06T14:48:40-07:00
by magick
Add -define histogram:unique-colors=true to your command line.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-06T15:10:34-07:00
by fmw42
magick wrote:Add -define histogram:unique-colors=true to your command line.

My apologies. I thought that was only an option, such that if false it would speed up the histogram image generation. I thought the default was true.

Even Anthony's page at http://www.imagemagick.org/Usage/files/#histogram does not mention the need to add it as true to get the simple text histogram. He shows it not used at all for the text information.

P.S The first changelog entry for the -define was

2010-04-17 6.6.1-5 Cristy <quetzlzacatenango@image...>
...
For the histogram: format, if you have no need for the unique color list, use <kbd>-define histogram:unique-colors=false</kbd> to forego this expensive operation.

But in a subsequent release, IM 6.7.4.10, it was not needed to get -format "%c" histogram:info:

So it seems the behavior has changed sometime after that release to the current one.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-08T22:08:17-07:00
by anthony
My understanding was that that change was only in IMv7!

That is by default in IMv7 color comment is NOT produced as it takes a lot of time.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-09T09:46:07-07:00
by fmw42
I thought this define was only needed to disable the text histogram when creating an image histogram and was by default on so that one could get a test histogram, via -format "%c" histogram:info:

My issue is really what do I do about all my scripts. If this behavior is being swapped and is going to be required to add the define to create a text histogram via histogram:info: from now on in IM6 and IM 7, then I need to change all my scripts now.

1) So my question is what is the decision about IM 6. Is this a new permanent change?

2) What is the intent for IM 7?

3) I presume that adding that define will not affect older version of IM 6 before the define was even needed for to disable the text histogram when generating a histogram image.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-09T21:33:27-07:00
by anthony
The change for me was only IMv7. I even documented it in Porting (no idea if changes are migrating to the actual web page though).

I have no idea why this change is in IMv6, probably due to a 'backport' from the coder. A lot of development still happens in BOTH. My updates for the percent escape handling for example. But I only backport compatible or bug fix changes.

I'll restore the default 'true' status in IMv6 if you want.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-10T09:53:57-07:00
by fmw42
anthony wrote:The change for me was only IMv7. I even documented it in Porting (no idea if changes are migrating to the actual web page though).

I have no idea why this change is in IMv6, probably due to a 'backport' from the coder. A lot of development still happens in BOTH. My updates for the percent escape handling for example. But I only backport compatible or bug fix changes.

I'll restore the default 'true' status in IMv6 if you want.

I think that would be best, if Magick does not object, so that others do not fall into this trap.

However, I am not sure why you are changing this behavior for IM 7. The old behavior was to have the default be on so that histogram:info works and let the users turn it off for making an image histogram. This has been the way it has been now for quite some time. It seems better to have a default such that if not used, something does not break, even if the other takes longer. The way you have it now, one has to remember to turn it on for textual histograms or else it breaks. This is just to keep image histograms faster. I think this is the wrong approach.

However, if you still intend to do that, then let me know as I need to change many scripts to add the "on" define for textual histograms.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-10T23:35:56-07:00
by anthony
It is an area that will eventually have quite a bit of option development later in IMv7 (beta).

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-11T09:16:58-07:00
by fmw42
anthony wrote:It is an area that will eventually have quite a bit of option development later in IMv7 (beta).
OK. But what is going to be done now in IM 6. Will you back it out so that histogram:info: works without the define set to true or need I change my scripts to put in the define set to true?

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-13T22:11:00-07:00
by anthony
Done in the SVN and for the next release.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-13T22:15:10-07:00
by fmw42
anthony wrote:Done in the SVN and for the next release.
OK, I will check tomorrow. My tests today (as late as earlier this evening) on the 6.7.6.10 beta would not produce any textual histogram with or without the define. Nothing was returned in either case.

What is the intent for this in IM 7? If you are going to change it in IM 7, then I probably should just go ahead and add the define into my scripts now in IM 6.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-13T22:51:18-07:00
by anthony
I can not actually say any more.

When I made that change it was my intent to change it. however since looking at percent escape property code, I noted that the percent expression '%k' also calls the exact same routine to get number of unique colors. This was unexpected. Until I check out the code I am not certain.

As for percent escapes, my refactoring is done for both IMv6 and IMv7, Updated documentation on my 'discoveries', and
added 'gamma' as a image attribute setting and escape.

In IMv7 I have added the new rule "only expand a single letter escape is NOT preceded by a number"
EG: 10%x does not expand the 'x' (X density with units) but 10%[x] does.
That way things like 10%x90% remains a valid geometry argument even though percent escapes were applied.

I do not expect anything to break from this refactoring. But let me know if anything crops up.

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-14T09:59:33-07:00
by fmw42
anthony wrote:I can not actually say any more.

When I made that change it was my intent to change it. however since looking at percent escape property code, I noted that the percent expression '%k' also calls the exact same routine to get number of unique colors. This was unexpected. Until I check out the code I am not certain.
OK. I will hold off until I hear further from you.
anthony wrote:As for percent escapes, my refactoring is done for both IMv6 and IMv7, Updated documentation on my 'discoveries', and
added 'gamma' as a image attribute setting and escape.

In IMv7 I have added the new rule "only expand a single letter escape is NOT preceded by a number"
EG: 10%x does not expand the 'x' (X density with units) but 10%[x] does.
That way things like 10%x90% remains a valid geometry argument even though percent escapes were applied.

I do not expect anything to break from this refactoring. But let me know if anything crops up.
Are you saying that all string formats (http://www.imagemagick.org/script/escape.php) will no longer work as is and will need brackets in IM 7?

EDIT:
Perhaps I misread your post -- so %x will still work, but 10%x will need to be 10%[x]. Is that correct?

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-14T19:44:22-07:00
by anthony
fmw42 wrote:
anthony wrote:
anthony wrote:As for percent escapes, my refactoring is done for both IMv6 and IMv7, Updated documentation on my 'discoveries', and added 'gamma' as a image attribute setting and escape.

In IMv7 I have added the new rule "only expand a single letter escape is NOT preceded by a number"
EG: 10%x does not expand the 'x' (X density with units) but 10%[x] does.
That way things like 10%x90% remains a valid geometry argument even though percent escapes were applied.

I do not expect anything to break from this refactoring. But let me know if anything crops up.
Are you saying that all string formats (http://www.imagemagick.org/script/escape.php) will no longer work as is and will need brackets in IM 7?

EDIT:
Perhaps I misread your post -- so %x will still work, but 10%x will need to be 10%[x]. Is that correct?
That is correct. The point is to make what used to work, continue to work as much as posible, but also ensure that when I start allowing the use of escapes in 'geometry style' arguments (my next task) that percent that follow numbers are still thought of as percent so it can be used as a geometry argument flag.

Geometry Style Arguments...
http://www.imagemagick.org/Usage/basics/#arg_geometry

So with this new 'escape handling' rule....
an argument "10%x" will think the % as a character '%' and not as a %x escape
But "10 %x" or "10%[x]" will take the percent to mean a %x escape.
Of course "10%%x" or "10\%x" will also mean 'do not do the escape' in a more explicit way.
We also do not want '10%' to produce a error about 'unknown escape', which is also being added.

WARNING: Until the last release "%[x]" would FAIL and do nothing. It just was not understood as being equivalent to "%x" that is what I have been working on over the last week!

What is wanted (needed) is for -resize '50%' to continue to work as it has always done, but also allow users to do -resize '%[my:percentage]%%' where 'my:percentage' is a pre-calculated user defined setting.

Essentially I want to get rid of the need to run multiple IM commands, just to get values that are already known to ImageMagick!

ASIDE: %x means substitute a "X resolution (density) with units". For no units you would either use "%[resolution.x]" or if you want to do some calculations you can use "%[fx:resolution.x]".


Later I will be adding a vary large number of new escapes, to access as many options that IM knows about and any meta-data that has previously been missing. 'gamma' was probably the first of many.

Suggestions for new escapes welcome!

Re: possible bug histogram IM 6.7.6.9 Q16

Posted: 2012-05-14T20:10:33-07:00
by fmw42
What is wanted (needed) is for -resize '50%' to continue to work as it has always done, but also allow users to do -resize '%[my:percentage]%%' where 'my:percentage' is a pre-calculated user defined setting.
please explain the need for %% at the end and what does that become under windows?


%[type] for truecolor, grayscale, truecolormatte (or perhaps in IM7 truecoloralpha?) etc
%[alpha] to test if alpha exists as a channel (separate from %[channels]) (I see %A does that, so perhaps %[alpha] is not needed)
%[im_version] as 06070609 (this is different from %[version], which does not seem to be working)
%[first_min_location] x,y location of first min pixel
%[first_max_location] x,y location of first max pixel
%[last_min_location] x,y location of last min pixel
%[last_max_location] x,y location of last max pixel

Feel free to change/shorten the names