[Gimp-developer] Quick mask malfunctioning on grayscale pictures
I think this is a bug. If not, then it's a serious application design issue. Shift+Q on grayscale pictures ignores color setup for quick mask. Default red appears as mid intensity gray which makes this great functionality useless on most occasions (for mottled pictures almost always). Any thought or should I go for filling a bug report?! Regards, Vladimir ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Problem with perspective transform matrix
Hello,
I am trying to build an algorithm that transforms pictures (all taken
from the same viewpoint) into their corrected-for-perspective
equivalents.
In the GIMP, I can apply the desired perspective transformation to an
image and retrieve the required transform matrix (it is {{0.485,
-0.374, 178}, {0, 0.45, 0}, {0, 0, 1}}, reading rows). (See
http://www.rodo.nl/input.jpg and http://www.rodo.nl/result.jpg for
input image desired output, respectively).
However, when I use this transformation matrix in my own code, I get
strange results, even using the function gimp_matrix3_transform_point
from gimpmatrix.c. See http://www.rodo.nl/error.jpg for the output I
receive. To compute a transformed coordinate (x', y') I simply multiply
(x, y, 1) by the transformation matrix that GIMP shows, dividing both
x' and y' by w' (the third value in the vector that is a result of that
multiplication) in order to switch back to non-homogenuous coordinates.
Is there a bug in generating the transformation matrix, or should I
interpret it differently? The function I wrote to compute a new
coordinate based on an old one and the transformation matrix seems to
work, since it yields the exact same results as does
gimp_matrix3_transform_point().
I hope that someone can help me interpret GIMP's transformation matrix.
Regards,
Willem Vervuurt
The Netherlands
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp save for web
Hi, Save for web plug-in is getting closer to usable state (version 0.18.0 so far). (For those, who got 0.15 version please update to recent, as it had saving bug.) The plug-in now has most of the stuff that has been suggested as improvement on this mailing list. Most important is that previews update much faster and it is much more comfortable to experiment (but I am not sure if this wouldn't cause problems on slow PCs) BTW, It could be good time to discuss how far it is from vision of GIMP user top request number seven. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with perspective transform matrix
Hi Willem, However, when I use this transformation matrix in my own code, I get strange results, even using the function gimp_matrix3_transform_point from gimpmatrix.c. It looks like you are applying the transform in the wrong direction... To compute a transformed coordinate (x', y') I simply multiply (x, y, 1) by the transformation matrix that GIMP shows In that case, I think that the transformation converts the destination coordinate to the corresponding source coordinate. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with perspective transform matrix
Hi David, thanks for your input. I have already tried that, but it is not the case. Your suggestion is equal to using exactly my method but with an inverted transformation matrix (I have implemented this to make sure, see http://www.rodo.nl/error_inv.jpg for the output generated after switching source -- destination). Something more complicated must be going on... Regards, Willem David Hodson wrote: Hi Willem, However, when I use this transformation matrix in my own code, I get strange results, even using the function gimp_matrix3_transform_point from gimpmatrix.c. It looks like you are applying the transform in the wrong direction... To compute a transformed coordinate (x', y') I simply multiply (x, y, 1) by the transformation matrix that GIMP shows In that case, I think that the transformation converts the destination coordinate to the corresponding source coordinate. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xHTML+CSS importer plugin
/gg wrote: These are just assumptions you are making , not a standard of any kind. They are not just assumptions: a DIV without class or ID or style is impossible to be visually formatted. So a clean div is just for conceptual delimitation. A DIV with one of those attributes can be -or not- visually formatted, so it depends on which css styles are applied. If you read the css information you can easily realize which are visual blocks and which are not. And about the standard thing, just refer to the W3C's Visual Formatting Model. There you can get information on which css attributes should be considered or not. It is a good idea in itself but since there is no fixed way this will be implemented by any web designer it's far too vague to start writing a plug-on for. If most of the web designers out there don't follow the standards, it doesn't make my suggestion too vague. Is a standard procedure. If programs like dreamweaver or even NVU skip the standards trying to make a user friendly program doesn't mean that those standards don't exist. This seems firmly outside what gimp has decided to be as an image editor. That's why I suggest a plugin. It seems that many people asked for slicing (which isn't a standard or a fixed way to design either, because there is no fixed ways to make things in design in general) as a core function of Gimp. I'm aganist it. So I suggested that xHTML+CSS importer plugin as an interesting approach for a similar use, but as an external, optional function. I'm not saying it's a must-be and Gimp must have it by default. It's just an idea. Thank you for your comments. Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xHTML+CSS importer plugin
Original-Nachricht Datum: Tue, 29 May 2007 12:27:39 -0300 Von: Guillermo Espertino [EMAIL PROTECTED] An: [EMAIL PROTECTED], gimp-developer@lists.XCF.Berkeley.EDU Betreff: Re: [Gimp-developer] xHTML+CSS importer plugin /gg wrote: These are just assumptions you are making , not a standard of any kind. They are not just assumptions: a DIV without class or ID or style is impossible to be visually formatted. nitpick You can still reach it via adjacent sibling, child or descendant selectors, or - if it does have any other attribute - an attribute selector. /nitpick Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 56, Issue 31
Michael wrote: nitpick You can still reach it via adjacent sibling, child or descendant selectors, or - if it does have any other attribute - an attribute selector. /nitpick Ouch! Yes, you're right! It's not impossible :-) But even in that situation it would be readable in the css stylesheet. I'm trying to imagine a situation where it wouldn't be parseable. Good point, anyway. The plugin should parse every div in the document and use the css information to decide which div is used for visual formatting. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with perspective transform matrix
Hi,
On Tue, 2007-05-29 at 14:50 +0200, Willem Vervuurt wrote:
I am trying to build an algorithm that transforms pictures (all taken
from the same viewpoint) into their corrected-for-perspective
equivalents.
In the GIMP, I can apply the desired perspective transformation to an
image and retrieve the required transform matrix (it is {{0.485,
-0.374, 178}, {0, 0.45, 0}, {0, 0, 1}}, reading rows). (See
http://www.rodo.nl/input.jpg and http://www.rodo.nl/result.jpg for
input image desired output, respectively).
I think you are making the wrong assumption that the perspective
transform tool would apply an affine transformation which can be
expressed as a 3x3 matrix. You probably know these matrices for example
from SVG files. The transformation performed by the Perspective
transform tool is however not necessarily an affine transformation. It
uses a 4x4 matrix. Only the upper left 3x3 submatrix 3x3 is displayed
because the other values are always 0.0 or 1.0.
Sven
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Quick mask malfunctioning on grayscale pictures
Hi, On Tue, 2007-05-29 at 12:52 +, Vladimir Savic wrote: I think this is a bug. If not, then it's a serious application design issue. Shift+Q on grayscale pictures ignores color setup for quick mask. Default red appears as mid intensity gray which makes this great functionality useless on most occasions (for mottled pictures almost always). Any thought or should I go for filling a bug report?! Of course you could file a bug report but we would appreciate if you could also try to fix the issue and provide a patch. I very much doubt that someone else will find the time to fix it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Quick mask malfunctioning on grayscale pictures
Hi, thinking about it, I don't think it can be fixed. Quick Mask is just a UI shortcut for using a channel. And a grayscale image can only have grayscale channels. So if you filed a bug report for this, we would probably have to close it as WONTFIX. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Quick mask malfunctioning on grayscale pictures
Hi, On Tue, 2007-05-29 at 21:30 +, Vladimir Savic wrote: Workaround is really easy, anyway: Find average pixel value for particular picture and give quick mask some high contrast gray value. Simple... Except that, as outlined already, quickmask is just a user interface to channels. And as long as we don't have spot color channels, it doesn't make sense to allow non-grayscale channels in a grayscale image. The simple workaround is really to convert the image to RGB mode. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp save for web
AJ Hi, AJ Save for web plug-in is getting closer to usable state (version 0.18.0 AJ so far). (For those, who got 0.15 version please update to recent, as AJ it had saving bug.) AJ The plug-in now has most of the stuff that has been suggested as AJ improvement on this mailing list. Most important is that previews AJ update much faster and it is much more comfortable to experiment (but AJ I am not sure if this wouldn't cause problems on slow PCs) AJ BTW, It could be good time to discuss how far it is from vision of AJ GIMP user top request number seven. AJ ___ AJ Gimp-developer mailing list AJ Gimp-developer@lists.XCF.Berkeley.EDU AJ https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Integrating slice plugin with save for web would simplify a lot of webdesigner work. Anyway it is long expected feature and it looks like Gimp moves forward. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Announce Scribus 1.3.4 - Open Source Page Layout
The Scribus Team is pleased to announce the release of Scribus 1.3.4 Антон Almost one year in the making, this release brings Scribus to a new plateau in professional print capabilities, innovative features and a completely re-written text layout engine. Among the major new features in 1.3.4: * A rewritten preview mode which allows designers and artists to view layouts on screen as readers with color viewing deficiencies would view a document. Thus, this enables a designer to avoid color combinations which affect legibility. * Major additions to TIFF/PSD support. This includes the ability to use clipping paths in TIFF and PSD files to allow text wrapping.In addition, Scribus now can import special flavors of EPS exported from Photoshop known as Desktop Color Separations (version 1.0 and 2.0). Layers, blend modes, Duo,Tri and Quadtone PSD files are now also supported. * The new styles and text capabilities include style inheritance for paragraphs, character styles and line styles. This is now managed by a new style manager palette. * The new text layout engine has a multitude of enhancements for vastly better more appealing justification, including the use of optical margins and more sophisticated word spacing algorithms. *New pre-press capabilities including, registration marks, crop marks, calibration bars and document meta info. These are all easily managed within the print and PDF export dialogs. * Color management enhancements including better CMYK CMYK conversions. * A rewritten and more capable Scrapbook * Support for patterns; both bitmap and vector * A more capable Align and Distribute Palette * Extended Multiple Copying *New transparency features including blend modes for layers and individual objects * A new cross-platform Icon set from the Tango Project Detailed release notes: (EN) http://www.scribus.net/releases/1.3.4/Scribus-1.3.4.EN_releasenotes.pdf (DE) http://www.scribus.net/releases/1.3.4/Scribus-1.3.4.DE_releasenotes.pdf Downloads: Source and some rpms: http://sourceforge.net/project/showfiles.php?group_id=125235 Upstream Debian/Ubuntu repo: http://debian.scribus.net Ubuntu users are advised to see: http://wiki.scribus.net/index.php/Getting_Scribus_on_Ubuntu/Kubuntu_up_and_running Fedora 5/6 RPMS: http://software.opensuse.org/download/home:/mrdocs/Fedora_Extras_6/repodata/ http://software.opensuse.org/download/home:/mrdocs/Fedora_Extras_5/repodata/ Opensuse RPMS 10.0, SLE 10,10.1,10.2: http://software.opensuse.org/download/home:/mrdocs/ MacOSX: http://aqua.acribus.net Windows 2000/XP: http://windows.scribus.net The Scribus Team would also like to thank - Anduin.net/Øverby Consulting and Cardia AS for their continued hosting of all of the Scribus websites. The Scribus Team would also like to thank the many end users, translators, testers and contributors who helped us with this release. In particular, Christoph Schäfer for his extensive testing and bug reporting throughout 1.3.4's development. About Scribus Scribus is a cross-platform open source page layout application with a focus on high quality commercial grade PDF and postscript export. Originally developed on Linux, Scribus now runs natively on MacOSX, OS/2, many forms of Unix and Windows 2000/XP. Underneath the modern and user friendly interface, Scribus supports professional publishing features, such as CMYK color, spot colors, separations, ICC color management and versatile PDF creation. Scribus was the first page layout application on the planet to directly support PDF/X-3 output, a rigorous ISO standard. Scribus did so by almost a year. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Quick mask malfunctioning on gray scale pictures
On Tuesday 29 May 2007 19:37:55 Sven Neumann wrote: Hi, On Tue, 2007-05-29 at 21:30 +, Vladimir Savic wrote: Workaround is really easy, anyway: Find average pixel value for particular picture and give quick mask some high contrast gray value. Simple... Except that, as outlined already, quickmask is just a user interface to channels. And as long as we don't have spot color channels, it doesn't make sense to allow non-grayscale channels in a grayscale image. The simple workaround is really to convert the image to RGB mode. True! :) Funny but true... Seems like I always see harder way to achieve something... :) Thanks, Vladimir Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
