This is a multi-part message in MIME format. --===============0653662228== Content-Type: multipart/alternative; boundary="------------020101070200050208050005" This is a multi-part message in MIME format. --------------020101070200050208050005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > @Boud :what is your problem when trying to compile? Just the problem is I don't know a lot of things about "how to do it" ; I was just a script user of the SVN version. Animtim was nice and sent me keys code lines to do it, but I spent hours without results because folders in 'calligra' are really different than in 'koinstall'. It surely sounds stupid for you :) I will surely try again. If I update using old script of SVN, it will be 2.3.1 ? Thanks for your replies. > @Silvio Heinrich : if gimp really uses just HSV then it is not really > superior. Oh, I really don't know nothing about how and why color modes prefer use HSV or HSL luma , I'm just a digital painter user. The only feedback I can give are with pictures like the previous mail :-) Btw, you are right , my use of 'superior' word needs to be explain : the color mode in Photoshop ( I used it for years too) don't work nicely with yellow/orange tones painting over gray. You obtain only a muddy green/yellowish tones. That's why I called the Gimp one 'superior' ; because if you use it as a painter to recolor a part and like to use yellow or orange ; the Gimp one will be more efficient for this case. That's why I always prefered the way Gimp handle it than Photoshop. Just to defend that the two way are usefull :) and I agree and like if you planed to support more then one color model. Good way ! and thanks for the link. --David On 01/29/2011 01:30 PM, Silvio Heinrich wrote: > Hmm.. ok. I don't know what color model gimp exactly uses for this but > i thought gimp uses HSV. > It would be nice if you could tell me more about the way how gimp does > it (of course only if you know). > But if gimp really uses just HSV then it is not really superior. It's > just a matter what you want to do in which way. > I paint myself (and i'm not too bad i would say :D) and for me the > photoshop way is working much better. > It was not my intend to simply remove something. The other color mode > is still there it's just not in the list. > I actually planed to support more then one color model so krita is > compatible to photoshop and gimp (i also included the "Grain Merge" > and "Grain Extract" modes for this reason). > If you want to know the advantages and disatvantages of HSL and HSV > please read this: > http://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages > Photoshop uses the HSL luma variant. > And as far as i know gimp uses HSV (but please correct me if i'm wrong > and give me some feedback how gimp2.6 is doing it :D) > On 01/29/2011 10:41 AM, David REVOY wrote: >> Hi, >> >> Just to react on this : >>> and "Color" modes work exactly as in Photoshop >> Just to inform the way 'color mode' works in Gimp 2.6 is superior to >> the 'color mode' of Photoshop ( till Cs2 for sure ). >> This can be tested & seen with comparing the same file open like this : >> http://www.davidrevoy.com/XYZ/color-mode_test_GIMP-net.jpg >> http://www.davidrevoy.com/XYZ/color-mode_test_TOSHOP-net.jpg >> useless to say that Gimp color mode is far superior for artist than >> Photoshop. I understand the photoshop one should be proposed for >> compatibility, but for efficiency ; please don't omit one like Gimp. >> I couldn't try it with Krita , btw* >> >> The PSD file if you need to test ( this file can be considered as >> 'public domain' if you need it ) : >> http://www.davidrevoy.com/XYZ/color-mode_test.psd.zip >> ;-) >> >> -David >> ( PS : can't compile since Git or install 2.3 threw PPA , as i'm >> Lucid Lynx LTS user not Maverick ...so I wait kubuntu backport to >> post the bin for Lucid 64bit ) >> >> On 01/28/2011 10:52 PM, Sven Langkamp wrote: >>> On Wed, Jan 12, 2011 at 11:17 PM, Silvio Heinrich >> > wrote: >>> >>> Phew... I think I've gone a bit mad with the blending modes :D. >>> I added a few. When counting everything together there should be >>> nearly 40 compositing modes now. >>> All modes should trait partly transparent layers as Photoshop is >>> doing it and all modes should >>> respect the channel flags. >>> But there are two problems with this patch: >>> >>> 1. I used a pretty generic approach. So it relies on the >>> compiler to do proper inlining. And i didn't use the optimized >>> multiply functions. I had a few problems with those functions, >>> because it seems the give no correct results but approximations. >>> So I still need to check out which composite modes will work >>> with the optimized functions. I just want to say that it could >>> be that this is a bit/much slower then the current >>> implementation (i don't know how much time you spend in >>> optimizing this). >>> I personally haven't noticed any speed impact but I've got a >>> 3GHz quad core, so i think i will be the last >>> who will notice this. >>> >>> 2. The "Hue" and "Saturation" modes are not working correctly >>> but the "Luminosity" and "Color" modes work exactly as in >>> Photoshop. I coded the algorithms after the ISO 3200-1 spec. >>> Adobe released the texts they gave to the ISO committee for >>> specification. You can find them here: >>> http://www.adobe.com/devnet/pdf.html >>> http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf >>> (direct link) >>> >>> go to the category "Transparency" -> "Basic Composition >>> Computations". This spec is of course for PDFs but it seems that >>> Photoshop uses the same formulas. >>> Since "Luminosity" and "Color" modes are working i think i made >>> some mistake in implementing the >>> "setSat" function (on page 327). Maybe someone else has an >>> enlightenment, because I'm working in the dark right now :D. >>> >>> But apart from this two problems everything else should work >>> fine (hopefully). >>> >>> >>> >>> I tried to build the branch but I get this error: >>> Linking CXX shared library ../../lib/libpigmentcms.so >>> CMakeFiles/pigmentcms.dir/colorspaces/KoLabColorSpace.o: In function >>> `unsigned short cfVividLight(unsigned short, >>> unsigned short)': >>> KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned >>> short cfVividLight(unsigned short, unsigned >>> short)]+0x31): undefined reference to >>> `KoColorSpaceMathsTraits::unitValue' >>> KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned >>> short cfVividLight(unsigned short, unsigned >>> short)]+0x3d): undefined reference to >>> `KoColorSpaceMathsTraits::zeroValue' >>> KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned >>> short cfVividLight(unsigned short, unsigned >>> short)]+0xb3): undefined reference to >>> `KoColorSpaceMathsTraits::zeroValue' >>> KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned >>> short cfVividLight(unsigned short, unsigned >>> short)]+0xbf): undefined reference to >>> `KoColorSpaceMathsTraits::unitValue' >>> CMakeFiles/pigmentcms.dir/colorspaces/KoLabColorSpace.o: In function >>> `unsigned short cfDivide(unsigned short, unsigned >>> short)': >>> KoLabColorSpace.cpp:(.text._Z8cfDivideItET_S0_S0_[unsigned short >>> cfDivide(unsigned short, unsigned short)]+0x25): >>> undefined reference to `KoColorSpaceMathsTraits>> short>::zeroValue' >>> KoLabColorSpace.cpp:(.text._Z8cfDivideItET_S0_S0_[unsigned short >>> cfDivide(unsigned short, unsigned short)]+0x31): >>> undefined reference to `KoColorSpaceMathsTraits>> short>::unitValue' >>> CMakeFiles/pigmentcms.dir/colorspaces/KoLabColorSpace.o: In function >>> `unsigned short cfArcTangent(unsigned short, >>> unsigned short)': >>> KoLabColorSpace.cpp:(.text._Z12cfArcTangentItET_S0_S0_[unsigned >>> short cfArcTangent(unsigned short, unsigned >>> short)]+0x25): undefined reference to >>> `KoColorSpaceMathsTraits::zeroValue' >>> KoLabColorSpace.cpp:(.text._Z12cfArcTangentItET_S0_S0_[unsigned >>> short cfArcTangent(unsigned short, unsigned >>> short)]+0x31): undefined reference to >>> `KoColorSpaceMathsTraits::unitValue' >>> CMakeFiles/pigmentcms.dir/colorspaces/KoRgbU8ColorSpace.o: In >>> function `unsigned char cfVividLight(unsigned char, >>> unsigned char)': >>> KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned >>> char cfVividLight(unsigned char, unsigned >>> char)]+0x27): undefined reference to >>> `KoColorSpaceMathsTraits::unitValue' >>> KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned >>> char cfVividLight(unsigned char, unsigned >>> char)]+0x33): undefined reference to >>> `KoColorSpaceMathsTraits::zeroValue' >>> KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned >>> char cfVividLight(unsigned char, unsigned >>> char)]+0x97): undefined reference to >>> `KoColorSpaceMathsTraits::zeroValue' >>> KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned >>> char cfVividLight(unsigned char, unsigned >>> char)]+0xa3): undefined reference to >>> `KoColorSpaceMathsTraits::unitValue' >>> CMakeFiles/pigmentcms.dir/colorspaces/KoRgbU8ColorSpace.o: In >>> function `unsigned char cfDivide(unsigned char, >>> unsigned char)': >>> KoRgbU8ColorSpace.cpp:(.text._Z8cfDivideIhET_S0_S0_[unsigned char >>> cfDivide(unsigned char, unsigned char)]+0x21): >>> undefined reference to `KoColorSpaceMathsTraits>> char>::zeroValue' >>> KoRgbU8ColorSpace.cpp:(.text._Z8cfDivideIhET_S0_S0_[unsigned char >>> cfDivide(unsigned char, unsigned char)]+0x2d): >>> undefined reference to `KoColorSpaceMathsTraits>> char>::unitValue' >>> CMakeFiles/pigmentcms.dir/colorspaces/KoRgbU8ColorSpace.o: In >>> function `unsigned char cfArcTangent(unsigned char, >>> unsigned char)': >>> KoRgbU8ColorSpace.cpp:(.text._Z12cfArcTangentIhET_S0_S0_[unsigned >>> char cfArcTangent(unsigned char, unsigned >>> char)]+0x21): undefined reference to >>> `KoColorSpaceMathsTraits::zeroValue' >>> KoRgbU8ColorSpace.cpp:(.text._Z12cfArcTangentIhET_S0_S0_[unsigned >>> char cfArcTangent(unsigned char, unsigned >>> char)]+0x2d): undefined reference to >>> `KoColorSpaceMathsTraits::unitValue' >>> collect2: ld returned 1 exit status >>> make[2]: *** [lib/libpigmentcms.so.8.0.0] Fehler 1 >>> make[1]: *** [libs/pigment/CMakeFiles/pigmentcms.dir/all] Fehler 2 >>> make: *** [all] Fehler 2 >>> >>> >>> _______________________________________________ >>> kimageshop mailing list >>> kimageshop@kde.org >>> https://mail.kde.org/mailman/listinfo/kimageshop >> >> >> _______________________________________________ >> kimageshop mailing list >> kimageshop@kde.org >> https://mail.kde.org/mailman/listinfo/kimageshop > > > _______________________________________________ > kimageshop mailing list > kimageshop@kde.org > https://mail.kde.org/mailman/listinfo/kimageshop --------------020101070200050208050005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
@Boud :what is your problem when trying to compile?
Just the problem is I don't know a lot of things about "how to do it" ; I was just a script user of the SVN version. Animtim was nice and sent me keys code lines to do it, but I spent hours without results because folders in 'calligra' are really different than in 'koinstall'. It surely sounds stupid for you :) I will surely try again. If I update using old script of SVN, it will be 2.3.1 ?  Thanks for your replies.

@Silvio Heinrich : if gimp really uses just HSV then it is not really superior.
Oh, I really don't know nothing about how and why color modes prefer use HSV or HSL luma , I'm just a digital painter user. The only feedback I can give are with pictures like the previous mail :-)
Btw, you are right , my use of 'superior' word needs to be explain : the color mode in Photoshop ( I used it for years too) don't work nicely with yellow/orange tones painting over gray. You obtain only a muddy green/yellowish tones. That's why I called the Gimp one 'superior' ; because if you use it as a painter to recolor a part and like to use yellow or orange ; the Gimp one will be more efficient for this case. That's why I always prefered the way Gimp handle it than Photoshop.
Just to defend that the two way are usefull :) and I agree and like if you planed to support more then one color model. Good way !  and thanks for the link.


--David

On 01/29/2011 01:30 PM, Silvio Heinrich wrote:
Hmm.. ok. I don't know what color model gimp exactly uses for this but i thought gimp uses HSV.
It would be nice if you could tell me more about the way how gimp does it (of course only if you know).
But if gimp really uses just HSV then it is not really superior. It's just a matter what you want to do in which way.
I paint myself (and i'm not too bad i would say :D) and for me the photoshop way is working much better.
It was not my intend to simply remove something. The other color mode is still there it's just not in the list.
I actually planed to support more then one color model so krita is compatible to photoshop and gimp (i also included the "Grain Merge" and "Grain Extract" modes for this reason).
If you want to know the advantages and disatvantages of HSL and HSV please read this:
http://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages
Photoshop uses the HSL luma variant.
And as far as i know gimp uses HSV (but please correct me if i'm wrong and give me some feedback how gimp2.6 is doing it :D)
On 01/29/2011 10:41 AM, David REVOY wrote:
Hi,

Just to react on this :
and "Color" modes work exactly as in Photoshop
Just to inform the way 'color mode' works in Gimp 2.6 is superior to the 'color mode' of Photoshop ( till Cs2 for sure ).
This can be tested & seen with comparing the same file open like this :
http://www.davidrevoy.com/XYZ/color-mode_test_GIMP-net.jpg
http://www.davidrevoy.com/XYZ/color-mode_test_TOSHOP-net.jpg
useless to say that Gimp color mode is far superior for artist than Photoshop. I understand the photoshop one should be proposed for compatibility, but for efficiency ; please don't omit one like Gimp. I couldn't try it with Krita , btw*

The PSD file if you need to test ( this file can be considered as 'public domain' if you need it ) :
http://www.davidrevoy.com/XYZ/color-mode_test.psd.zip
;-)

-David
( PS : can't compile since Git or install 2.3 threw PPA , as i'm Lucid Lynx LTS user not Maverick ...so I wait kubuntu backport to post the bin for Lucid 64bit )

On 01/28/2011 10:52 PM, Sven Langkamp wrote:
On Wed, Jan 12, 2011 at 11:17 PM, Silvio Heinrich <plassy@web.de> wrote:
Phew... I think I've gone a bit mad with the blending modes :D.
I added a few. When counting everything together there should be nearly 40 compositing modes now.
All modes should trait partly transparent layers as Photoshop is doing it and all modes should
respect the channel flags.
But there are two problems with this patch:

1. I used a pretty generic approach. So it relies on the compiler to do proper inlining. And i didn't use the optimized multiply functions. I had a few problems with those functions, because it seems the give no correct results but approximations. So I still need to check out which composite modes will work with the optimized functions. I just want to say that it could be that this is a bit/much slower then the current implementation (i don't know how much time you spend in optimizing this).
I personally haven't noticed any speed impact but I've got a 3GHz quad core, so i think i will be the last
who will notice this.

2. The "Hue" and "Saturation" modes are not working correctly but the "Luminosity" and "Color" modes work exactly as in Photoshop. I coded the algorithms after the ISO 3200-1 spec. Adobe released the texts they gave to the ISO committee for specification. You can find them here:
http://www.adobe.com/devnet/pdf.html
http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf  (direct link)

go to the category "Transparency" -> "Basic Composition Computations". This spec is of course for PDFs but it seems that Photoshop uses the same formulas.
Since "Luminosity" and "Color" modes are working i think i made some mistake in implementing the
"setSat" function (on page 327). Maybe someone else has an enlightenment, because I'm working in the dark right now :D.

 But apart from this two problems everything else should work fine (hopefully).



I tried to build the branch but I get this error:
Linking CXX shared library ../../lib/libpigmentcms.so                                                                                                                                          
CMakeFiles/pigmentcms.dir/colorspaces/KoLabColorSpace.o: In function `unsigned short cfVividLight<unsigned short>(unsigned short, unsigned short)':                                            
KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned short cfVividLight<unsigned short>(unsigned short, unsigned short)]+0x31): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::unitValue'
KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned short cfVividLight<unsigned short>(unsigned short, unsigned short)]+0x3d): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::zeroValue'
KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned short cfVividLight<unsigned short>(unsigned short, unsigned short)]+0xb3): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::zeroValue'
KoLabColorSpace.cpp:(.text._Z12cfVividLightItET_S0_S0_[unsigned short cfVividLight<unsigned short>(unsigned short, unsigned short)]+0xbf): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::unitValue'
CMakeFiles/pigmentcms.dir/colorspaces/KoLabColorSpace.o: In function `unsigned short cfDivide<unsigned short>(unsigned short, unsigned short)':
KoLabColorSpace.cpp:(.text._Z8cfDivideItET_S0_S0_[unsigned short cfDivide<unsigned short>(unsigned short, unsigned short)]+0x25): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::zeroValue'
KoLabColorSpace.cpp:(.text._Z8cfDivideItET_S0_S0_[unsigned short cfDivide<unsigned short>(unsigned short, unsigned short)]+0x31): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::unitValue'
CMakeFiles/pigmentcms.dir/colorspaces/KoLabColorSpace.o: In function `unsigned short cfArcTangent<unsigned short>(unsigned short, unsigned short)':
KoLabColorSpace.cpp:(.text._Z12cfArcTangentItET_S0_S0_[unsigned short cfArcTangent<unsigned short>(unsigned short, unsigned short)]+0x25): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::zeroValue'
KoLabColorSpace.cpp:(.text._Z12cfArcTangentItET_S0_S0_[unsigned short cfArcTangent<unsigned short>(unsigned short, unsigned short)]+0x31): undefined reference to `KoColorSpaceMathsTraits<unsigned short>::unitValue'
CMakeFiles/pigmentcms.dir/colorspaces/KoRgbU8ColorSpace.o: In function `unsigned char cfVividLight<unsigned char>(unsigned char, unsigned char)':
KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned char cfVividLight<unsigned char>(unsigned char, unsigned char)]+0x27): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::unitValue'
KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned char cfVividLight<unsigned char>(unsigned char, unsigned char)]+0x33): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::zeroValue'
KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned char cfVividLight<unsigned char>(unsigned char, unsigned char)]+0x97): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::zeroValue'
KoRgbU8ColorSpace.cpp:(.text._Z12cfVividLightIhET_S0_S0_[unsigned char cfVividLight<unsigned char>(unsigned char, unsigned char)]+0xa3): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::unitValue'
CMakeFiles/pigmentcms.dir/colorspaces/KoRgbU8ColorSpace.o: In function `unsigned char cfDivide<unsigned char>(unsigned char, unsigned char)':
KoRgbU8ColorSpace.cpp:(.text._Z8cfDivideIhET_S0_S0_[unsigned char cfDivide<unsigned char>(unsigned char, unsigned char)]+0x21): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::zeroValue'
KoRgbU8ColorSpace.cpp:(.text._Z8cfDivideIhET_S0_S0_[unsigned char cfDivide<unsigned char>(unsigned char, unsigned char)]+0x2d): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::unitValue'
CMakeFiles/pigmentcms.dir/colorspaces/KoRgbU8ColorSpace.o: In function `unsigned char cfArcTangent<unsigned char>(unsigned char, unsigned char)':
KoRgbU8ColorSpace.cpp:(.text._Z12cfArcTangentIhET_S0_S0_[unsigned char cfArcTangent<unsigned char>(unsigned char, unsigned char)]+0x21): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::zeroValue'
KoRgbU8ColorSpace.cpp:(.text._Z12cfArcTangentIhET_S0_S0_[unsigned char cfArcTangent<unsigned char>(unsigned char, unsigned char)]+0x2d): undefined reference to `KoColorSpaceMathsTraits<unsigned char>::unitValue'
collect2: ld returned 1 exit status
make[2]: *** [lib/libpigmentcms.so.8.0.0] Fehler 1
make[1]: *** [libs/pigment/CMakeFiles/pigmentcms.dir/all] Fehler 2
make: *** [all] Fehler 2


_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop



_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
--------------020101070200050208050005-- --===============0653662228== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop --===============0653662228==--