Re: [Gimp-developer] babl roadmap
The planned architecture as outline in babl/docs/roadmap.txt will likely collapse under its own weight. If the devs are determined to pursue this course to the bitter end, here are some considerations regarding encoding trc_gamma as double (you really can't do this): //begin quote from the babl roadmap double trc_gamma /* makes sense to have it even if not initially used */ );//end quote ICC RGB working space profile Tone Reproduction Curve information (TRC) can't be held in one double variable unless the TRC really is a true gamma TRC. Some ICC RGB working space profiles have true gamma TRCs. Some ICC RGB working spaces have point curve TRCs specified by varying numbers of points. Some ICC RGB working spaces have TRCs that are specified using parametric curves, which take five parameters. Given that not all profile TRC information can be stored in one double variable, you might consider removing the trc_gamma variable from babl_define_named_rgb_space. A proper TRC retrieving function could be written later, if/when you want to make use of the information. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ 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] Plugins
On 12/10/2014 1:59 AM, пользователь MrCharliemcd wrote: I am a Gimp user trying to find a way to create a plugin for DAZ Studio 4.6 DAZ offers Studio and a Photoshop plugin for free. Is there any way to make one for Gimp, or can Gimp even handle 3D like Photoshop? You need to look for any available documentation on how to provide a link between GIMP and DAZ Studio. The information would likely be found in the SDK of DAZ Studio (if they have one). It could be useful to have a link between DAZ and GIMP to make it easier to experiment with textures on items. -- Cheers! Kevin. http://www.ve3syb.ca/ |Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful! #include disclaimer/favourite | --Chris Hardwick ___ 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] babl roadmap
The sRGB as PCS architecture outline in babl/docs/roadmap.txt will likely collapse under its own weight. The roadmap should be amended to reflect a more accurate assessment of the amount of work the planned architecture will entail. The babl roadmap says: Babl currently only supports formats using the sRGB primaries, quite a few editing operations including gamma adjustments and multiply compositing relies on the chromaticities of the space used, permitting at least linear formats with other chromaticities is highly desirable As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start: Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL Colors/Alien Map RGB Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' enhance green formula) Colors/Desaturate average Colors/Desaturate lightness Colors/Mono Mixer (except Luminosity-based BW conversions) Colors/Posterize Colors/Threshold Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels Auto Pick (used for white balancing images) Filters/Artistic/Cartoon Filters/Edge Detect/Sobel Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise Filters/Noise/RGB Noise Filters/Artistic/Soft glow Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn Layer blend Mode/Color Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide Layer blend Mode/Dodge Layer blend Mode/Hard light Layer blend Mode/Hue Layer blend Mode/Lighten only Layer blend Mode/Multiply Layer blend Mode/Overlay Layer blend Mode/Screen Layer blend Mode/Saturation Layer blend Mode/Value In addition, Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value. The babl roadmap should be amended to include all of the above-listed operations as requiring special-casing in the sRGB as PCS architecture. More than half of the approximately 85 operations that I did check are chromaticity-dependent when performed on linear RGB data. Someone should check all editing operations. You can skip all strictly ADD/SUBTRACT-based operations, including scaling and gaussian blurs. The roadmap says permitting at least linear formats with other chromaticities is highly desirable. It is unclear why permitting should be limited to linear formats. All of the operations listed above depend on the working space chromaticities, regardless of whether the RGB values are linear or perceptually uniform. Indeed, some (and probably many) operations, that work just fine on linear unbounded sRGB values, are *very* dependent on the chromaticities when performed on perceptually uniform RGB values (for example drawing a gradient). Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned sRGB as PCS architecture. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ 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] [Gegl-developer] babl roadmap
On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: The sRGB as PCS architecture outline in babl/docs/roadmap.txt will likely collapse under its own weight. The roadmap should be amended to reflect a more accurate assessment of the amount of work the planned architecture will entail. The babl roadmap says: Babl currently only supports formats using the sRGB primaries, quite a few editing operations including gamma adjustments and multiply compositing relies on the chromaticities of the space used, permitting at least linear formats with other chromaticities is highly desirable As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start: The place for this would be in the GIMP wiki; where the state of migration from old type gimp plug-ins to GEGL ops, as well as other tracking state of ops are maintained. http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL The roadmap says permitting at least linear formats with other chromaticities is highly desirable. It is unclear why permitting should be limited to linear formats. All of the operations listed above depend on the working space chromaticities, regardless of whether the RGB values are linear or perceptually uniform. This has to do with which capabilities one chooses to implement early, since it would bring a functional system, the non sRGB TRC are nice to have but not as fundamental as custom chromaticities. Not having custom TRCs for custom formats; means that those formats would be using the sRGB TRC until such support would be added. Indeed, some (and probably many) operations, that work just fine on linear unbounded sRGB values, are *very* dependent on the chromaticities when performed on perceptually uniform RGB values (for example drawing a gradient). Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned sRGB as PCS architecture. The per-op working pixel representation are part of GEGLs design, thus it isn't really special casing - but specifying. /Ø ___ 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] [Gegl-developer] babl roadmap
On 10/13/2014 03:25 PM, Øyvind Kolås wrote: On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start: The place for this would be in the GIMP wiki; where the state of migration from old type gimp plug-ins to GEGL ops, as well as other tracking state of ops are maintained. http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL It's OK with me if you put the information in the GIMP wiki. But if you attribute the information to me, please include the disclaimer that I think your architecture will eventually collapse under its own weight. Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned sRGB as PCS architecture. The per-op working pixel representation are part of GEGLs design, thus it isn't really special casing - but specifying. You designed an architecture around converting images to unbounded sRGB for editing. After 6 months of trying to show you that your architecture has serious built-in problems, you finally believe me, or at least you believe Mansencal and Sayre. But you want to keep the architecture anyway. So now all chromaticity-dependent editing operations will require a brand new special specifying, unless the image is already an sRGB image. If you didn't intend to convert all images to unbounded sRGB for editing, there wouldn't be any reason to special specify roughly half of all the editing operations that you offer through the GIMP UI. With respect, Elle Stone -- Some operations that require special specifiying, assuming linear encoding: Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL Colors/Alien Map RGB Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' enhance green formula) Colors/Desaturate average Colors/Desaturate lightness Colors/Mono Mixer (except Luminosity-based BW conversions) Colors/Posterize Colors/Threshold Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels Auto Pick (used for white balancing images) Filters/Artistic/Cartoon Filters/Edge Detect/Sobel Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise Filters/Noise/RGB Noise Filters/Artistic/Soft glow Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn Layer blend Mode/Color Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide Layer blend Mode/Dodge Layer blend Mode/Hard light Layer blend Mode/Hue Layer blend Mode/Lighten only Layer blend Mode/Multiply Layer blend Mode/Overlay Layer blend Mode/Screen Layer blend Mode/Saturation Layer blend Mode/Value Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value. ___ 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] babl roadmap: How do you know which images are sRGB images?
According to the babl roadmap, sRGB images won't need special-case treatment. But every time the user opens an image that isn't an sRGB image, special-case treatment will be required for chromaticity-dependent editing operations. How do you plan to tell when an image is an sRGB image and when it's not an sRGB image? With respect, Elle Stone ___ 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
