--- Log opened Sun Apr 08 00:00:56 2007 00:25 -!- zipola [n=zipola@cable-vrk-fe5cdd00-177.dhcp.inet.fi] has quit ["Abiit"] 01:07 < pxegeek> Yes, please. I already added a comment to that effect. 01:36 < pxegeek> Hey dooglus, you around? 02:04 < pxegeek> Well, when you catch up with the chat history... 02:05 < pxegeek> I'm looking at two icons I did. 02:06 < pxegeek> http://pxegeek.home.comcast.net/synfig/transform-scale.sif was done before your color dialog implementation. 02:07 < pxegeek> It has the right dark blue to match the Tango colour schema 02:09 < pxegeek> If I look at the color selection dialog with the dark blue rectangle selected, and visually linear color selection checked in File-setup-misc, the RGB values are correct - 13,29,53 02:11 < pxegeek> If I then turn off visually linear color selection HTML is the same (02103F v. Tango colour 204a87), but RGB becomes 1,6,25. 02:15 < pxegeek> Looking at http://pxegeek.home.comcast.net/synfig/transform-rotate.sif 02:16 < pxegeek> It should have the same colour rectangles, but they're noticeably more pale 02:16 < pxegeek> For this one, I typed in the HTML value 204a87. 02:19 < pxegeek> If I have the visually linear color selection box checked, the RGB values are 39,57,75. (I can't see how these map to the HTML values) 02:20 < pxegeek> If I have visually linear color selection unchecked I get the right RGB value, but the colour is still too pale. 02:23 < pxegeek> Can you take a look at the code and see how the visually linear color selection check box interacts with the calculation of the RGB values from HTML? 02:25 < pxegeek> It looks like HTML -> RGB calculation works correctly with the visually linear color selection box unchecked 02:26 < pxegeek> but the colors only look correct with the RGB values when the visually linear color selection is checked. 02:27 < pxegeek> I hope that's clear. I can talk about it more when you're online 02:30 < dooglus> wow 02:30 < dooglus> that's a lot of talking you've been doing :) 02:32 < dooglus> I don't understand how the colours work in synfig either 02:34 < dooglus> what exactly did you want me to find out from the code? 02:43 < pxegeek> What does the visually linear color selection check box do? 02:44 < pxegeek> When it's checked, the HTML-> RGB calculation comes out 'wrong' 02:46 < pxegeek> Can you fix it so that the HTML -> RGB comes out correct when that box is checked? 02:47 < dooglus> I'm not sure what is correct 02:47 < dooglus> when checked, all color values are passed through 'gamma_out()' before being used 02:48 < dooglus> which basically raises all color values to the power of 2.2 02:49 < pxegeek> All RGB values 02:49 < pxegeek> hmmm... 02:50 < pxegeek> What I want to do is type in 204a87 and get dark blue 02:50 < pxegeek> Right now I get light blue 02:52 < pxegeek> regardless of whether the checkbox is selected. 02:53 < pxegeek> The RGB values calculate correctly when the box is unchecked, but the color is too pale (presumably the gamma=2.2 affecting it) 02:53 < dooglus> if you set gamma=1, does it come out right? 02:54 < dooglus> synfig has a flag: 02:54 < dooglus> -g Gamma (default=2.2) 02:54 < pxegeek> I assume so, but that would make no difference for any setting. 02:54 < pxegeek> Can you pre-divide by gamma when you do the HTML->RGB conversion? 02:55 < dooglus> so what should 'ffffff' come out as? 02:55 < dooglus> like 70,70,70 or something? 02:56 < pxegeek> As my daughter says, "well let's see" Hang on... 02:58 < pxegeek> Ugh I'm confused. 03:00 < dooglus> does http://dooglus.rincevent.net/synfig/1175993977.png help? 03:00 < pxegeek> 204a87 comes out as 39,57,75 but should come out as 13,29,53 03:01 < dooglus> it shows 0-100 along the bottom, and 00-ff up the side 03:01 < dooglus> how hex values and decimal value correspond 03:01 < dooglus> with 'linear' mode on 03:01 < dooglus> and the red line is (x^2.2)/100 03:01 < pxegeek> yes, it's more noticeable at the low end.. 03:03 < pxegeek> So, shouldn't the HTML value always map to the same RGB? 03:03 < pxegeek> Regardless of Gamma? 03:03 < dooglus> I think it should always result in the same color in the .sif file, yes 03:03 < dooglus> but will appear differently on-screen, depending on the gamma 03:04 < dooglus> is that right? 03:05 < dooglus> 204a87 came out as 39 57 75 in the color selector when linear was on, gamma was 2.2 and black level was 12.9 03:06 < pxegeek> pale blue, right? 03:06 < dooglus> the sif file has 0.1254900.2901960.5294121.000000 03:06 < pxegeek> which is the 13,29,53 RGB that you should get. 03:06 < dooglus> turning linear off 03:07 < dooglus> 204a87 came out as 13 29 53 in the color selector when linear was off, gamma was 2.2 and black level was 12.9 03:07 < dooglus> the sif file has the same as before 03:07 < dooglus> so 204a87 is the same color whether linear is on or not 03:08 < dooglus> but it shows up differently in the R,G,B sliders - because that's what linear mode does - it redefines the color sliders to look linear, rather than being linear 03:08 < pxegeek> yes 03:08 < dooglus> (due to the non linear response of your eyes, these 2 are different) 03:10 < pxegeek> but when you type 204a87 into the HTML box, you get 13,29,53 with linear off, but the colour is still too pale 03:11 < pxegeek> So right now transform-scale has the right RGB values 03:11 < pxegeek> but looks correct with linear on 03:12 < pxegeek> When you render the icons what value of gamma do you use? 03:13 < dooglus> the makefile does it automatically 03:13 < dooglus> I'll check what it uses 03:14 < dooglus> looks like it does: $(SYNFIG) $< -w 16 -h 16 -o $*-16x16.png $< -w 32 -h 32 -o $*-32x32.png $< -w 48 -h 48 -o $*-48x48.png $< -w 64 -h 64 -o $*-64x64.png 03:14 < dooglus> ie. uses the default 2.2 03:14 < pxegeek> Transform-scale looks too dark with gamma=1, but transform rotate now looks correct 03:15 < pxegeek> Ugh, so what do I do? 03:15 < dooglus> I think if we use gamma=1 then the colours you get are the colours you ask for 03:15 < dooglus> (in the hex box) 03:15 < pxegeek> Right 03:16 < pxegeek> but you'll automatically render them much lighter when you compile 03:17 < dooglus> well, unless I change the makefile to use -g 1.0 03:18 < pxegeek> Is that going to mess up the other icons & dialog box? 03:18 < pxegeek> about dialog I meant 03:18 < dooglus> I guess so 03:19 < dooglus> it would be very easy to write a script to convert all the existing icons' colours to work with 1.0 instead of 2.2 though 03:19 < dooglus> or to convert your 1.0 icons to work with 2.2 - either wa 03:19 < dooglus> y 03:20 < pxegeek> Well, it would be easier to use the colour palette HTML dialog if gamma=1 :) 03:21 < pxegeek> Next question of course is why is the default value 2.2 anyway? 03:22 < dooglus> I've no idea 03:22 < dooglus> maybe because that's how our eyes are? 03:22 < dooglus> or something? 03:22 < dooglus> I don't understand any of this stuff 03:22 < dooglus> synfig(5524): warning: Gamma argument is currently ignored... 03:22 < dooglus> doh! 03:24 < dooglus> so there's no way to get it to render using 1.0 at the moment? 03:25 < pxegeek> "Once more the devil farts in my face, Baldrick" 03:26 < pxegeek> From looking at Wikipedia, it looks like gamma=2.2 is common for CRT calibration 03:26 < pxegeek> Don't know what that means for my LCD... 03:28 < pxegeek> Ha. "In LCDs such as those on laptop computers, the relation between the signal voltage VS and the intensity I is very nonlinear and cannot be described with gamma value. " 03:28 < dooglus> http://dooglus.rincevent.net/synfig/1175995653.png shows an example 03:28 < dooglus> the left side was with 'black level 0%' and gamma 1.0 03:28 < dooglus> the colors check out (using the eye dropper in The Gimp) 03:29 < dooglus> you have to use black level 0% and gamma 1.0, or the colours are too pale 03:29 < pxegeek> Pretty - we should include that on the wiki page! 03:29 < dooglus> I think we have to assume that the users have configured their monitors appropriately 03:29 < dooglus> we can't adjust the gamma for them separately in every application - can we? 03:30 < pxegeek> OK, so we assume that gamma is 2.2? 03:32 < dooglus> I think what's happening at the moment, 03:32 < dooglus> is we are assuming that the user doesn't have their monitor set up right 03:32 < dooglus> and so we're rendering everything brighter than it should be, to make up for that 03:32 < dooglus> no other application that I use does that 03:32 < pxegeek> So it seems. 03:32 < dooglus> so synfig graphics end up being twice as pale as everything else 03:32 < pxegeek> Yes. 03:32 < dooglus> hence the 'washed out' look to the icons 03:33 < pxegeek> Exactly 03:33 < dooglus> but we should really try to find out why it's doing what it's doing. 03:33 < dooglus> maybe there is a good reason for it 03:33 < pxegeek> Transform-scale looks correct because I hand calculated the RGB values, and the gammas matched. 03:34 < pxegeek> All the later ones with the 'correct' HTML values look washed out 03:34 < dooglus> are you on a Windows box? 03:34 < pxegeek> yes 03:34 < pxegeek> But you can look at the sif files for the RGB values 03:34 < dooglus> I'm thinking about a 'gamma converter' program 03:35 < pxegeek> I'm going to set my gamma to one when I render :) 03:35 < pxegeek> How you figure it for the compile I leave to you... 03:35 < pxegeek> That way, I get WYSIWYG 03:36 < dooglus> ah, well the -g option isn't implemented... 03:36 < dooglus> so you have to render with 2.2 03:36 < pxegeek> Mmmm... sounds like a bug ;) 03:37 < dooglus> I don't know why it isn't implemented 03:37 < dooglus> sounds like an easy enough thing to do 03:37 < pxegeek> BTW, Why do you generate the icons everytime? Why not link them statically? That would allow us to hand tweak the small size icons to look crisper also 03:37 < pxegeek> Or even just use the tango icons 'as is' 03:38 < dooglus> I imagine synfig is used to make its own icons "because it can" 03:39 < dooglus> ie. because it's a "cool" feature that it can draw its own icons, or something 03:39 < dooglus> if you can hand tweak to make them better, then by all means do 03:40 < pxegeek> I don't think I can tweak them in the sif file, only the rendered image... 03:40 < dooglus> right 03:40 < dooglus> I can add your .png files to svn, and use those rather than re-generating them all the time 03:40 < dooglus> maybe just for the smallest icons? or do you think it's worth tweaking the bigger ones too? 03:41 < pxegeek> So right now all the icons are rendered at 128x128, but displayed at ~22?x22?? 03:42 < dooglus> good question 03:42 < dooglus> the line I pasted before suggested 16, 32, 48, 64 were the sizes 03:42 < dooglus> must have been the wrong line I guess 03:42 < pxegeek> Sorry - my daughter just distracted me. I don't know where I was going with that.... 03:43 < pxegeek> maybe what I'm seeing is 16x16. 03:43 < dooglus> ok, it's using this: 03:43 < dooglus> .sif.$(EXT): $(SYNFIG) -q $< -o $@ --time 0 03:43 < pxegeek> Atrus mentioned support for larger icons, but I can't see any way to use the larger sizes 03:44 < dooglus> so it's not specifying a size, just using whatever the .sif tells it to 03:44 < dooglus> and the .sif files say: hmmm.. Good to know. I start out with canvas 200x200, and manually set to 128x128 at render time 03:46 < pxegeek> sif files are 200x200. So when you compile they will be a little bigger. Hopefully it won't break anything 03:47 < dooglus> I think I see why the 4 'lock' icons are missing in the Windows build 03:47 < pxegeek> I don't think they're in the pixmap dir... 03:48 < dooglus> when the build script makes .png files from .sif files, it adds each .png file's name to a list 03:48 < pxegeek> They disappeared between 421 & 426 03:48 < dooglus> that list is used when making the windows package 03:48 < dooglus> but the keyframe lock icons are made separately, and not added to the list 03:49 < dooglus> keyframe_lock_icon.sif is used to render all 4 images 03:49 < pxegeek> something changed.... 03:49 < pxegeek> 4 frames from the same sif file? Neat 03:50 < dooglus> it uses the '-c' flag to synfig 03:50 < dooglus> $(SYNFIG) -q $< -o $@ --time 0 -c FutureOnly 03:50 < dooglus> for example 03:50 < dooglus> -c Render the canvas with the given id instead of the root. 03:51 < pxegeek> I tend to get a lot more crashes when I have timelines turned on, so I haven't played much with that 03:51 < dooglus> are you still getting crashes with the new version? 03:52 < pxegeek> yes. 03:52 < dooglus> anything repeatable? 03:52 < pxegeek> For me, yes. I bounced one off pabs, but he didn't see it under linux 03:53 < pxegeek> hang on - I'll give you an example in a second - gotta check on the kids 03:53 < dooglus> he's using an older build though 03:53 < dooglus> ok 04:01 < dooglus> hmm. 1 .sif file, 4 canvases: http://dooglus.rincevent.net/synfig/1175997573.png 04:03 < pxegeek> OK, try this. 04:03 < pxegeek> http://pxegeek.home.comcast.net/Scoobydoo.sif 04:03 < pxegeek> He may look familiar 04:03 < pxegeek> Although he looks a lot darker now I've turned my gamma down 04:04 < pxegeek> Go to > Edit , properties 04:05 < pxegeek> Time and edit the endtime to 10s 04:05 < pxegeek> OK or apply will cause synfig to crash for me. 04:47 < dooglus> ok 04:47 < dooglus> I forgot I was running this laptop off the battery 04:47 < dooglus> it crashed when the battery ran out 04:48 < dooglus> and the memory stick got left in a real mess 04:51 -!- pabs3 [n=pabs@dsl-58-7-239-5.wa.westnet.com.au] has joined #synfig 04:57 < pxegeek> oops! 04:57 * pxegeek is going to tuck the little one into bed 05:02 < dooglus> scooby doesn't crash for me either 05:02 < dooglus> morning pabs 05:02 < pabs3> hullo 05:03 < dooglus> I keep on finding more and more synfig bugs 05:03 < dooglus> quicker than I can fix them 05:07 < dooglus> I don't suppose you know why the '-g ' flag has been disabled? 05:09 < pabs3> haven't looked into it 05:45 < pxegeek> There's definitely some PC dependencies as well. I can run the same versions on two different PCs and some sif files will crash on one and not on the other. 05:45 < pxegeek> That's why I was interested when you were talking about race conditions with threads.... 05:45 < pxegeek> Morning pabs! 05:46 < pabs3> morn :) 05:58 < pxegeek> dooglus - I've finally caught up with you.... 05:59 < pxegeek> Even if I set my gamma to 1.0, it looks great on the screen but still renders out with gamma set to 2.2. 06:02 < pxegeek> Transform-scale is the only one that renders with the tango colors as I coded the RGB correctly, but with visually linear color selection enabled 06:02 < pxegeek> i.e. the HTML values are off. 06:04 < pxegeek> So having the HTML option in the dialog box doesn't help me, as I still have to recalculate to take the gamma into account :( 06:07 < dooglus> yes 06:07 < dooglus> the hex/html value you type is what gets stored in the .sif file 06:07 < dooglus> but when you render, a gamma of 2.2 is used, which means you end up not getting the colour you asked for 06:09 < pxegeek> "the hex/html value you type is what gets stored in the .sif file" iff linear is unchecked 06:10 < dooglus> no 06:10 < dooglus> what I said, I think 06:10 < pxegeek> If it is checked then RGB <>HTML e.g. RGB 13,19,53 maps to 02013F instead of 204A87 06:11 < dooglus> type 204A87 into the box, hit return, save the .sif file and look at the rgb in there 06:12 < pxegeek> Yes, that is correct to get a light blue. But 204A87 should be dark blue. To get that, I had linear on and entered 13,29,53. 06:12 < dooglus> 0.1254900.2901960.529412< 06:12 < dooglus> that should be what you get, whatever gamma, black level and linear-ness you are using 06:12 < pxegeek> You're looking at rotate? 06:13 < dooglus> 0x20 / 0x100 == 0.125, absolutely 06:13 < pxegeek> Yes 06:13 < pxegeek> We're agreeing... 06:13 < pxegeek> That's the value that gets stored. 06:13 < dooglus> ok 06:13 < dooglus> I was disagreeing with your 'iff' earlier 06:14 < pxegeek> ? 06:14 < dooglus> "the hex you type == the colour that gets stored in .sif iff linear is unchecked" 06:15 < dooglus> that's what I was disagreeing with 06:15 < dooglus> I think this is true: "the hex you type == the colour that gets stored in .sif whether or not linear is unchecked" 06:15 < pxegeek> If you have the same color selected, and change whether you're looking at it withlinear enabled and disabled, the RGB values change 06:15 < pxegeek> in the selection dialog 06:15 < dooglus> the sliders in the dialog change, yes 06:15 < dooglus> but what gets written to the .sif file doesn't 06:16 < dooglus> you realise that .sif files are plain text, right? you can open them in notepad or whatever 06:17 < pxegeek> yes, so to actually get the colour you want when you render, you have to use the HTML value that gives the correct RGB with linear on. 06:17 < pxegeek> which is not the HTML value from the Tango style guide... 06:17 < dooglus> ok 06:18 < dooglus> so you want to be able to type an HTML value and have that be what appears when you render? 06:18 < pxegeek> So transform-scale renders correctly although the RGB stored is 1,6,25 instead of 13,29,53 06:19 < pxegeek> yes. Or fix the render so it can use a gamma of 1. 06:20 < pxegeek> HTML values give you the expected values in the RGB box when linear is off, but the rendered result is too pale. 06:20 < pxegeek> I want to have linear on, type in 204a87 and get 13,29,53 06:21 < pxegeek> not 39,57,75 06:22 < dooglus> it's easy enough to hard-code the gamma it uses to render 06:22 < dooglus> I just did so to make: http://dooglus.rincevent.net/synfig/color-1.0.png and http://dooglus.rincevent.net/synfig/color-2.2.png 06:22 < dooglus> (from the same .sif file) 06:22 < pxegeek> Ugh this is going to mess people up. Existing sifs are going to be darker. 06:23 < dooglus> yes 06:23 < dooglus> ooh. those 2 files look identical in firefox 06:23 < pabs3> yep 06:23 < dooglus> they're not, though 06:23 < pabs3> png has gamma info iirc 06:24 < dooglus> aah 06:24 < pxegeek> http://dooglus.rincevent.net/synfig/1175995653.png showed it better. 06:25 < dooglus> yes, but that wasn't from a render - that's 2 studio canvases 06:25 < dooglus> (thanks to the bug I reported yesterday where changing the gamma doesn't update the display properly) 06:26 * pabs3 recons ducks need tooltips or something 06:27 < pabs3> hey, what is that box just to the left of the refresh button? 06:27 < dooglus> refresh button? 06:28 < pxegeek> The small x in the circle? 06:28 < dooglus> oh, ok 06:30 < pabs3> in the bottom right of canvas windows is (from right to left): stop button (red circle with x), refresh button (circular arrows), some weird box 06:30 < dooglus> statusbartable->attach(*progressbar, 4, 5, 0, 1, Gtk::SHRINK, Gtk::EXPAND|Gtk::FILL, 0, 0); 06:30 < dooglus> statusbartable->attach(*refreshbutton, 5, 6, 0, 1, Gtk::SHRINK, Gtk::SHRINK, 0, 0); 06:30 < dooglus> statusbartable->attach(*stopbutton, 6, 7, 0, 1, Gtk::SHRINK, Gtk::SHRINK, 0, 0); 06:30 < pabs3> spose I should just RTFC 06:30 < pabs3> ah, progress 06:30 < dooglus> ( synfig-studio/src/gtkmm/canvasview.cpp ) 06:32 < dooglus> I don't know if I've ever seen it do anything though 06:32 < pabs3> ugh, segfault with libav target 06:32 < dooglus> there is code to update it: view->progressbar->set_fraction(x); 06:33 < pxegeek> I have 06:33 < pxegeek> I'm sure of it... 06:34 < dooglus> I just got a segfault loading pirates.sif :( 06:34 < dooglus> and again 06:38 < pxegeek> ...maybe not.... 06:39 < pxegeek> Did we ever figure out is a sound clip could be loaded in? 06:39 < pxegeek> s/if/is 06:41 < dooglus> I didn't 06:41 < dooglus> maybe the progress bar updates when you're doing a render in studio? 06:46 < pabs3> doesn't seem to 06:47 < pabs3> hhm, can't seem to edit metadata or delete metadata 06:48 < dooglus> I've never looked at that dialog 06:49 < dooglus> I'm getting a crash from line 61 of synfig-core/src/synfig/gamma.cpp 06:49 < dooglus> how is that possible? 06:50 < dooglus> ==21536== Invalid write of size 1 06:50 < dooglus> ==21536== at 0x4373881: synfig::Gamma::set_gamma(float) (gamma.cpp:61) 06:50 < dooglus> ==21536== by 0x8368470: synfig::Gamma::Gamma(float) (gamma.h:61) 06:51 < pxegeek> Metadata, as in meta tab on teh Params, Children..canvas metadata window? 06:51 < dooglus> unless I'm running out of memory 06:52 < dooglus> pxegeek: those tabs are moveable. you can drag them into other dialogs however you like 06:52 < pxegeek> It reflects options set elsewhere, like grid size and whether onion skinning is on or off 06:58 < dooglus> any idea how big the stack can get in linux before things start crashing? 06:58 < pabs3> I imagine it is configurable via /proc or /sys at runtime 06:58 < dooglus> ok, but by default? 06:59 < dooglus> I'm wondering whether putting 2 'Gamma' objects onto the stack could be causing it to crash 06:59 < dooglus> they're quite big - like 192Kb each 07:02 < pabs3> ulimit -s 07:02 < dooglus> 8192 07:03 < pabs3> same here 07:03 < pabs3> you can change it by putting a number after -s 07:04 < dooglus> Values are in 1024-byte increments 07:04 < dooglus> so 8000K = 8M 07:04 < dooglus> I don't think I'm close to that 07:18 < dooglus> I'm not understanding why firefox displays both those pictures so brightly 07:18 < dooglus> http://dooglus.rincevent.net/synfig/color-1.0.png has a gamma of 1.0: 07:18 < dooglus> identify -verbose color-1.0.png | grep -i gamma ==> Gamma: 1 07:19 < dooglus> identify -verbose color-1.0.png | grep -E '[0-9]{5}:' | head -1 07:19 < dooglus> 13422: ( 0, 17, 34, 0) #00112200 07:19 < dooglus> shows it really does have color #001122 in it, a lot 07:20 < dooglus> yet firefox is displaying it much brighter 07:33 < dooglus> so gaim is now called pidgin, apparently 07:33 < pabs3> yar 07:39 * pxegeek is yawning my head off... 07:39 < pxegeek> 'nite all 07:39 < dooglus> nite 08:06 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has quit [Read error: 110 (Connection timed out)] 09:42 < pabs3> hmm, madsen got unsubscribed due to his email bouncing 10:15 -!- zipola [n=zipola@cable-vrk-fe5cdd00-177.dhcp.inet.fi] has joined #synfig 12:52 -!- pabs3 [n=pabs@dsl-58-7-239-5.wa.westnet.com.au] has quit ["Don't rest until all the world is paved in poems."] 13:33 -!- zotz [n=zotz@24.244.163.157] has joined #synfig 18:05 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"] 22:51 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig --- Log closed Mon Apr 09 00:00:57 2007