Processing for print

[snibgo]

Good stuff. The next upload of my customim page will have edits addressing the points you have raised.

[afre]

Thanks again. That would be of great help to others. Didn't document all the adjustments; everyone's system is different after all.

Two more things:

1. %CYGTEMP% is my only tmp directory. When I run %PICTBAT%eqLimit for the first time (or after emptying %CYGTEMP%), I have to run the command 2 times before it works (again). I get the following output:

   Code: Select all

   set eqlDEBUG=1
   
   %PICTBAT%eqLimit random.jpg . . . OUT1.tif [x3]
   
   [1x]
   C:\Users\***SRCDIR***>rem From image random.jpg, 
   
   C:\Users\***SRCDIR***>rem make contrast-limited histogram-equalised (with iterative redistribution) version. 
   convert.exe: improper image header `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/miff.c/ReadMIFFImage/1090.
   convert.exe: no images defined `info:' @ error/convert.c/ConvertImageCommand/3212.
   histcap= 
   convert: improper image header `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/miff.c/ReadMIFFImage/1090.
   convert: no images defined `C:\cygwin64\tmp\OUT1_eql_gchc_cap.miff' @ error/convert.c/ConvertImageCommand/3212.
   convert.exe: improper image header `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/miff.c/ReadMIFFImage/1090.
   convert.exe: unable to open image `C:\cygwin64\tmp\OUT1_eql_gchc_cap.miff': No such file or directory @ error/blob.c/OpenBlob/2674.
   convert.exe: no images defined `info:' @ error/convert.c/ConvertImageCommand/3212.
   MeanDiffPC=
   convert: improper image header `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/miff.c/ReadMIFFImage/1090.
   convert: no images defined `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/convert.c/ConvertImageCommand/3212.
   convert: improper image header `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/miff.c/ReadMIFFImage/1090.
   convert: no images defined `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/convert.c/ConvertImageCommand/3212.
   convert: improper image header `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/miff.c/ReadMIFFImage/1090.
   convert: no images defined `C:\cygwin64\tmp\OUT1_eql_gchc_clhe_red.miff' @ error/convert.c/ConvertImageCommand/3212.
   convert.exe: unable to open image `C:\cygwin64\tmp\OUT1_eql_gchc_clhe_red.miff': No such file or directory @ error/blob.c/OpenBlob/2674.
   convert.exe: no images defined `OUT1.tif' @ error/convert.c/ConvertImageCommand/3212.
   
   [2x]
   C:\Users\***SRCDIR***>rem From image random.jpg, 
   
   C:\Users\***SRCDIR***>rem make contrast-limited histogram-equalised (with iterative redistribution) version. 
   histcap=13.0601815823606 
   convert: color separated image required `\cygwin64\tmp\OUT1_eql_gchc_cap.miff' @ error/raw.c/WriteRAWImage/528.
   convert.exe: improper image header `C:\cygwin64\tmp\OUT1_eql_gchc_cap.miff' @ error/miff.c/ReadMIFFImage/510.
   convert.exe: no images defined `info:' @ error/convert.c/ConvertImageCommand/3212.
   MeanDiffPC=
   convert: color separated image required `\cygwin64\tmp\OUT1_eql_gchc_clhe_red.miff' @ error/raw.c/WriteRAWImage/528.
   convert.exe: improper image header `C:\cygwin64\tmp\OUT1_eql_gchc_clhe_red.miff' @ error/miff.c/ReadMIFFImage/510.
   convert.exe: no images defined `OUT1.tif' @ error/convert.c/ConvertImageCommand/3212.
   
   [3x]
   C:\Users\***SRCDIR***>rem From image random.jpg, 
   
   C:\Users\***SRCDIR***>rem make contrast-limited histogram-equalised (with iterative redistribution) version. 
   histcap=13.0601815823606 
   MeanDiffPC=0.61274586099031

2. Wondering how you made this and this out of this. My output is different; also 256x256. Correct me if I am wrong but your goal with shadows/highlights was to make the cumulated slope span from one corner to the other in the graph. (If so, I wonder if there is a way to automate the task.)

[snibgo]

convert: improper image header `C:\cygwin64\tmp\OUT1_eql_gch.miff' @ error/miff.c/ReadMIFFImage/1090.

The problem may be that the script eqLimit.bat uses both %TEMP% and %CYGTEMP%. Near the start, it writes OUT1_eql_gch.miff to %CYGTEMP%, and then reads it from %TEMP%. So they must point to the same place. The difference is that %CYGTEMP% is in the Cygwin style. On my computer:

Code: Select all

f:\pictures>echo %TEMP%
C:\Users\Alan\AppData\Local\Temp

f:\pictures>echo %CYGTEMP%
/cygdrive/c/Users/Alan/AppData/Local/Temp

You can see that they point to the same directory, but the Windows style is rooted at "C:\" where the Cygwin style is rooted at "/cygdrive/c/".

If your %TEMP% and %CYGTEMP% don't point to the same directory, there will be problems. [Note to self: amend web page instructions, and add an automated test. Perhaps Cygwin IM no longer needs this weirdness.]

Does that solve a problem?

Wondering how you made this http://im.snibgo.com/eql_src1_cle_eql_gch.png
and this http://im.snibgo.com/eql_src1_cle_eql_gchc_clhe_red.png
out of this http://im.snibgo.com/eql_src1_sm.jpg.

I didn't. Small JPEGs (*_sm.jpg) are made for display only; I don't process them. Those graphs are made from eql_src1.tiff, which is 115 MB, 5120x4840 pixels, 16 bits/channel/pixel. I haven't uploaded that file, and I won't. (With my internet connection, it would take hours.)

My output is different; also 256x256.

From an 8-bit jpg, yes, the graph will only be 256 wide. The histogram has only 256 entries, so there is no point in being any wider. If you run eqLimit.bat on an image with more bits/channel, you will get a wider graph.

Correct me if I am wrong but your goal with shadows/highlights was to make the cumulated slope http://im.snibgo.com/eql_src1_clesh_eql ... he_red.png
span from one corner to the other in the graph. (If so, I wonder if there is a way to automate the task.)

It already spans corner-to-corner. The purpose of that section of that page http://im.snibgo.com/eqlimit.htm#tweak is to "drop" the highlights by increasing their contrast. So white stays white, but nearly white becomes darker. If you compare that graph with the previous one, you'll see a difference in slope at the right side of the graph. I combine the two here, with an arrow showing the drop:

I have been working on improved methods for the same effect.

[snibgo]

As the script requires that CYGTEMP points to the same directory as TEMP, but in the Cygwin style, we can force it to be so with this Windows command:

Code: Select all

for /F "usebackq" %%L in (`cygpath %TEMP%`) do set CYGTEMP=%%L

I'll insert that into all scripts that need it.

[afre]

1. Replaced all "%TEMP%" with "%CYGTEMP%" (C:\cygwin64\tmp) because my %TEMP% path is unacceptably long. It's still puzzling as to why I need to run the script 3x when I begin with an empty/cleared %CYGTEMP%.

2. Didn't think through the slope-question before posting. Also, didn't realise the script is smart enough to display different graphs for different inputs. Now that that's out of the way, I will try to reframe my question:

Comparing this with this, the latter appears to have a nicer rolloff at either end. I wonder if there is an intuitive(?) way to set paramters for batch processing. Right now, the lift and drop appear, at least to me, a bit arbitrary and more of a per-photo thing.

Shadows/highlights slope thresholding? I don't know if that made any sense . Also, this is probably outside of the scope of this thread or your scripts atm. Not saying it is too difficult for you, but I wonder if others like fmw42 have anything to say about this.

[snibgo]

It's still puzzling as to why I need to run the script 3x when I begin with an empty/cleared %CYGTEMP%.

I am also puzzled.

Right now, the lift and drop appear, at least to me, a bit arbitrary and more of a per-photo thing.

Agreed. I've been working on two angles: a more intuitive setting for the user, and automatic hands-off correction. I think I've cracked both, but other stuff has distracted me.

Comments from Fred or anyone are welcome.

[afre]

1. I think I've cracked both, but other stuff has distracted me.

   Sounds good. However, eqLimit, etc. aren't suitable for me atm because

   It's still puzzling as to why I need to run the script 3x when I begin with an empty/cleared %CYGTEMP%.

   It's especially annoying when processing multiple files or testing multiple parameters. Maybe it's the way the scripts handle temp files. In addition, temp files are sometimes created in-directory (e.g. eqlTile), and they aren't always cleared. You probably have good reasons for %TEMP%, %CYGTEMP% and in-directory temp files, so I won't question that. But because of the complexity, I get these problems.
   
   Maybe this will help:
   • My console is C:\Windows\System32\cmd.exe (echo %TEMP%/%CYGTEMP% don't work in CYGWIN's bash/cmd)
   • My temp directory is C:\Users\****\AppData\Local\Temp
   • My >%IM% is ImageMagick 6.9.0-7 Q16 x64 (binary)
   • My >%IMDEV% is ImageMagick 6.9.0-6 Q32 x86_64 (WIN src; your build instructions)
   • My > is ImageMagick 6.9.0-0 Q16 x86_64 (? - still works after binary uninstallation)
   • CYGWIN is near-current; MinGW was previously on my system
2. Still having trouble generating the histogram and cumulated slope pair. E.g. if I have orig.png and then processed.png, what would I have to do to generate their respective graphs so that they match or are similar to the ones in your discussion here and here?

[afre]

Back on topic :
I would like to make a label that is white on black or vice versa depending on the context. Instead of taking the intensity of the entire image, it would be more appropriate the take that of a subregion (say SouthEast). As noted, I could probably do things haphazardly with many commands and temp files (if I can remember how to use the appropriate IM options), but that wouldn't be good for efficient batch processing.

Please point me in the right direction; e.g. how to identify the average intensity of a SouthEast subregion. Thanks.

[snibgo]

It's still puzzling as to why I need to run the script 3x when I begin with an empty/cleared %CYGTEMP%.

You could comment-out the "@call echoOffSave" at the top of the script and post the output here. Also post an input file, so I can reproduce the result.

I still use v6.9.0-0, and it is possible an IM bug in a later version causes the problem.

If you provide an input file, I can use it as the source image for a version of the eqlimit.htm page, which I can zip up so you can download it and view it on your computer.

Please point me in the right direction; e.g. how to identify the average intensity of a SouthEast subregion. Thanks.

Code: Select all

convert in.png -gravity SouthEast -crop 100x50+0+0 +repage -colorspace Gray -format "%[fx:mean]" info:

This crops the image to the 100x50 south-east corner, and gives an intensity number like 0.147157 where 0 would be black and 1.0 is white.

[afre]

Code: Select all

convert in.png -gravity SouthEast -crop 100x50+0+0 +repage -colorspace Gray -format "%[fx:mean]" info:

1. Forgot that we could use -format with convert. Is it possible to make it into a condition within IM to set a label black or white? My standard method would be to write to file and use that info for a later conditional call.
2. About -format. The fx prefix would probably be the way to go, since to my understanding it has a floating point range [0..1]. What I am currently confused about is kurtosis, skewness and entropy. They appear to be different in value when without prefix, with fx (sans entropy) and with verbose. It's in the context of %imdev% but I would like a general response.

[fmw42]

The range of [mean] is from 0 to quantumrange of your IM compile. The range of [fx:mean] is always from 0 to 1. Similarly for all the other statistics. The fx versions always range from 0 to 1.

[afre]

The range of [mean] is from 0 to quantumrange of your IM compile. The range of [fx:mean] is always from 0 to 1. Similarly for all the other statistics. The fx versions always range from 0 to 1.

OK—that confirms my impression of fx. What's odd is that kurtosis and skewness show different values among [...], [fx:...] and -verbose. [fx:kurtosis] and [fx:skewness], which aren't shown here, deviate more from their -verbose and non-fx counterparts. Also, [fx:depth] is nowhere near [depth]; must be a bug or metric unknown to me. Anyway, under Q32,

Code: Select all

%imdev%identify -quiet -verbose *TIF

Image statistics:
Overall:
min: 0 (0)
max: 65535 (1)
mean: 32830.1 (0.500956)
standard deviation: 15352.3 (0.234262)
kurtosis: -1.15263
skewness: -0.117958
entropy: 0.945626

Code: Select all

%imdev%identify -quiet -format "\ndepth %[fx:depth]\nminima %[fx:minima]\nmaxima %[fx:maxima]\nmean %[fx:mean]\nsigma %[fx:standard_deviation]\nkurtosis %[kurtosis]\nskewness %[skewness]\nentropy %[entropy]\ncolors %k\n" *TIF

depth 3.72529e-09
minima 0
maxima 1
mean 0.500956
sigma 0.234263
kurtosis -1.24141
skewness -0.11368
entropy 0.945626
colors 10486993

Another useful statistic may be where the peaks are located. Is there a way I can find out where the top XX peaks are like this?

[fmw42]

Entropies match. kurtosis and skewness may be different due to different precision used in computing them in different parts of the code. One of the developers would need to look at this.

I am not sure what depth is supposed to represent. The value does look very odd.

I do not understand what you want by peaks? Peaks in what? The histogram? Depending upon the image, one could have more than a few peaks. A raw histogram jumps up and down a lot separated by only a few graylevels, i.e, spikes. That is not practical to present in the v verbose information.

What you may want is some smoothing applied to the histogram to smooth out the closely separated peaks/spikes and make just a few rounded peaks. That would mean you would have to supply a smoothing amount. This would mean some new define for identify as best as I can tell. It would also mean you need peaks separately from each channel.

[snibgo]

I have a page on histogram peaks and troughs, which I hope to publish in a week or so (along with "-sparse-color triangulation" and an inpainting process module).

I don't know what depth, kurtosis, skewness and entropy represent.

[afre]

More info on what I meant by peaks (see "More About").