Doug Kerr
Well-known member
For a long time, I have done most of my photo processing and editing with Picture Publisher (since 2001, Version 10). This was a product of Micrografx, of Dallas, Texas (Richardson, actually), since essentially absorbed into Corel.
My most common processing task is what we might consider basic processing, which typically comprises primarily the following (I give some qualifications next to each item).
A. Tonal scale adjustments to compensate for non-optimal exposure. [Needed for most images].
B. Cropping. [Required for perhaps half of the images].
C. Rotation (usually to correct for the camera not being roll-level). [Needed rarely.]
D. Color correction ("white balance" and so forth). [Needed infrequently.]
E. Downsizing. [I do this for images destined for Carla's blog and such, which today is the preponderance of my work.]
I dearly love Picture Publisher 10, but when I reflect on how well it does each of those things, I realize the following (listed by key letter as in the list above).
A. It has no really handy way to do that. I usually have to make several passes around a loop of adjusting brightness (or, perhaps, gamma correction) and contrast.
B. It does this very nicely, with a very nice user interface.
C. It does this nicely. The is a measuring feature that will determine the distance between two points and the azimuth of the line between them. So I can use this to determine how much rotation will be needed bring to horizontal a known horizontal feature in the scene. The, I can ask the program to rotate by an arbitrary angle, and the setting for that will be pre-populated with the result of the measurement.
D. It's not worth a damn at this.
E. I recently realized that its performance at this falls very short of modern accomplishments.
Well, that's two out of five! In addition, it fumbles the Exif metadata of files it handles (probably would have been fixed in 10.1, but it moved on over the northern border before that), so if I want to preserve that I have to use a complex process.
Regarding E, I have of late been doing the downsizing with ImageMagick, driven by the very nice script Bart developed (customized a bit for convenience in my situation). The results there are very much better than those with PP10 (especially with respect to such matters as scene areas with fine patterns, where the PP10 downsizing often gave rise to serious moiré artifacts).
As you have seen from my other recent thread, I have recently become aware of the processing program Silkypix Developer Studio, nominally a raw development program. But essentially all its features (other than raw development itself) are available for work (perhaps with some limitations) on JPEG files (which is how I usually work).
I had earlier concluded that the work of SDS in doing white balance color correction (on JPEG files) seems quite nice, and handy to use.
I recently did some testing on its performance in downsizing, and on my "litmus test" image, its performance is indistinguishable from that of ImageMagick.
The cropping function works in a different way from that in PP10, but is very easy to use.
Regarding rotation, SDS does not have anything comparable to the measuring capability of PP10, but rotation is controlled with a slider, and the onscreen image follows essentially instantaneously. When rotation is underway, a grid is placed on the screen so I can easily tell visually when I have done what is needed.
So I am currently doing the workflow planning to move to the use of SDS to do my "routine" image processing.
In that regard, there is also a nice situation regarding filenames. I give my processed images filenames that comprise the filename by which the file is held in my (camera incoming archives) with a suffix (so they can't be confused with the source file, but the source file can always be identified). SDS will, when told to "save" the processed image as a JPG file, gladly construct a filename consisting of the source filename with any desired prefix or suffix (yes, I know that is not unusual today).
So I think this change will overall be an improvement on many fronts.
I'll keep you up to date as to how it goes.
Best regards,
Doug
My most common processing task is what we might consider basic processing, which typically comprises primarily the following (I give some qualifications next to each item).
A. Tonal scale adjustments to compensate for non-optimal exposure. [Needed for most images].
B. Cropping. [Required for perhaps half of the images].
C. Rotation (usually to correct for the camera not being roll-level). [Needed rarely.]
D. Color correction ("white balance" and so forth). [Needed infrequently.]
E. Downsizing. [I do this for images destined for Carla's blog and such, which today is the preponderance of my work.]
I dearly love Picture Publisher 10, but when I reflect on how well it does each of those things, I realize the following (listed by key letter as in the list above).
A. It has no really handy way to do that. I usually have to make several passes around a loop of adjusting brightness (or, perhaps, gamma correction) and contrast.
B. It does this very nicely, with a very nice user interface.
C. It does this nicely. The is a measuring feature that will determine the distance between two points and the azimuth of the line between them. So I can use this to determine how much rotation will be needed bring to horizontal a known horizontal feature in the scene. The, I can ask the program to rotate by an arbitrary angle, and the setting for that will be pre-populated with the result of the measurement.
D. It's not worth a damn at this.
E. I recently realized that its performance at this falls very short of modern accomplishments.
Well, that's two out of five! In addition, it fumbles the Exif metadata of files it handles (probably would have been fixed in 10.1, but it moved on over the northern border before that), so if I want to preserve that I have to use a complex process.
Regarding E, I have of late been doing the downsizing with ImageMagick, driven by the very nice script Bart developed (customized a bit for convenience in my situation). The results there are very much better than those with PP10 (especially with respect to such matters as scene areas with fine patterns, where the PP10 downsizing often gave rise to serious moiré artifacts).
As you have seen from my other recent thread, I have recently become aware of the processing program Silkypix Developer Studio, nominally a raw development program. But essentially all its features (other than raw development itself) are available for work (perhaps with some limitations) on JPEG files (which is how I usually work).
I had earlier concluded that the work of SDS in doing white balance color correction (on JPEG files) seems quite nice, and handy to use.
I recently did some testing on its performance in downsizing, and on my "litmus test" image, its performance is indistinguishable from that of ImageMagick.
The cropping function works in a different way from that in PP10, but is very easy to use.
Regarding rotation, SDS does not have anything comparable to the measuring capability of PP10, but rotation is controlled with a slider, and the onscreen image follows essentially instantaneously. When rotation is underway, a grid is placed on the screen so I can easily tell visually when I have done what is needed.
So I am currently doing the workflow planning to move to the use of SDS to do my "routine" image processing.
In that regard, there is also a nice situation regarding filenames. I give my processed images filenames that comprise the filename by which the file is held in my (camera incoming archives) with a suffix (so they can't be confused with the source file, but the source file can always be identified). SDS will, when told to "save" the processed image as a JPG file, gladly construct a filename consisting of the source filename with any desired prefix or suffix (yes, I know that is not unusual today).
So I think this change will overall be an improvement on many fronts.
I'll keep you up to date as to how it goes.
Best regards,
Doug