Re: [Gimp-developer] Gaussian/Tileable blur: Choice of IIR and RLE still necessary?

[Øyvind Kolås]

> So, maybe the disctinction will be still necessary when GIMP 2.10 is out --
> however, the existing Gaussian blur GEGL plug-in  does not offer any
> choice in algorithm

A choice in algorithm is however made internally. The choice depends
on the radius of the blur.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gaussian/Tileable blur: Choice of IIR and RLE still necessary?

[Joao S. O. Bueno]

On 31 August 2012 22:11, Liam R E Quin  wrote:
> On Thu, 2012-08-30 at 11:49 +0200, gg wrote:
>
>> "With modern computers" argument is countered by "on modern images". As
>> the hardware gets faster the images also get bigger ( in both x and y) .
>> As gimp progresses to higher bit resolutions any difference may become
>> more relevant not less.
>
> I just compared the two methods and found RLE tool about 10 or 11
> seconds and IIR took maybe 19 seconds on the same image with the same
> radius (2.5p I think).
>

So, maybe the disctinction will be still necessary when GIMP 2.10 is out --
however, the existing Gaussian blur GEGL plug-in  does not offer any
choice in algorithm

  js
 -><-

> Liam
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
> Co-author, 5th editoin of "Beginning XML", Wrox, July 2012
>
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gaussian/Tileable blur: Choice of IIR and RLE still necessary?

[Liam R E Quin]

On Thu, 2012-08-30 at 11:49 +0200, gg wrote:

> "With modern computers" argument is countered by "on modern images". As 
> the hardware gets faster the images also get bigger ( in both x and y) . 
> As gimp progresses to higher bit resolutions any difference may become 
> more relevant not less.

I just compared the two methods and found RLE tool about 10 or 11
seconds and IIR took maybe 19 seconds on the same image with the same
radius (2.5p I think).

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Co-author, 5th editoin of "Beginning XML", Wrox, July 2012

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Speak Selection Errors

[Patrick Dreier]

Hello!

You have Gimp Speak Selection setup Errors English. The Selection of 
Gimp Setup is not in french.
When selection Windows Setup french langugues in Gimp selection Setup 
englisch .


With king regards!
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Guillermo Espertino (Gez)]

El 31/08/12 17:46, Tobias Ellinghaus escribió:

BTW, all this legacy stuff seems to go against the product vision.
Making a tool for a specific audience means some compromises, and this
is certainly a compromise that "high-end image manipulation" audience
wouldn't mind.

Especially these people will be upset if their older work can't be opened and
edited any longer. It's not the kiddies doing animated sigantures for web
forums that the developers care about, it's the serious users which are the
target in the product vision. And having several versions of GIMP installed in
parallel is no option for them. I guess you are beating a dead horse here.

Nobody said that it wouldn't be possible to open or edit old files. The 
problem here is appearance.
If you open a layerer composite in linear space it will look different 
than the same composite blended in gamma space.
Some blending modes look almost the same, some of them don't. It also 
depends on the image. The effects of linear compositing would be more 
visible in some cases and almos unnoticeable in others.
So, what I proposed was just using linear space for blending for 
everything (including old files) and offering an optional projection or 
"bake" mode for keeping the old appearance as close as possible. And 
that can come later.
It seems pointless to keep legacy code to take care of the old stuff and 
complicate things just to be able to manage a handful of old files.


I think I can consider myself a high end GIMP user and not a kiddy doing 
animated signatures. I'm discussing about making GIMP a high end tool, 
which probably involves in some point getting rid of the low-end legacy.
It's a compromise, sure. But nothing keeps GIMP from getting a mechanism 
for importing and displaying legacy files later, on top of a sane and 
high-end pipeline.


Gez.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Compile module like display-filter-lcms.c

[Elle Stone]

On 8/31/12, Jon Nordby  wrote:
> On 31 August 2012 17:39, Elle Stone  wrote:
>> What's the right way to compile a module such as display-filter-lcms.c?
>
> The build of the in-tree modules is already set up in automake. Just
> change the file after having compiled GIMP without modifications, and
> run "make" (and "make install").

Jon, thanks! That worked perfectly.
Elle
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Tobias Ellinghaus]

Am Freitag, 31. August 2012, 22:16:50 schrub Guillermo Espertino (Gez):

[...]

> BTW, all this legacy stuff seems to go against the product vision.
> Making a tool for a specific audience means some compromises, and this
> is certainly a compromise that "high-end image manipulation" audience
> wouldn't mind.

Especially these people will be upset if their older work can't be opened and 
edited any longer. It's not the kiddies doing animated sigantures for web 
forums that the developers care about, it's the serious users which are the 
target in the product vision. And having several versions of GIMP installed in 
parallel is no option for them. I guess you are beating a dead horse here.

>   Gez

Tobias


signature.asc
Description: This is a digitally signed message part.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP 1.8.2 for Mac (official?) Build

[Michael Natterer]

On Wed, 2012-08-29 at 22:57 +0200, Simone Karin Lehmann wrote:
> Am 28.08.2012 um 10:08 schrieb Michael Natterer :
> 
> > On Mon, 2012-08-27 at 22:02 -0600, Clayton Walker wrote:
> >> 
> >> 
> >> https://dl.dropbox.com/u/942685/gimp-2.8.2-dmg-1.dmg
> >> 
> >> If someone could just mirror that on the gimp ftp website, or upload it to
> >> sourceforge or something, that would be great. Thanks!
> > 
> > Great! :)
> > 
> > I have uploaded it to ftp.gimp.org and updated the download page
> > on www.gimp.org.
> > 
> > Thanks Clayton for the effort to make this happen!
> > 
> > Regards,
> > --mitch
> > 
> 
> 
> aha, so I'm kicked out. 

No you are not, this was never anyone's intention.

I have put the links to your installers back now, removing them
was neither friendly nor smart, sorry for that.

About the general issue: Clayton came to IRC and offered to
work on a native build. Having such a build was a goal for
a long time, and we will never fix the remaining issued without
finally going forward by releasing one.

This was not in any way meant as a hostile move against you,
we always appreciated your work, and still do.

The issue is probably that most stuff takes place on IRC,
so this "just happened". Developer time on GIMP is very
limited, and the issue of a native build was just not
pressing enough to publically ask for help on gimp-developer,
and the help on IRC came without any effort.

Again, we would really like you to stay with the GIMP
community, and perhaps even come to IRC so we can work
on proper OSX packages together.

It would really suck to lose a valuable hacker over
such an unintentional incident.

Regards,
--Mitch


> Why without prior notice, after four years I've maintained the GIMP builds 
> for Mac OS X? Why has nobody asked me why I didn't build a, as you call it, 
> 'native' version? Do you really think I wasn't able to build a version which 
> doesn't depend on X11?
> 
> It's never been about building, that's quite easy. It's all about having a 
> well working version of GIMP.
> 
> The now official Mac build still has the usability glitches, which prevented 
> me to release such a version of GIMP: plugin dialogs pop up behind the main 
> windows. 
> 
> Oh, BTW, the color picker doesn't work well, screenshots fail, no support for 
> scanners or digital cameras, the help system doesn't work, even accessing the 
> online manual fails. OTOH, pressure sensitivity for graphic tablets seems to 
> be fixed. (where can I get the source code patches? I can't find them in git.)
> 
> But, back to the main topic. What's the advantage of a so called 'native' 
> build? The menu bar at the top? Not using X11? From this point of view, even 
> most Linux versions aren't native. Or does a 'native' version magically solve 
> all kind of problems? Is it about toolkits or software layers? Is GTK+ native 
> and XQuartz not? Is the cairo quartz backend a native OS X feature or just 
> another kind of software layer between the application and the OS X graphical 
> libraries and routines? 
> 
> IMO a native version of an application is more than only the use of a 
> specific toolkit or software layer. IMO a native application should use 
> standard native functionality. And yes, the menu bar at the top is one. But 
> does your 'native' version use the native OS X file dialog, the native print 
> functionality and dialogs, or does it use native ColorSync. No. Or new 
> security features like Gatekeeper. No.
> 
> And even further, having your targeted user audience in mind, the official 
> build lacks functionality Mac users got used to in the past  years: a set of 
> plugins offering advanced photo retousching and workflow, locally installable 
> user manuals, support for various OS versions and architectures.
> 
> Anyway, now that you're providing an official Mac version of GIMP, I'm quite 
> sure that you will give all of these to your Mac users soon, or point them to 
> resources where they can easily get it.
> 
> Finally, although I'm very disappointed about the current situation, I had a 
> great time being part of the open source community and I'd like to say thanks 
> to all of you for all your lovely mails and your supportive feedback I've 
> received from all over the world in the past few years. Thank you.
> 
> Now, dear GIMP team, ...
> 
> so long, and thanks for all the fish.
> 
> 
> Simone Karin Lehmann
> http://gimp.lisanet.de
> 
> 
> 
> 
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Guillermo Espertino (Gez)]

El 31/08/12 16:12, Simon Budig escribió:
Well, it is not just about compatibility, it is also about trust of 
our userbase.


My question is:
a) Does the existing userbase actually care about it?
b) Wouldn't doing a relevant change like that, but communicating it 
properly wouldn't be enough to avoid problems and keep users happy? (if 
such thing is possible :p)


GIMP has many users, but if you look for artists or designers using it 
for complex artwork the list is rather short, and probably that kind of 
artists will prefer linear blending because it does look better (just 
place a blurred gray circle on a magenta background in gamma and linear 
spaces and ask people which looks better, I bet no one will choose gamma).


I think it's about communication. If GIMP ditches gamma blending, but 
every time you open an old file you get a notice saying that layer modes 
appearance might change, and it is documented clearly that this change 
was made for the better, I doubt anyone will feel betrayed by developers.


And if there's a strategy to "bake" the old look into a layered or 
flattened image, then nobody will complain.
I'm asking some friends about this, and everyone seems to be fine with 
an importer that warns about the appearance chance and offers the 
alternative of baking the appearance losing some editability.
I'm not saying that asking a few friends is enough, but I'd really like 
to know how other users feel about this.



I think it is important that we do not give the impression that we mess
around with the users data at the whim of the developers. Some people
probably have invested lots of time in complex artwork where it is not
exactly clear what to do to restore the original look, especially if you
don't know where to steer towards.


I think it's about communication. If GIMP ditches gamma blending, but 
every time you open an old file you get a notice saying that layer modes 
appearance might change, and if it is documented stating clearly that 
this change was made for the better, I doubt anyone will feel betrayed 
by developers.


It's like saying: "this is the right way to do it. Our old core didn't 
let us do it this way, but now we can. Now composites will look as they 
should, but perhaps that means that what you created with an old version 
will now look a little different".


And if there's a strategy to "bake" the old look into a layered or 
flattened image, then nobody will complain.
I'm asking some friends about this, and everyone seems to be fine with 
an importer that warns about the appearance chance and offers the 
alternative of baking the appearance losing some editability.
I'm not saying that asking a few friends is enough. I'd really like to 
know how other users feel about this.


Anyway, I wouldn't be so worried about users feeling betrayed. Users do 
that.
A lot of them felt the save/export separation as a betrayal and even 
some of them claim that they won't be using GIMP anymore because of 
that. Some people even complains about the bulky look of the new 
sliders. Some people even complains about the no-image window introduced 
in 2.6 saying the floating toolbox with a menu was better!



Anyway, it probably is not that bad. We already discussed the
possibility of legacy layer modes which would retain the old look but
are basically unavailable or hidden in the layers dialog.

At the same time new layer modes with the old names can be introduced.
I wonder what's the real benefit of doing such thing. Ok, old files will 
be still functional and users will be able to work with them. But at the 
same time it introduces complexity and odd behavior of the application.
For instance, a user may ask why the overlay mode works in that way in 
his old files but not with the new files. If that happens, the user will 
go to the forums, lists or IRC and ask. Somebody will have to answer why.
Somebody will have to answer why untagged 8bpc images and, say AdobeRGB 
8bpc images look different when blended.
It will also mean that some users will create new files from scratch and 
then say "I want to use the legacy-normal mode, why can't I do that?".
Keeping legacy visible will clutter the UI. Hiding it will mean more 
people asking where is it.


It sounds either like a mess or like a lot of hard work to make those 
situations co-exist, and the benefit is still only for the few guys that 
need to open an overly complicated composition made with an old GIMP to 
modify it, keeping the old look.
I'd prefer that all that effort is put on making GIMP a more powerful 
application and I bet that keeping legacy is a huge PITA for developers 
and it's far more interesting and fun to add new features and 
streamlining the application.


BTW, all this legacy stuff seems to go against the product vision. 
Making a tool for a specific audience means some compromises, and this 
is certainly a compromise that "high-end image manipulation" audience 
wouldn't mind.


 Gez
__

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Alexandre Prokoudine]

On Fri, Aug 31, 2012 at 11:12 PM, Simon Budig wrote:

> At the same time new layer modes with the old names can be introduced.

Or you could rename old ones to "foobar-old" and just use "foobar" for
the new ones.

Alexandre Prokoudine
http://libregraphicsworld.org
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Simon Budig]

Guillermo Espertino (Gez) (gespert...@gmail.com) wrote:
> El 31/08/12 14:05, Simon Budig escribió:
> > [compromises in Gimp] so that old
> > XCF files in a new Gimp look the same as always.
> 
> I wonder how much of a big deal would
> be to ditch legacy appearance.

Well, it is not just about compatibility, it is also about trust of our
userbase.

I think it is important that we do not give the impression that we mess
around with the users data at the whim of the developers. Some people
probably have invested lots of time in complex artwork where it is not
exactly clear what to do to restore the original look, especially if you
don't know where to steer towards.

Anyway, it probably is not that bad. We already discussed the
possibility of legacy layer modes which would retain the old look but
are basically unavailable or hidden in the layers dialog.

At the same time new layer modes with the old names can be introduced.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Guillermo Espertino (Gez)]

El 31/08/12 14:05, Simon Budig escribió:
With your "elimination" of the conversion in util.h you probably have 
introduced visually different results for these kind of operations 
(because e.g. the "addition" mode now adds up in a linear fashion, 
while it earlier worked in Gamma mode). Of course it is debatable how 
certain layer modes are supposed to work, but we also need to maintain 
some backwards compatibility, so that old XCF files in a new Gimp look 
the same as always.


I can only speak as a user, and I'm not sure about how other users feel 
about this, but even after 6 years of GIMP as my main and only bitmap 
manipulation software, I wonder how much of a big deal would be to ditch 
legacy appearance.
Of course several of my old files will look different, but if I think of 
it as a compromise to get a better GIMP, I'm all for it.
If I had to modify old files to make them look right in linear blending, 
it wouldn't be very difficult, and for those cases when getting the same 
results is critical, I still could use GIMP 2.8
Keeping legacy seems like an anchor for any program, and I wonder if 
keeping a legacy version as a separate product wouldn't make more sense 
than leashing the power of GIMP could have and squeezing dev's brains 
and time to get legacy co-existing with the new core.
I also wonder how much of GIMP's userbase uses it for complex composites 
with lots of layers and blending modes. Judging by the forums and 
tutorials out there, probably most of the users wouldn't notice if sRGB 
blending is replaced by linear.


There is a special case, though, that I wanted to leave for the end: 
Using GIMP for web mockups. Web browsers still use gamma blending for 
compositing RGBA images (a png with transparent background, for instance).
It's true that creating mockups in linear space would give different 
results, but that could be solved by adding a special variant of the 
"normal" blending (simple porter-duff alpha-over op) that gamma-corrects 
both inputs, composites them and then linearizes the result.
And maybe it doesn't have to be a special blending mode but a preview 
mode ("web preview" or something like that") that creates a projection 
with every alpha-over done in gamma-corrected space.


Anyway, that seems to be something that can be addressed later.

I'm curious to know how other users feel about this. I'd even suggest to 
comment everything legacy out in 2.10 and see how user community reacts.
If it's too bad for the majority of the users out there, GIMP 2.8 would 
be still an option (I mean, if there are users who chose to stick with 
2.6 because of the save/export thing, they can stick with 2.8 because of 
legacy looks). If nobody cares, happy-happy, joy-joy. :-)


Gez.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Compile module like display-filter-lcms.c

[Jon Nordby]

On 31 August 2012 17:39, Elle Stone  wrote:
> What's the right way to compile a module such as display-filter-lcms.c?

The build of the in-tree modules is already set up in automake. Just
change the file after having compiled GIMP without modifications, and
run "make" (and "make install"). Only the neccesary files will be
recompiled when you do this. I recommend doing the same when working
on the in-tree plugins, or any other part of the GIMP source code.

If the build parameters needs changing, like for building against LCMS
2 instead of 1, I'm afraid you will have to look into the autotools
files (configure.ac and Makefile.am). Read up on autotools on the web,
and ask if you get stuck.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] still missing translation for script-fu, only in some languages

[Joao S. O. Bueno]

On 31 August 2012 12:47, Cristian Secară  wrote:
> The script-fu in stable version is still limited to 61 strings
> (something related to intltool as far as I understand from past
> messages).
>
> But what confuses me is that (for example) the French or German
> script-fu menus are for some reason translated in the final product,
> while at the same time they are missing from http://l10n.gnome.org
> How is that ?

I thought this was a critical bug for the stable branch - but I could
not even find it
on bugzilla  last Thursday (therefore I assumed it was fixed).

Is there an issue open for this?

  js
 -><-

>
> Take a simple example in File -> Create -> Logos ->
> (French)
> -> B_asique II...
> (German)
> -> E_infach 2 …
> However, at http://l10n.gnome.org this string is marked as "deleted" in
> both languages.
>
> For Romanian, in the final product that string is in English ...
>
> Cristi
>
> --
> Cristian Secară
> http://www.secarica.ro
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Jon Nordby]

On 31 August 2012 17:37, Elle Stone  wrote:

> On 8/30/12, Jon Nordby  wrote:
>> This is actually one more conversion and one step earlier than we need
>> to. Ideally the pipeline should look like this:
>>
>> GeglBuffer -> | display filter stack | -> sRGB in monitor profile -> | Cairo
>> |
>>
>> That way we only convert to the monitor profile as a last step. This
>> would require GEGLifying the display filter stack and all the modules
>> it uses.
>
> (I think "sRGB in monitor profile" probably means "sRGB or monitor
> profile". Jon - yes? no?)
Yes.

-- 
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Simon Budig]

Elle Stone (l.elle.st...@gmail.com) wrote:
> The purpose of the constant background converting back and forth
> between two tone curves, sRGB TRC and linear gamma, is not clear at
> all.

Well, it is not on purpose. It is basically a side-effect of trying to
port Gimp to the new infrastructure without e.g. changing the visual
output of e.g. layer modes, while avoiding changing the math (Or do it
in an incremental manner while keeping the results consistent).

> "In service of the noble goal" doesn't explain *why* the conversions
> are done over and over again instead of just once. I really, really,
> really want to know why those relentlessly repeating background
> conversions between sRGB TRC and linear gamma are happening.

Ok, for an example have a look at gimp/app/operations and grep the
string "R'G'B'".

As you can see, a lot of them are designed to work in a R'G'B' mode,
since this was the working assumption in our old 8 bit core. We need
as-identical-as-possible results and the easiest way to port them to
GEGL and adding support for the high-bit-depth modes is to let the
operations work in "R'G'B'A float" and port the math in the most
straightforward way possible.

Now every time some of these operations is involved, the GEGL core needs
to convert the "RGBA u16" data as stored in the image to "R'G'B'A float"
so that the operation can properly work in its expected working format.
And of course before the new data ends up in the pixel storage it needs
conversion back to "RGBA u16".

Of course this is not good and has a massive speed impact, ideally the
operation should be able to work on "RGBA u16" directly, but then the
math becomes nontrivial (we need compatible results). This is
optimization work that we have not even really started tackeling.

I fully expect to have other problems like this on all kinds of
different places and I don't know which of these point it actually is
you're hitting with your test cases.

With your "elimination" of the conversion in util.h you probably have
introduced visually different results for these kind of operations
(because e.g. the "addition" mode now adds up in a linear fashion, while
it earlier worked in Gamma mode). Of course it is debatable how certain
layer modes are supposed to work, but we also need to maintain some
backwards compatibility, so that old XCF files in a new Gimp look the
same as always.

> But I
> will stop asking. And maybe some kind soul will send a private email
> giving an explanation that I can understand.

Please not, keep it on the list. These things are tricky and they
deserve to be pulled into the open  :)

And don't stop asking.

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Tobias Oelgarte]

Am 31.08.2012 18:27, schrieb Elle Stone:

The ultimate goal of working in a linear light color space is both
clear and noble.


I support this. Working in linear light color space has many advantages. 
One of them is the potential speed. The other would be tools that only 
need to work inside one color space.



The purpose of the constant background converting back and forth
between two tone curves, sRGB TRC and linear gamma, is not clear at
all.


At the moment it is also not clear to me. But i guess that it has to do 
with all the legacy code that currently is in the way, because this 
parts haven't been rewritten. I assume that this parts just got a 
wrapper (it does the color conversion, currently every time) to be able 
to work on the core while not making everything unusable.


But if I'm wrong and it should stay like this, then this is a real problem.


"In service of the noble goal" doesn't explain *why* the conversions
are done over and over again instead of just once. I really, really,
really want to know why those relentlessly repeating background
conversions between sRGB TRC and linear gamma are happening. But I
will stop asking. And maybe some kind soul will send a private email
giving an explanation that I can understand.


In the case I'm not lier than i have given the explanation above.


I was excited to find out that the latest LCMS can do color
conversions involving negative floating point numbers. If the Gimp
code is only 20% finished, then perhaps the information I just gave
about the new ability of LCMS to do conversions involving negative
floating point numbers might be pertinent to crafting the remaining
80%. But if not, then I apologize for posting it.

Elle


Lets see what the developers have in mind. If they do it right, then 
there should be two solutions with the empowered to choose which one he 
likes, because both have a distinct advantage and disadvantage:


A) The buffer of any type / color space will be converted at 
load/creation time to linear RGB float. Anything else works only with 
linear RGB float. Final output will be converted to sRGB or device color 
profile.


B) The buffer will be loaded and stored in native/original format. Every 
access to the buffer which is not linear RGB float will force a 
conversion, which might need caching for better speedup. The core still 
works entirely in linear RGB float. and the final output will be 
converted to sRGB or device color profile.


While (A) would be fast it is very memory intensive for larger images. 
The method (B) might be very slow in comparison, but it needs much less 
memory.


Ideally the user would load layers/buffers and would have the choice to 
convert the buffer to any color space/format he likes, with the hint 
that linear RGB float is the fastest that does not need any conversion. 
So the user would have to option if he wants speed or less memory 
consumption.


But maybe someone wants to enlighten me that both things are not 
mutually exclusive.


Tobias
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Elle Stone]

The ultimate goal of working in a linear light color space is both
clear and noble.

The purpose of the constant background converting back and forth
between two tone curves, sRGB TRC and linear gamma, is not clear at
all.

"In service of the noble goal" doesn't explain *why* the conversions
are done over and over again instead of just once. I really, really,
really want to know why those relentlessly repeating background
conversions between sRGB TRC and linear gamma are happening. But I
will stop asking. And maybe some kind soul will send a private email
giving an explanation that I can understand.

I was excited to find out that the latest LCMS can do color
conversions involving negative floating point numbers. If the Gimp
code is only 20% finished, then perhaps the information I just gave
about the new ability of LCMS to do conversions involving negative
floating point numbers might be pertinent to crafting the remaining
80%. But if not, then I apologize for posting it.

Elle

On 8/31/12, Alexandre Prokoudine  wrote:
> On Fri, Aug 31, 2012 at 7:37 PM, Elle Stone wrote:
>> I keep coming back to this question. If your goal is to convert all
>> images to your linear light working space for image processing, why
>> not do the conversion one time and be done with it?
>
> Isn't it what Øyvind defined as a noble goal in his mail few weeks ago? :)
>
> Didn't he also say that the relevant part of code is more like 20%
> done and hence should not be treated as what the team had in mind for
> final design? :)
>
> Alexandre Prokoudine
> http://libregraphicsworld.org
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>


-- 
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] still missing translation for script-fu, only in some languages

[Cristian Secară]

The script-fu in stable version is still limited to 61 strings
(something related to intltool as far as I understand from past
messages).

But what confuses me is that (for example) the French or German
script-fu menus are for some reason translated in the final product,
while at the same time they are missing from http://l10n.gnome.org
How is that ?

Take a simple example in File -> Create -> Logos ->
(French)
-> B_asique II...
(German)
-> E_infach 2 …
However, at http://l10n.gnome.org this string is marked as "deleted" in
both languages.

For Romanian, in the final product that string is in English ...

Cristi

-- 
Cristian Secară
http://www.secarica.ro
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Alexandre Prokoudine]

On Fri, Aug 31, 2012 at 7:37 PM, Elle Stone wrote:
> I keep coming back to this question. If your goal is to convert all
> images to your linear light working space for image processing, why
> not do the conversion one time and be done with it?

Isn't it what Øyvind defined as a noble goal in his mail few weeks ago? :)

Didn't he also say that the relevant part of code is more like 20%
done and hence should not be treated as what the team had in mind for
final design? :)

Alexandre Prokoudine
http://libregraphicsworld.org
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Compile module like display-filter-lcms.c

[Elle Stone]

What's the right way to compile a module such as display-filter-lcms.c?

gimptool-2.0 outputs a gcc command:

gcc  -pthread -I/usr/include/freetype2   -o display-filter-lcms
/usr/local/src/gimp/gimp/modules/display-filter-lcms.c
-Wl,--export-dynamic -pthread -L/usr/local/lib64 -lgimpui-2.0
-lgimpwidgets-2.0 -lgimpmodule-2.0 -lgimp-2.0 -lgimpmath-2.0
-lgimpconfig-2.0 -lgimpcolor-2.0 -lgimpbase-2.0 -lgtk-x11-2.0
-lgegl-0.2 -lgmodule-2.0 -lrt -lbabl-0.1 -lm -lgdk-x11-2.0 -latk-1.0
-lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo
-lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -llcms

But when I tried to compile, the terminal output complained:

/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/crt1.o: In
function `_start':
/home/abuild/rpmbuild/BUILD/glibc-2.15/csu/../sysdeps/x86_64/elf/start.S:109:
undefined reference to `main'
collect2: ld returned 1 exit status

Compiling all of Gimp takes a half hour on my old, slow machine, so
there has to be a better way to recompile the display-filter-lcms
module.

Thanks in advance if anyone can help,
Elle Stone
-- 
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Elle Stone]

I keep coming back to this question. If your goal is to convert all
images to your linear light working space for image processing, why
not do the conversion one time and be done with it?

I did some preliminary checking. LCMS can do the conversion between
your linear light profile and the monitor profile. At least I think it
can, per this post:

[Lcms-user] negative float clipping and gamma 1.0
http://sourceforge.net/mailarchive/message.php?msg_id=29167076

So it looks like LCMS can now convert from linear gamma built-in sRGB
with negative values to XYZ space. I played with the transicc utility
and sure enough, negative numbers were being transformed from linear
sRGB to XYZ and back. I'm pretty sure any other profile with a linear
gamma TRC will also work.

Assuming the new LCMS capacity works the way I think it does, then you
could use what Jon Nordby described in a previous post to this thread,
and let LCMS take care of sending the properly transformed linear
light information to the monitor display:

On 8/30/12, Jon Nordby  wrote:
> This is actually one more conversion and one step earlier than we need
> to. Ideally the pipeline should look like this:
>
> GeglBuffer -> | display filter stack | -> sRGB in monitor profile -> | Cairo
> |
>
> That way we only convert to the monitor profile as a last step. This
> would require GEGLifying the display filter stack and all the modules
> it uses.

(I think "sRGB in monitor profile" probably means "sRGB or monitor
profile". Jon - yes? no?)

This ability to use negative floating point numbers with a linear
gamma profile (only a linear gamma profile, no other TRC) is a new
LCMS capability. It would not have been around at all when you thought
up your linear light profile, which perhaps MS/HP then "borrowed" from
you. :)

Perhaps the new LCMS capability would eliminate any need for
constantly converting back and forth between sRTB TRC and linear gamma
TRC.

> You should also note that babl's "RGBA float" format is not inspired
> by or defined by scRGB, but could more well be described as a linear
> light / physical color space, with the same RGB primaries as sRGB, a
> linear gamma curve, white at 1.0, 1.0, 1.0 - black at 0,0,0 extendable
> towards the limits of floating point representation negatively and
> positively.

Your choice of white point (1,1,1) is intriguing, being at odds with
the almost universally used D50 white point of
XYZ=(96.420,100.000,82.489), and also the V2 sRGB D65. By the way, the
lcms V4 matrix sRGB profile uses D50, in keeping with the V4 ICC
profile specifications.

Are the primaries for your linear light profile as defined in
babl/extensions/CIE.c?
/* sRGB/HDTV phosphor colours */
static const double pxr = 0.64F;
static const double pyr = 0.33F;
static const double pxg = 0.30F;
static const double pyg = 0.60F;
static const double pxb = 0.15F;
static const double pyb = 0.06F;

If so, I will experiment to see what happens using lcms utility
"transicc" to convert from your linear light space with its unusual
white point, to regular color spaces (including camera and monitor as
well as working spaces), and back.

Just a thought: If your linear space used the identity profile, with
RGB primaries of (1,0,0), (0,1,0) and (0,0,1), I don't think you would
need negative float values to cover the entire 1931 CIE XYZ color
space, conversion computations would be drastically simplified, and
I'm pretty sure you'd have less space devoted to imaginary colors. But
this whole negative floating point values thing for ICC profiles is
new territory to me. I've known about it theoretically for a long
time, but until now never had the wherewithal (the new LCMS
utilities/capabilities) or reason (your linear light color space) to
acquire any practical understanding.

Cheers,
Elle Stone


-- 
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] v2.8.2 copy/paste

[Nik Omul]

Ok, thank you all for replies. I get it now.
I've come to love that accidental_feature/bug :)

Have a great weekend, guys!





-
Nik O.
Никита Омуль
--
View this message in context: 
http://gimp.1065349.n5.nabble.com/v2-8-2-copy-paste-tp35255p35270.html
Sent from the Developers mailing list archive at Nabble.com.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Request for equations for Fractal Trace and QBist

[Mukund Sivaraman]

On Fri, Aug 31, 2012 at 05:08:29PM +0530, Mukund Sivaraman wrote:
> After many iterations, either the point stays close to (x,y), or
> 'escapes' and jumps far away from (x,y).  You should be able to

Corrected:

After many iterations, either the point *coverges at another point*, or
'escapes' and jumps far away from (x,y).


Kind regards,

Mukund
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Request for equations for Fractal Trace and QBist

[Mukund Sivaraman]

Hi Katie

On Thu, Aug 30, 2012 at 10:44:21PM +0100, Katie Harrison wrote:
> Hi, I love using the Fractal Trace and QBist filters, but I wish I could
> apply similar effects to SVG images, so I'd like to (attempt to) write
> Inkscape extensions that do something similar. My problem is that I'm just
> a python developer who can't read c code, so I was wondering if the math
> equations used by these filters are written down somewhere, or if there is
> someone on this list who knows what they are?

For Fractal trace, the method is simple. If you are not familiar with
the Mandelbrot set, first make yourself familiar with it so that you
can write a program to draw it.

http://en.wikipedia.org/wiki/Mandelbrot_set

I see that you are not familiar with C, but here is a small
simplistic program to draw it that you may still be able to follow:

https://banu.com/blog/27/rest-in-peace-mandelbrot/

Once you have understood it, here's how the Fractal trace works. For
every point in the target image (mapped to the set, and in set
co-ordinates) say z = c = (x,y), Fractal trace puts the point through
the equation:

z = z^2 + c

On every iteration, z is a new point in the set. Typically this point
hops around and around the original (x,y).  [The XaoS program has a
nice animated illustration of this in its help section.]

After many iterations, either the point stays close to (x,y), or
'escapes' and jumps far away from (x,y).  You should be able to
determine if you should stop iterating based on the distance of the
current value of 'z' from (x,y), or after 'N' iterations if the point
has not ventured far (and likely won't).  [This is the same type of
escape checking that you'd do when drawing the Mandelbrot set.]

Once you decide to stop iterating, the color of pixel (in image
co-ordinates) corresponding to resulting value of 'z' (in set
co-ordinates) is set as the color of pixel in the target image (in
image co-ordinates) corresponding to the (x,y) point (in
set-coordinates).

This class of operation is called a 'map', as the color of the point
maps to that of another.  Usually some sort of sampling is also
performed around (x,y) (in the domain of the map) to get rid of
aliasing.

That is all. If you have understood how the Mandelbrot set is generated
and are able to write a program to generate it, then doing the Fractal
trace should be straightforward after that.


Kind regards,

Mukund
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] v2.8.2 copy/paste

[Michael Natterer]

On Fri, 2012-08-31 at 13:22 +0400, Alexandre Prokoudine wrote:
> On Fri, Aug 31, 2012 at 1:14 PM, Michael Natterer wrote:
> 
> > The reason why this "worked" in 2.8.0 was because of another bug:
> > switching tabs was not really switching images internally
> 
> Oh right, I remember some curious issues like the list of layers not
> being updated after dragging stuff around.
> 
> No chance for 2.8?

The problem is DND itself: the data is transferred on *drop*,
at which point the layers dialog has switched to the new image
already. I have a way of fixing this, but it's a bit intrusive.
Will have to wait for the patch in master to see how intrusive
the actual code is, and then decide on backporting.

--mitch


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Mac enhancement requests

[kristarella]

Hi,

I was pretty stoked to see there's a native version of GIMP for Mac now.
Thanks for all the hard work!

I have a couple of small requests that I think would go a long way in
making the app more Mac-like and I would be more comfortable recommending
it to people.

One is that the Preference pane be opened with Cmd+, which is the standard
shortcut for mac app preferences.

The second is that the default setting for window management behviour be
'normal' for hints and toolboxes. The first time I ran the app it felt
ridiculously slow and buggy, but it actually wasn't it was just that the
color space warning (to keep or assign the color space) was behind the main
toolbox window, so I thought it was taking ages for my image to open, but I
couldn't see that window, and the same with the PNG export preferences...
my image just wasn't saving, but it was because the
preferences/confirmation window was behind the toolbox. And because the
default behaviour of the toolbox was to be on top all the time I didn't see
these dialogues and they were hard to access.

Thirdly, it would be great if Cmd+` switched between the windows, which is
normal behaviour on mac programs (and GIMP under X11).

Thanks for considering!

Kristen.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] v2.8.2 copy/paste

[Alexandre Prokoudine]

On Fri, Aug 31, 2012 at 1:14 PM, Michael Natterer wrote:

> The reason why this "worked" in 2.8.0 was because of another bug:
> switching tabs was not really switching images internally

Oh right, I remember some curious issues like the list of layers not
being updated after dragging stuff around.

No chance for 2.8?

Alexandre Prokoudine
http://libregraphicsworld.org
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] v2.8.2 copy/paste

[Michael Natterer]

On Fri, 2012-08-31 at 13:06 +0400, Alexandre Prokoudine wrote:
> On Fri, Aug 31, 2012 at 11:16 AM, Nik Omul wrote:
> > Hi,
> > In v2.8.0 you can drag a layer, hover it over other image tab and, when that
> > image opens,
> > drop it down to perform copy_layer/paste_as_new_layer procedure.
> > In v2.8.2 it's not working this way anymore (Windows). Is this a permanent
> > change to GIMP?
> 
> It's a bug. Confirmed on Linux.

It's this one: https://bugzilla.gnome.org/show_bug.cgi?id=676522

The reason why this "worked" in 2.8.0 was because of another bug:
switching tabs was not really switching images internally, this
got fixed, breaking the "accidential" feature you are talking about.

Single window mode was simply never really finished, we'll try
to get it right in 2.10.

--mitch


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] v2.8.2 copy/paste

[Alexandre Prokoudine]

On Fri, Aug 31, 2012 at 11:16 AM, Nik Omul wrote:
> Hi,
> In v2.8.0 you can drag a layer, hover it over other image tab and, when that
> image opens,
> drop it down to perform copy_layer/paste_as_new_layer procedure.
> In v2.8.2 it's not working this way anymore (Windows). Is this a permanent
> change to GIMP?

It's a bug. Confirmed on Linux.

Alexandre Prokoudine
http://libregraphicsworld.org
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] v2.8.2 copy/paste

[Nik Omul]

Hi,
In v2.8.0 you can drag a layer, hover it over other image tab and, when that
image opens,
drop it down to perform copy_layer/paste_as_new_layer procedure. 
In v2.8.2 it's not working this way anymore (Windows). Is this a permanent
change to GIMP? 
Could not find a heads up in last version release notes, no clues in bug
reports or anywhere else. 
Can anybody, please, enlighten me? 


Thank you



-
Nik O.
Никита Омуль
--
View this message in context: 
http://gimp.1065349.n5.nabble.com/v2-8-2-copy-paste-tp35255.html
Sent from the Developers mailing list archive at Nabble.com.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Request for equations for Fractal Trace and QBist

[Katie Harrison]

Hi, I love using the Fractal Trace and QBist filters, but I wish I could
apply similar effects to SVG images, so I'd like to (attempt to) write
Inkscape extensions that do something similar. My problem is that I'm just
a python developer who can't read c code, so I was wondering if the math
equations used by these filters are written down somewhere, or if there is
someone on this list who knows what they are?

Thanks,
K Harrison
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Toy License - Wilber

[Daven Johnson]

To the GIMP Team,

Please see below regarding our interest in a toy license for Wilber. I
attached supplementary files which I believe went to Mukund, I can send
files individually to any who are interested, but I believe the files were
too large to send to the listserve as a whole. Thank you.


Hello Mukund,
>
> Thank you for the information. I have attached a more formal proposal and
> information on my company, but the summary is as follows.
>
> *Product Types (non-exhaustive)*
> *
> *
>
>- *Plush*
>   - 5-6" and/or 8-10" versions of Wilber
>   - Wilber's head only and/or Wilber plus a small body for enhanced
>   "plushiness"
>   - Standard Wilber image as well as Wilber with a beret,
>   construction hat, and wizard hat as rights are available. I believe 
> these
>   rights are currently available via permission licenses, but any
>   clarification would be appreciated.
>- *Vinyl/Resin *
>   - 4-6" mini-figures
>   - Wilber's head only or body
>   - First set would potentially include exchangeable pieces - so
>   beret, construction hat, wizard hat, paintbrush that would be swappable
>   - For other copyrighted "construction kit" props we would also
>   provide further "sets" to be used with the base toy as available, for
>   collectors etc.
>- *Bobbleheads*
>- *Stress Balls*
>
> *The following are terms we are interested in*
>
> * Global license
> * Standard consumer products royalty to GIMP community - 15% of net
> proceeds
> * Exclusivity - If the GIMP team would be open to an exclusive deal, we
> would like to discuss this at higher rates, otherwise we are fine with a
> non-exclusive deal
> * Estimated sales volume - 182,000 units annually, $3M gross revenue -
> catering to core GIMP users as well as general toy and collectible
> collectors outside of your base
> * Verification of sales - as per our other licenses we would provide
> quarterly reports and have standard audit provisions that I presume the
> GNOME Foundation or another representative would have the option to execute
> on annually.
>
> From a partnership standpoint we take on the risk and handle everything
> from toy design through to fulfillment to the end consumer via our website
> and wholesale partnerships.
>
> The following are some of our current brand partners.
>
>- Magicka (Paradox Interactive - www.paradoxplaza.com )
>   - Sold over 1.3M copies worldwide
>- Dungeons of Dredmor (Gaslamp Games - www.gaslampgames.com )
>   - Indie Game of the Year for 2011 from PC Gamer US
>- Zeno Clash (Aceteam - www.aceteam.cl )
>   - PC Gamer's 2009 Independent game of the year
>   - Ranked in 2011 as one of PC Gamer's top 100 games of all time
>- Creature Breeder (virtual pet/pokemon type community)
>
> I hope this provides you enough background and we look forward to
> discussing further.
>
> Best,
>
> Daven
>
> *
> *
> On Sun, Aug 12, 2012 at 11:24 AM, Mukund Sivaraman  wrote:
>
>> > Hello,
>> >
>> > My company develops limited edition toys for a variety of brands - game
>> > companies, communities, etc. and we are interested in making plush toys
>> and
>> > statues of Wilber. We were touching base to discuss any concerns. We
>> would
>> > look to provide a portion of proceeds to the community. If someone were
>> > able to get back to us that would be appreciated.
>>
>> I am interested in selling Wilber and GEGL t-shirts too as part of
>> Banu's new shop.  It seems some GIMP team members want an adult line as
>> well.  ;)
>>
>> Here is my understanding of it:
>>
>> * Wilber (a coyote in case you didn't know) isn't exactly used for
>>   *selling* t-shirts by the GIMP team, but it has been used on t-shirts
>>   and other goodies by the GIMP team. So as it could be construted as a
>>   trademark, you'll have to get permission from the GIMP team depending
>>   on what toy/clothing you want to use it with.
>>
>> * If you want to use a particular drawing of Wilber (there are many,
>>   such as by tigert, jimmac, mattanhan, etc.), you'll *also* have to
>>   get permission from its author as the image is copyrighted.  Some of
>>   these may have been released under permissive licenses, so you'll
>>   have to mention the license in that case, or get a waiver from its
>>   author.
>>
>> Please reply with more details of what your offer is, what proceeds
>> will go to what community, what volume of sales you plan to do, and how
>> we can verify the proceeds against sales.
>>
>> Mukund
>>
>
>
>
> --
>
> *Daven Johnson*
>
> President
>
>
> *ShouldBee*
>
> *www.shouldbee.com*
>
> Phone +1.267.972.4432
>
> Fax +1.240.334.4719**
>
> *Email* daven.john...@shouldbee.com
>
> *LinkedIn* Daven Johnson 
>
>


-- 

*Daven Johnson*

President


*ShouldBee*

*www.shouldbee.com*

Phone +1.267.972.4432

Fax +1.240.334.4719**

*Email* daven.john...@shouldbee.com

*LinkedIn* Daven Johnson