WEBVTT 00:00.000 --> 00:14.680 Excellent. So, this is one tool I know in a few many times. So, it's nice to see 00:14.680 --> 00:21.400 a gimp here. So, right, I think we're a minute late. So, let's start. 00:21.400 --> 00:26.200 Well, we don't have much time so let's jump right into it. Where's going after the 3.2 00:26.200 --> 00:31.800 release? Before I mentioned all that, let's do a quick look behind. The last year has been 00:31.800 --> 00:36.440 very eventful. It's the biggest milestone of course, is after 7 years of development, 00:36.440 --> 00:42.760 finally releasing the most evasive 3.0 release. It has many, many features I will not 00:42.760 --> 00:47.720 cover today. I very much recommend watching the keynote that the gimp may tend to 00:47.720 --> 00:54.840 have given last year. But, until we've summing up quickly, we've published 10 separate 00:54.840 --> 01:02.560 releases first to where about the 3.0 release, the next 4, where about our micro releases 01:02.560 --> 01:09.480 for the now new stable release of 3.0. And, 4, are the new, are releases in the new unstable 01:09.480 --> 01:15.600 branch, the 3.1. The last of which is the second release candidate, which should mean that 01:15.600 --> 01:21.280 the 3.2 release is coming fairly soon. The team has also attended two events, first one 01:21.280 --> 01:27.000 is the library graphics meeting, 2,025, which is more of a developer conference, and then 01:27.000 --> 01:31.640 we also participate in World War week, which is more of a team meeting and a hackathon 01:31.640 --> 01:38.280 more in a personal setting. What's coming in the upcoming 3.2 release, there is way too much 01:38.280 --> 01:43.440 for me to cover here today. So, I'll focus only on free items. The first one are just 01:43.440 --> 01:47.960 the small UX and UI changes that in most cases you will not notice because they are 01:48.040 --> 01:54.080 quite small, but they are the small fixes working towards making the whole UX experience 01:54.080 --> 02:02.040 much better. A lot of these changes have come from the work done in our new GPUX issue 02:02.040 --> 02:06.200 tracker and I very much recommend if you want to participate in the discussions there, 02:06.200 --> 02:11.640 you are always most welcome. The two features I want to mention are two new types of 02:11.720 --> 02:18.720 layers. The first type are link layers. Now it is possible to give projects to the link 02:18.720 --> 02:25.160 and over the existing image file and once that file is updated outside of GIMP, it will 02:25.160 --> 02:31.960 be reloaded automatically. The second type of layer has been in development since 2006 02:31.960 --> 02:37.040 when it started as a Google summer of code project. It has gone through many revisions 02:37.040 --> 02:42.680 and finally one developer has pushed it over the finish line and got it into the main 02:42.680 --> 02:48.200 line and now it is possible to make use of GIMP's path tool to create vector layers, apply 02:48.200 --> 02:53.560 non-instructive transformations to them, and if needed, the best drives them into classic 02:53.560 --> 03:00.040 layer. Resturization is also available for link layers. Now that we all called up, we can 03:00.040 --> 03:07.720 take a look into the future. What is coming after the 3.2 release. The short answer is, it 03:07.720 --> 03:12.920 depends on the community. GIMP is a community driven project. There is no one road map. There 03:12.920 --> 03:19.400 is no one clear vision where we are going. It all comes down to who are the current contributors 03:19.400 --> 03:26.040 and what they are interested in. And then we try to align the interest and maybe try to narrow 03:26.040 --> 03:34.480 down what we are working on. I have taken these from our roadmap, which is publicly available. 03:34.480 --> 03:39.440 And again, there is way too much for me to cover here today. I will focus only on free items 03:39.440 --> 03:46.440 that are particularly interesting to me. The first one is a full C and Y came out. What has 03:46.440 --> 03:54.360 become possible in the 3.0 release is finally working with images using C and YK. What you 03:54.360 --> 04:02.600 can do now is to import an image using C and YK. GIMP will ask you what kind of a color 04:02.600 --> 04:10.640 profile you would like to use. Once GIMP converts an image into RGB automatically, then you 04:10.640 --> 04:17.080 continue working with your image with a project as usual and GIMP uses RGB in the background. 04:17.080 --> 04:23.320 You can make use of software for preview. And once you export your image, GIMP will use 04:23.320 --> 04:28.600 the profile of the color profile you have selected before or change layer and apply it on 04:28.600 --> 04:35.400 export. What we are working towards now is making it possible to skip this conversion altogether 04:35.400 --> 04:41.200 and adding a new color mode which would be the C and YK mode. Having in total free main 04:41.200 --> 04:48.280 color modes available next to RGB, gray scale and hopefully in the future C and YK. 04:48.280 --> 04:53.280 Now then it would be possible not to convert at all and have direct access to the color 04:53.280 --> 04:59.320 channels or adding new channels using for example colors. These two workflows are 04:59.320 --> 05:05.040 to be also referred to as late binding and early binding. I recommend checking out the 05:05.040 --> 05:11.880 working progress merge request where some of the foundation work is already being done. 05:11.880 --> 05:17.360 The second feature that's being worked on is a new XCF format. XCF is the project format 05:17.360 --> 05:22.880 that's used by GIMP and currently it is a binary format. That gives us some limitations 05:22.880 --> 05:28.120 as to how we can work with our project and also limits the performance. Because if you 05:28.120 --> 05:33.200 have a large project of multiple hundreds of megabytes and you export you need to write 05:33.200 --> 05:39.800 we need to write a whole file at one switch. Can take some time if your project is too big. 05:39.800 --> 05:45.440 So the future is some kind of a container format. What type of container? I do not know. 05:45.680 --> 05:54.000 The end result or the expected end result is that we can select the load and export parts 05:54.000 --> 05:59.680 of a project which would then allow for much better performance allowing for features like 05:59.680 --> 06:06.160 all the saving, fast saving and building new features like animation support for keyframes 06:06.160 --> 06:11.920 or pages which are a bit similar features instead of relying on layers as smooth plugins 06:12.000 --> 06:17.520 to now. That would be a good foundation to build these features on. I recommend checking 06:17.520 --> 06:26.400 out a Patreon post of our main of GIMP's maintainer shahan. Second feature that's on myself interested 06:26.400 --> 06:31.680 in is investigating hard the acceleration in GIMP. There are two ways hard the acceleration 06:31.680 --> 06:36.720 can be used in GIMP. That's the compute. Those are your filters, blending modes and color 06:36.800 --> 06:45.520 space and pixel encoding conversions and canvas rendering. There has been a compute support 06:45.520 --> 06:54.160 in GIMP's graphics library, Google for quite a long time but from for some time it has been 06:54.160 --> 07:00.400 disabled by default and even hidden as an experimental option. One of the reasons is overall stability 07:00.400 --> 07:06.320 which is not the greatest and second one is performance. I've spent some time putting together 07:06.320 --> 07:13.760 instrumentation to get a better idea of why OpenCL in Google is not as performance and turns out 07:13.760 --> 07:19.440 we're leaving some potential performance on the table and that's something I've been trying 07:19.440 --> 07:25.920 to investigate how to make better in the future. When I mentioned OpenCL maybe some of you are asking 07:26.000 --> 07:32.080 why OpenCL why not using CUDA or HIP or ROCKN more, any other feet or any other of the many 07:32.080 --> 07:38.880 APIs and maybe the higher level APIs as well. My answer to that right now is that it doesn't 07:38.880 --> 07:45.920 really matter because first of all we need to put together a model for compute to actually make use 07:45.920 --> 07:54.560 of graphics processing in the first place. That much about what's coming in the future releases 07:54.720 --> 08:00.640 now just some behind the scenes. There's a GIMP community these days which the main purpose is managing 08:00.640 --> 08:08.400 the funds that GIMP has to ensure that the community can thrive. There has been a change in the 08:08.400 --> 08:14.000 members of the community there's a new member which is Mitch, a long time contributor, a long time 08:14.000 --> 08:21.920 internal of GIMP. There is also a grant system on the way. Last year the GIMP may 08:21.920 --> 08:27.440 obtain as mentioned there are two grants over the ongoing one was for himself as the main 08:27.440 --> 08:32.640 maintainer and other for the maintainer of the graphics library. At the moment there are no 08:32.640 --> 08:40.640 grants going on which partially is due to the setup of how the grants are being done together with 08:40.640 --> 08:46.640 non-foundation which is the fiscal host of GIMP's funds. There have been some slowdowns because 08:46.640 --> 08:52.640 of the recent management changes on non-foundation site but right now we are very confident in the 08:52.640 --> 08:57.120 steps we are taking and we know that the foundation we're building now will be quite solid. 08:58.480 --> 09:03.920 Now it's just something about becoming a GIMP developer. GIMP is over 30 years old at this point 09:03.920 --> 09:11.200 and I'm not 30 thankfully just yet but I've contributed to getting over the end of the past 09:11.200 --> 09:18.160 but it was only not last year that I actually became a core developer by being invited into the team. 09:19.840 --> 09:24.080 I would just like to mention that anybody is always welcome in the team and it does not 09:24.080 --> 09:31.520 matter how much of an experience somebody has. Myself I joined mainly because I got to participate 09:31.520 --> 09:36.480 in Google Summer of Code which if there are any students around here and are thinking of applying 09:36.480 --> 09:45.920 or doing not know what you saw I very much recommend applying for it but at least from GIMP side 09:45.920 --> 09:53.040 the most appreciated is not the skill of how the developer you are. You can come in and just 09:53.040 --> 09:59.360 start asking questions we are always very much happy to explain stuff and just help you along 09:59.360 --> 10:05.920 to become a better developer. The most appreciated is that you show up and stay around 10:07.760 --> 10:14.560 and just what is it to be a GIMP developer or open source software developer? It's a 10:15.680 --> 10:22.160 I would just say it's a unique hobby and many of you I presume are open source contributors. Actually 10:22.160 --> 10:27.280 I can maybe ask who of you in the room contributes to an open source project if you could 10:27.440 --> 10:34.400 raise your hands at least about half of you here. So you know what it is what it is like spending 10:34.400 --> 10:39.600 a lot of time inside working on a project instead of using doing some conventional hobby. 10:39.600 --> 10:47.360 I very much enjoyed myself though it can be tiring at times. The first few items are almost like a 10:47.360 --> 10:55.360 job listing or job advertisement remote office, work from home, pick your own work, sounds all great. 10:57.600 --> 11:03.920 Most projects have openings at all times and it's all about coming in and joining and usually 11:03.920 --> 11:09.840 the community is just once people coming in and sticking around. So I would just like to 11:11.200 --> 11:16.560 encourage those of you who do not contribute yet or do not know how to start. I would just say 11:16.560 --> 11:22.960 join a discussion channel, go to the issue tracker of the project and start asking questions and 11:22.960 --> 11:30.480 be curious. And it's a tiring, it's almost a job contributing to open source projects so 11:30.480 --> 11:38.720 remember to rest as well. Last year I want to thank all the users of camp. It's not without you 11:38.720 --> 11:44.240 that we would want to continue contributing to camp and especially I want to thank all the 11:44.240 --> 11:49.920 contributors that helped the past year get all the releases out. I took all of these names from 11:49.920 --> 11:58.000 our news reports on gb.org slash news. I'm not sure if I missed somebody, I hope I did not, 11:58.000 --> 12:03.040 but all of the contributors are very much appreciated and I'm very much wanting to thank everybody 12:03.040 --> 12:08.320 who has contributed. And thank you all for coming this is all from my site and if you have any questions 12:08.320 --> 12:11.280 please ask. 12:11.440 --> 12:24.480 Thank you. We have to use the microphone for questions for the people online. So even if you 12:24.480 --> 12:28.560 share it, apparently it doesn't work with the video. 12:42.400 --> 12:48.320 First, thank you for the presentation. Second, my question is about the XCF file format. 12:49.200 --> 12:56.560 I know there are no concrete plans on how to develop it yet. Have you tried anything so far or 12:56.560 --> 13:02.320 looked at any solutions? And if so could you explain what kind of experiments you've already tried with it? 13:05.920 --> 13:11.760 Myself, I didn't look into any of that. I think there is already a discussion on going in the 13:11.760 --> 13:17.920 tracker. I didn't read it. There is way too much for me to read and wait a little time. 13:20.480 --> 13:25.440 I think there has been discussions about whether to use, for example, an SQLite database. 13:26.720 --> 13:31.520 I hope I'm not saying bogus, but I think for example, Krita in their project files makes you 13:31.520 --> 13:38.880 a use of SQLite. I'm not sure. I'm taking it for the report. That could be one way to approach it. 13:39.840 --> 13:44.400 But I don't think there has been any clear experimentation as to what could be the most 13:44.400 --> 13:47.280 performance or the most flexible. Okay, thank you. 13:47.680 --> 13:57.680 Any other questions you can put in your hand up and we'll get the mic, thank you. 13:58.640 --> 14:04.000 What's the look look at it? 14:12.160 --> 14:18.880 Just to follow up to the last question, SQLite would be an excellent storage mechanism or mail 14:18.880 --> 14:22.640 may or may not be an excellent storage. But the actual format isn't that slightly different, 14:23.200 --> 14:35.920 but I mean, format is more a markup and markdown or XML or could be. I've just gotten 14:35.920 --> 14:42.880 in recommendation the other day that whatever formats we choose, it would be saying to make it 14:42.880 --> 14:49.040 also in a way that's handcraftable instead of always relying on the GUI and automatic creation 14:49.040 --> 14:54.880 of the files to create test files for testing, which definitely if it is marked down, 14:54.880 --> 15:00.320 if it is XML or something could be very helpful. I was just using those as examples. 15:01.520 --> 15:05.920 It doesn't have to be any of those, but even just a plain text file with some simple format 15:05.920 --> 15:14.000 could be saying start. Cool. How long have you been running? I've been using it for many years. 15:14.000 --> 15:18.000 Well, I think it's been one of the longest running projects in the last year, 15:18.000 --> 15:22.400 the game has celebrated its 30th birthday, so this year it should be 31 years. 15:24.080 --> 15:28.480 Nice. Very cool. Any other questions? We've got a little bit more time. 15:35.680 --> 15:44.960 Thank you very much. Very cool projects. If you are curious about something more, 15:44.960 --> 15:49.840 or want to just drop by and say hi, if we have a burst of a feather session at one o'clock. 15:49.840 --> 15:54.480 Actually I want more questions. Are there any gimmstickers? Oh, yeah. I have gimmstickers on me, 15:54.480 --> 15:59.760 so if you want some, please. I really have gimmstickers on on the desk. Oh, yes. Thank you.