Re: [Gimp-developer] Some questions about tiff
Attached is an example scan from XSane. There are more than just a few grey levels and you see the hand written notes on top of it This file could easily be represented in a posterized form with 4 Bits per pixel, probably it could also be represented by 2 Bits per pixel, but Gimp's function posterize should be given parameters to use something blue for the handwritten part like in my second example . Gimp does not show a histogram when using the contrast curve tool in my example. My question arises when lots of already scanned and OCR-treated pdf files shall be optimized with three goals: 1. reduce the size of the file by reducing the 600 dpi resolution which was chosen during scanning for better OCR results, keep the OCR result, 2. reduce the bits per pixel for the scan image plane, e.g. by posterizing or even binaizing, 3. improve the contrast of the displayed pdf file by some contrast enhancing function, e.g. as it is done after applying a contrast curve in Gimp. I want to do all this maintaining the OCR-plane from input files. Manipulating sandwich PDF-files (like scans made searchable by OCR) is probably out of the scope of Gimp. But the functions used for the image plane are in it. gs (ghostscript) can reduce the dpi e.g. from 600 dpi (good for OCR) down to 150 dpi (insufficient for OCR but sufficient to display most documents. I wish, they would also provide 200 dpi requiring a bit more storage space. Unfortunately gs only handles 72 dpi (/screen), 150dpi (/ebook) and 300 dpi for output. It can do this keeping the OCR pane. To my knowledge, gs can't apply any color or grey level transformations, even none which could be made by a look up table. Regards Adalbert Am 18.09.22 um 22:32 schrieb Liam R E Quin: On Sun, 2022-09-18 at 20:52 +0200, Adalbert Hanßen via gimp-developer- list wrote: XSane produced a color scan from a document with 600 dpi and fill color, 1.1MB file size. I normally have XSane make a png file. For 8-bit per channel (0 to 255) images, you can also use the XSane gimp plugin, which is a lot easier, but make sure to export the file right away so you havwe a copy if gimp crashes or if you make a mistake :) When I load this file into Gimp, I get an error message about an incompatible TIFF format (additiona channels without the field ExtraSamples). It gives me choice to let the additional channel worlk as * non pre-multiplied alpha * pre-multiplied alpha * channel I see no difference whatever choice I select. If you choose Channel, it'll be visible in Gimp's Channels dialogue. Otherwise, it's most like pre-multiplied alpha (transparency), and will most likely be "all opaque", so you can ignore it. However: When I try to adapt colors by the contrast curve, I see no Histogram under it. How large is the image? If you used the Line Art setting in XSane every pixel will be either 0 or 255, so the histogram is just two vertical lines, one at eacn end, that aren't really visible as they're right next to the edge. FOr a large image it can take a while for the background thread to count all the pixels in the image and fill in the histogram. ** Is this due to the error message when loading the file? ** no. ankh / liam / demib0y ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Some questions about tiff
XSane produced a color scan from a document with 600 dpi and fill color, 1.1MB file size. According to tiffinfo (under Xubuntu) the properties of the Sane-generatd tiff file is TIFF Directory at offset 0x11af5a (1159002) Image Width: 4976 Image Length: 3190 Resolution: 600, 600 pixels/inch Bits/Sample: 8 Compression Scheme: JPEG Photometric Interpretation: YCbCr Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 16 Planar Configuration: single image plane Reference Black/White: 0: 0 255 1: 128 255 2: 128 255 Software: xsane DateTime: 2022:09:18 18:15:59 JPEG Tables: (574 bytes) When I load this file into Gimp, I get an error message about an incompatible TIFF format (additiona channels without the field ExtraSamples). It gives me choice to let the additional channel worlk as * non pre-multiplied alpha * pre-multiplied alpha * channel I see no difference whatever choice I select. But this might be due to my sample. However: When I try to adapt colors by the contrast curve, I see no Histogram under it. ** Is this due to the error message when loading the file? ** I see histograms under the contrast curve for other tiff images not resulting from XSane. Regards Adalbert Hanßen OpenPGP_signature Description: OpenPGP digital signature ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Suggested improvement
Currently Gimp has no key associated to overwrite the currently loaded image in the file format in which it has been loaded. *Ctl-s* stores the current image as an xcf file. I propose to assign *Shift-Ctl-s* to storing the current image under its unaltered name and format. *Why: *I often make screenshots to document software features. I have a script file which makes a screenshot 7 seconds after the function has been triggered by a keystroke. 7 seconds is usually enough to bring about the situation I want to capture with the screenshot, which might otherwise not been screenshotted, since some functions "eat up" the screenshot triggering keystrokes and thus they don't trigger the screenshot. Often, only a tiny part of the whole screenshot is interesting. Therefore my script automatically opens the stored file to let me crop the image as needed. Finally I would like to store it whit a keystroke-action. One might add to the keystroke-invokable function to immediately close Gimp without further user intervention after it has stored the file in its old format. *Additional question:* Is it possible, to automatically direct gimp by a command line option (e.g. -c) to begin with the crop tool after it has been started? Regards Adalbert Hanßen OpenPGP_signature Description: OpenPGP digital signature ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] deriving transform by comparing image before/after edit
Hello Bill, your problem could be solved much easier and doing that would open great new things to Gimp: Let us for short think of all of Gimp's functions (I just cal them functi, but their names of coursee would be unique within Gimp), which are accessible from any menu function, being split into a parameterizing function parametrize_functi and an actual operating one operate_functi, i.e. * parametrize_functi just asks for all parameters (if there are any) but does not process them * imagine thatparametrize_functi createsa log entry "functi, pi1, , pin"with all necessary parameters which it has obtained when the ok button is pressed (if there is one), * those log entries would be recorded. * when the ok button is pressed,operate_functi functions would be called through one central placewith those recorded parameters. Thefuncti areidentified by the firstentry in each recorded parameter set. Then it would become very easy to automatically re-run such recorded steps . Your question “How exactly did I achieve this result?” would become superfluous. Would that not be great? In Gimp, all theses log entries should be recorded strictly inthe sequence in which they are done. Of course, the number of the tab to which they go (and the plane in it and son on) also have to be recorded. When the clipboard is used, that has to be recorded too and if the clipboard-content doesnot originate from this particular Gimp session, a copy of it has to be stored to make everything reconstructible. (IfGimp does not get notified when the system clipboard is changed outside of Gimp, Gimp has to maintain ashadow copy of a clipboard with an image and it has to compare the current system clipboard containing an image to its own shadow copy, in order to storea reconstruction copy of the system clipboard image, if any operation happens, where the system clipboard from outside of Gimpis actually used in Gimp). With such log-keeping, even all “destructive” functions could be undone in Gimp without much storage requirements: In the worst case, the sequence of processing steps would have to be redone from the very beginning. One could speed that up by storingintermediate result toa file, until the session ends. When a picture is stored or exported, some cleanup has to be done to eliminate all logged operations and possibly also all stored system clipboards which entered the flow of operations but do not not influence any non-stored result any more. Idemat the end of a session or closing a tab, Of course, loading an image has also a parametrize function: The one which lets you select the image to be loaded and the tab to which it goes. Of course, switching to anothertab also has to be recorded. When you copy something from one tab and paste it e.g. to a plane in another tab, the associated processing logs become “mangled” because the pasted-to history now also depends on the history of the pasted-from tab and its associated image. The number of parameters of the functi differ from one function to anotherone. There could be none, like in transform to grayscale. There could be only a few, like in setting a threshold transforming to B/W or when doing some brightness or colour manipulations. There would also onlybe a few like when pasting something from the clipboard to a specified place (i.e. the coordinates of the placement and possibly an orientation angle). There could be functions which have many parameters, like cutting out some fancy shape. The whole log filecould be a plain ASCII file! It would besomething like tab1, openFile, full_path_to_it tab1, rotateImage, centerx, centery, degrees tab1, cropImage, x1, y1, x2, y2 tab2, openFile, full_path_to_that All selection operations, all cloning operations, all matrices used in convolutions, all colour adaptation operations, really everything you can do with Gimp could be recorded like this. Theoretically you could do that by hand by just exactly write down each processing step together with its parameters. But some functions have quite a lot of parameters, like e.g. cutting parts with an irregular shape, or using paintbrush-operations and the like. But a computer does not get tired when it is told to do tedious things over and over. Debug and improve mode In such an Interpreter approach, one could also provide a mode, where each parameterizingfunction is called again, but then all parameterizing steps are preset as they were done when the Gimp session was recorded. In the debug and improve mode the user can vary what wasdone before and continue, when the varied parameters have been input. If proper construction schemes are used, the parameterizing functions in this special mode are exactly the same ones as they are used in the normal mode, the only difference being that instead of only an ok button, you also haveadditional buttons "interactive", "skip" and "exit". * When you click on "interactive", you continue with arbitrary Gimp processing steps, returning
Re: [Gimp-developer] deriving transform by comparing image before/after edit
Bill, unfortunately the result of a convolution operation can not always be inverted. The most simple example is a convolution matrix (=folding matrix) with all zeroes. It definitely wipes the whole image and that can not be undone! Unfortunately, the situation is such that the result of a matrix operation almost never can be inverted. Here an explanation with a little bit more reference to mathematics, leaving out the details of not square sized pictures and convolution matrices like those in Gimp, which only have up to 5*5 entries (think of them as being larger, expanded with all zeroes around it to all sides to pad them to the image size): Let M denote the Matrix and FT(M) the fourier transform of it (expanded to the image size). The Fourier transform is a terribly complicated thing and in fact, the result of a real valued picture becomes a complex valued picture, i.e. two pictures: one for the real part and another one for the imaginary one. Fortunately in mathematics (but not in Gimp) there also is an inverse Fourier transform which is as complicated as the FT itself, but once one has a program for FT, one also has one for the inverse FT. Of course, the FT and its inverse operate on complex valued "pictures", but you normally only look onto the real part of them in the non-transformed image. (The FT image is often referred to as in the frequency range: small and "high frequency" details in the picture become large in the FT and vice versa, it is all really "convolved", as one may say in the double meanig of this word). Let P denote the picture and FT(P) the fourier transform of the picture. Let M#P denote the convolution of M and P Then FT(M#P) = FT(M)*FT(P) (point-wise multipliaction) If FT(M) has entries with zeroes in it, these zeroes will cancel their respective pixels in FT(P). This of course means that FT(M#P) can no longer be FT(P). Unfortunatly almost all FT(M) would have zeroes somewhere, if the convolution matrix would have image size. The matrix convolution can be computed very effectively and it is quite powerful, especially for small matrices. Fortunately it now works in Gimp 2.10.22 (it did not work in earlier versions of 2.10) and fortunately now we can load and store the convolution matrices. I frequently convolve scans of documents with something like this 0 0 0 0 0 0 -1 -1 -1 0 0 -1 c -1 0 0 -1 -1 -1 0 0 0 0 0 0 wherer c ins the centre-weight, a number which is larger than the negative value of the sum of all other (negative) weights, e.g. c somewhere in the range 9...12. This matrix convolution subtracts from each pixel a weighted mean of the surrounding ones. The purpose of such a filter is to remove background like shadows or stains from the document before I apply OCR to it (that's why I do this operation). By choosing c larger than the negative sum of the surrounding ones, you can give the original picture more emphasis than to the reduction of the background. My convolution filter has some "differentiating property" which lets it emphasize noise in the picture. In order to mitigate that, one can first apply some gaussian filter. Another way is to integrate the the blurring (local average) into the convolution matrix, i.e. simultaneously do some kind of smoothing for the centre, for example -1 -1 -1 -1 -1 -1 c c c -1 -1 c c c -1 -1 c c c -1 -1 -1 -1 -1 -1 with some appropriate centre weight such that the sum of the c's ie a bit larger that the negative sum of the -1's around. The centre part is a box convolution which makes the image unsharp. (It would be nice if one could change all the centre- weights in one place, but once you think about that, you trigger the desire to shape the centre weights like a bell shaped function, which comes closer to gaussian unsharpness. Indeed, Gaussian unsharpness can almost be approximted by several times folding with a box function with only positive values). Of course it would be great, if the convolution matrix could be made larger than 5*5 for such folding matrices to remove background. For removing stains and shadows, it would also be beneficial if one could apply some gray level transformation to each pixel of the image (e.g. given by a polynominal) before the pixel value is mutiplied with the matrix entry in the convolution operation and to apply some other gray level transformation (one which mostly anihilates the first one) on the way back before the convolution image is shown. In addition I would whish me something where I could apply two convolution matrices to an image: the first one acting like now, but the second one just to compute some "comparison value" which is used to set the pixel to "black" if the outcome of the first mentioned convolution is greater or equal to the outcome of the second convolution. Think of the second convolution going to some "alpha channel". But it would become necessary to be able to store and
