It would be great if image filters were non-destructive so that the original image was still kept intact/around and could be restored, similar to when we crop or set the graphics mode (grayscale, white/black, watermark) of an image.
Sounds like another enhancement for the UX Team.
@Jay, OK--flesh it out. I think native handling is all filter parsed BMP/DIB, and originals are held--but then either deleted when replaced with "processed" image. Performance and size issues to do this across LibreOffice. Would not want to leave it enabled for all sessions. We already "loose" too many images. So, how would you see this working in the UI? A Tools -> General toggle, a toggle in the Image dialog?
If you will only store the information, that a filter has to be applied, you need an addition to the ODF standard.
I believe the only viable solution is to keep the original image and process the filter on it in the same way that graphics mode/brightness/contrast work. It would be integrated into the image toolbar so users could change between the filters and it would also be in the image tab of the image dialog or a new tab would be added to handle settings for filters, graphics mode, brightness, contrast, colors, and gamma.
(In reply to Regina Henschel from comment #3) > If you will only store the information, that a filter has to be applied, you > need an addition to the ODF standard. Would an addition to the ODF standard be needed, if we stored both the original and filtered versions, and that the filtered version needs to be displayed?
Or could be just extend the graphics mode setting?
Jan Philips: It is possible to store two images for the same object. That is currently done with svg graphics. The file contains an additional png graphic, so that other applications, which cannot read svg, can use the png version of the graphic. But I'm not sure how to keep the information about the filter. The filter 'watermark' for example is stored in an attribute draw:color-mode. That attribute has a fixed list of names. The color adjustments like 'red' are stored in dedicated attributes, 'draw:red' for example. There exists an attribute draw:filter-name, but I do not know, what the purpose of that attribute is. The text in ODF part 1, section 19.170 draw:filter-name is "The draw:filter-name attribute specifies the implementation-dependent filter name that has been used to load an image into the document." Perhaps Thorsten knows, whether this is meant to be a graphic filter or a file format filter. I find no place in LibreOffice where the attribute draw:filter-name is used.
(In reply to Regina Henschel from comment #7) > Jan Philips: It is possible to store two images for the same object. That is > currently done with svg graphics. The file contains an additional png > graphic, so that other applications, which cannot read svg, can use the png > version of the graphic. Yes there is a benefit of storing an image version of an svg or 3d model (the new ones introduced in impress) so other applications can show a preview if it when its unable to render the svg or 3d model, but in this case i dont think there is a benefit to storing an image of an image, but thanks for the info. :D > But I'm not sure how to keep the information about the filter. The filter > 'watermark' for example is stored in an attribute draw:color-mode. That > attribute has a fixed list of names. The color adjustments like 'red' are > stored in dedicated attributes, 'draw:red' for example. From my searching online, it seems that draw:color-mode has the fixed list of greyscale, mono, standard, and watermark. And it would be nice to extend this list to support a few more modes available in MSO including sephia, black/white 25% and black/white 75%. > There exists an attribute draw:filter-name, but I do not know, what the > purpose of that attribute is. The text in ODF part 1, section 19.170 > draw:filter-name is "The draw:filter-name attribute specifies the > implementation-dependent filter name that has been used to load an image > into the document." Perhaps Thorsten knows, whether this is meant to be a > graphic filter or a file format filter. I find no place in LibreOffice where > the attribute draw:filter-name is used. Yes it would be great to find out if there is already an ODF specification that we can use to implement the image filter with. According to ( http://blogs.msdn.com/b/brian_jones/archive/2008/03/25/can-i-mention-that-it-s-also-in-odf.aspx ) "... the draw:filter-name attribute can represent the filter name of the image. This attribute contains the internal filter name that the office application software used to load the graphic." According to ( https://issues.oasis-open.org/browse/OFFICE-3464 ) "The draw:filter-name attribute specifies the implementation-dependent filter name that has been used to load an image into the document.".
Was messing around in google docs and noticed they had a recolor option for negative, which i thought was interesting, as basically its just an inverted grayscale.
(In reply to Regina Henschel from comment #7) > There exists an attribute draw:filter-name, but I do not know, what the > purpose of that attribute is. The text in ODF part 1, section 19.170 > draw:filter-name is "The draw:filter-name attribute specifies the > implementation-dependent filter name that has been used to load an image > into the document." Perhaps Thorsten knows, whether this is meant to be a > graphic filter or a file format filter. > That's a graphic filter name, see style:filter-name and it's remnants in the code. But this all appears very stale, might be even worth deprecating. I would though not recommend to reuse it for the use case here, i.e. pixel filters.
So we need to come up with a new ODF extension for pixel filters (maybe draw:pixel-filter) and extend draw:color-mode with some new entries (sephia, black/white 25%, black/white 75%, negative).
We already use svg for some things - I would just take a look at SVG 1.1 filter [1] for filters and compare if they cover everything (I think they do). With feColorMatrix for example you can do anything you want with colors which covers all the color modes (and more) and feConvolveMatrix should cover most of our Bitmap filters. Also consider that we would need to support this for SVG sooner or later. [1] http://www.w3.org/TR/SVG/filters.html
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Old ticket without new input. Let's resolve as WF- there are plenty of better suited tools for images modification.