Xarx

I'd already answered this question before you asked it. If I check the changes every month, it would be quick. But as I do that only once in a time, I would miss all the updates from previous months (but the last one). Never mind, pointless discussion, as you're decided.

I understand your concerns about "unauthorized indexes". But data that can be loaded into Excel (e.g. CVS) can be filtered, sorted, I can add my own notes to them etc. And most importantly, if a new version of the index is published, I can easily identify the changes without needing to read the whole index again, and also refer to my own notes to the older plugins I've written earlier. I know, every month you point out the new plugins, but I don't check for the new plugins every month, and every time I do, it always takes me lot of time.

I'm not going to discuss the graphical style of the index. Instead, I'd prefer an index version that I could load into Excel or database. Neither the current HTML version nor the PDF are suitable for that. Would it be acceptable for you, EER?

Wizardry, is it? ;-)

Rotation Bilinear works exactly like I need, unfortunately the center of rotation cannot be outside the canvas :-(. Rotate Zoom+ cannot even set the center of rotation. But exactly something like this I need also for shifts (moves). ;-) There are many ways how to simulate the sub-pixel shifts, for instance: 1. Enlarge the image, say 4x 2. Do normal pixel move 3. Return the image its original dimensions again If you know exactly the amount of the pixel move you need, you can use these workarounds, but they are unsuitable for experimenting or "fine tuning".

I have several layers in an image, and I need to align them precisely. The ordinary layer shift ("move pixels") by multiples of pixels is not sufficient. Is there a tool or plugin for PDN that allows sub-pixel shifts (i.e. moves by fractions of pixel)? And rotations by very small angles?

Yes and no, it depends on which kind of calculation you are doing. The basic thing in which sRGB and RGB differ is that RGB is "linear", while sRGB is not. Moreover, the conversion formulas for most pixel characteristics like saturation, HSV value, chroma, luminance use RGB colors, not sRGB encoded (gamma corrected) colors (see Wikipedia). It seems that PDN has some internal knowledge about sRGB. Because when you e.g. make a printscreen, paste it into PDN and save it as .png, the saved image contains the sRGB flag (ancillary chunk, see Wikipedia). But if you create and edit a new image in PDN and save it as .png, it does NOT contain this sRGB flag, meaning that the image is RGB encoded, not sRGB. (And this is correct behavior, in my opinion.) And thus I repeat my original question: When I scan an image with PDN, is the image sRGB encoded or not? It should be, I suppose.

I know that PDN has no explicit means to work with color profiles. But it cannot avoid working with color profiles implicitly - because scanners, printers, image files (when loading/saving) and Windows itself do use them. Thus I expect that when scanning, PDN receives sRGB encoded image. when printing, it sends the sRGB image to the printer without decoding it (the Windows do the decoding then, I suppose). But what does PDN do when loading/saving an image from/to disk? In particular, when a loaded image uses different color space, does PDN convert the image to RGB, or to sRGB? And does PDN do that consistently, or is the result sometimes RGB, and sometimes sRGB? I am asking because I needed to perfor some a little more complex calculations on scanned images using the CodeLab, and the results were not satisfactory. The results improved when I considered the image sRGB encoded, but they were still far from perfect.

Does PDN use internally sRGB or RGB color coding? For example, when I scan an image from within PDN and use the default Windows color profile (sRGB), is then the image in PDN sRGB-encoded or not? I'd say that it is sRGB encoded. But almost all PDN tools and plugins do not bother to decode it before manipulating it, am I correct? The correct processing sequence should be sRGB -> RGB -> image manipulation -> RGB -> sRGB while most tools manipulate the sRGB image directly: sRGB -> manipulation -> sRGB. Am I right? Martin.

This plugin sets one image channel (R,G,B,A) from another one or from other basic pixel characteristics (a CMYK component, HSV component, luminance etc.). This plugin arose as a natural extension to the Mike Ryan's InputToOutput plugin. Sure, there are other similar plugins by idea, like the Pyrochild's Gradient Mapping or the Ed Harvey's Extract Channel, but they replace the original image, not modify it. InputToOutput+_v1.0.zip

Yes, this is a very essential information! The plugin author should adment his 8-point "Instructions to use" and add that all the C,M,Y layers must have their layer blend mode set to Multiply (choose a layer and press F4; for the K layer it doesn't matter; This is because the C,M,Y colors are inks, while the black K is a pigment). Then the image composed of all the four layers looks identical to the original image, not so "washed out" as the presented sample result.

Neither :-). The originals were this badly printed :-(. The paper color turned to grey-yellow due to age (the magazines are 30 to 50 years old). To be honest, I didn't try many programs. All programs I have use the same Windows scanning component as Paint.Net does, and there is not much to set. I don't have any program that has direct access to the scanner (or at least I don't know about any). But as I've said, the problem is already in the originals, not in the scanning process, so I don't thing that changing the scanning program would help much. Only if it allowed to scan directly to CMYK or some other advanced scanning settings. Martin.

I owe the originals, so I can rescan them again. But how will it help? If I don't change any scanning parameters, I shall get the same results. Should I scan to CMYK directly? How? Will it then cope with the non-pure CMYK colors so that I can re-position and fit them correctly? Martin.

Thanks nitenurse79. But I'm quite satisfied with the results from the Grim Color Reaper plugin. The main problem is the mispositioned blue/green/purple lines in the drawing - the drawing should be outlined with lines of black color, not with rainbow lines. I mentioned the non-white background paper mainly for completeness, as it might influence the solution of the other problem, and in that way it might prevent the use of the Grim Color Reaper plugin. Martin.

There's already a plugin "RGB to CMYK" that decomposes an image into 4 individual layers that together give the original image. But the problem is that the plugin uses the "pure" CMYK colors, and I need some "dirty" ones. So this plugin is not of much help to me. Even an idea how to do it would be helpful, then I could search for a way on how to realize it (e.g. search for a plugin, use the CodeLab, search for a different program). Martin.

Hello, I've got a lot of paper models from old teen magazines, and I want to scan them. There are, however, several problems, and especially the second one I need to solve. Could you provide me with an advice? I attached a sample image. (Of course, I have the scans in raw format myself. Here I had to convert it to JPEG due to the attachment max allowed size limit.) 1. The old paper is not white, it's rather of a cream or yellowish color. I use the Grim Color Reaper plugin to make it white, with pretty satisfactory results. 2. The models are printed with web-offset technique (probably), but sometimes the CMYK colors are not positioned correctly to fit together. See the sample image. I'd like to correct the CMYK color positioning as best as possible. But I havent't succeeded, so far. The main problem here is in that the scanned CMYK colors are "dirty" and not saturated enough. And I haven't found a plugin nor formula that would allow me to decompose images into non-pure CMYK colors. Could you advise me a solution? Thank you, Martin.