Graphics Planet

One of the primary tasks of an architectural visualization artist is to create a 3d model of an architectural project, in order to add lights and textures to create a realistic visualization of the building. Besides the main architectural project, we sometimes have to work on secondary 3d models or builds to compose the environment [...] Related posts:

1. Basic tutorial on how to model buildings with box modeling From all the techniques available to create 3d models for...
2. Modeling for architecture: How to create curved curtain walls in Blender 3D? At some point in the modeling process we have to...
3. Modeling stairs for architectural visualization with scripts in Blender 3D There are a few parts of an architectural visualization project...

• Luciana was munching on sausage slices. She grabbed the curved end of one sausage, looked carefully at it, and exclaimed, "look, a little vault!".

  I guess that's what she learns in this house.

O trabalho em escritórios de arquitetura ou como profissional especializado em visualização apresenta diversos pequenos desafios, como o gerenciamento de materiais e grandes bibliotecas de objetos 3d. Quando optamos por trabalhar com softwares que apresentam grande quantidade de opções em renderização como o 3ds Max, a incompatibilidade entre alguns objetos e materiais é fato corriqueiro. [...]

GEOM

PROPERTY GS_INPUT_PRIMITIVE TRIANGLES

PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP

The U.S. Supreme Courtis about to issue a ruling on a case that may invalided a lot of software patents and make patenting of software and busines process more difficult, if not impossible. A sensible view on that in the Economist. Countries with most international-patent applications. Filed under: intellectual property

The second week of our action plan for optimizing Krita was devoted to optimizing painting in Krita. Although there are many great paintops in Krita, digital painters tend to use most of the time the simple default brush engine which we call Pixel Brush. Painters can use GIMP brushes here, the text brush, but the most used brush tip is called Autobrush. You can setup the brush attributes like shape (circle, rectangle) and you can change the ratio to get an ellipse. Then you can change softness by vertical and horizontal fading. If you play with spikes and ratio, you get stars and other funny shapes. The brush has many dynamic attributes thanks Cyrille Berger’s work on concept called sensors. E.g. tablet can control the size by pressure, by tilt or anything you want (e.g. interesting is drawing angle) and it can be tuned by curve.

The algorithm, which computes the brush mask, stamped on the canvas regular as you stroke, is computed by the KisCircleMask::valueAt(). It is a computationally expensive function according valgrind logs we did week ago and many times before. David Revoy, team member of the Durian project, said that using 70px brush on 2500×2500 image was very slow in Krita. So we needed to optimize that.

I started with exploration of the code. I’m not the author of the autobrush, though I did most of the paintops in Krita (10 paintops are mine out of 19, many are experimental). First catch was the interpolation in the brush mask computation. We called valueAt() 4 times per pixel of the brush mask. We found out with Cyrille that the valueAt function used to take integer parameters a long long time ago and double values of the brush mask pixel positions were computed with interpolation. So I decided to remove the interpolation as the function has been capable to take double input long time ago. And the results of the valueAt() are more precise then interpolation. The benefit was great. Painting was 4x faster. Benchmark for random lines with changing size according pressure dropped from 18 seconds to 4 seconds on 4096×4096 image. Check it in the wiki, related table is called Just with performance fix.

From the valgrind logs we noticed that the atan2 function is called too often. “Chickenpump” suggested some cool old school tricks in comments. And so we gave that a try. I used double hashing with QHash in QHash for the 2D function atan2, but that was very slow due to low cache hit ratio and expensive hashing. Then Cyrille posted some links with free code which implemented a fast atan2 with an internal lookup table. So I ported that code to Krita. Cyrille did some magic stuff like computation with fixed precision on library loading time and some little tune ups to speed the fast atan2 computation and we managed to get more speed up around 1.3x faster then without fast atan2 function. There is probably some more room for optimizations as the fast atan2 implementation uses a quite small lookup table. Also I tested some other implementations, but it had problem with precision. It had 3 degrees error. That is too much for us, so I dropped that.

I remembered a quite interesting magic function for fast inverse square root used in Quake III. So I gave it a try as we use inverse square root in valueAt() too. I found out by benchmark that fast inverse square root is slower then directly computing the inverse square root (1/sqrt(x)). It used to be 4 times faster a long time ago. Probably Intel implemented that in processors already. Or the optimization done by compiler was not so effective in case of fast version. Again we dropped that.

Most of the use cases for painting include brush masks which are symmetrical. The algorithm could compute just 1/4 of the mask. Next step was implementing this.

First version used 4 pointers to the memory and compute 1 pixel and copy 3 pixels to the right region. I managed to get another 1.7x speed up (from 3.555 ms to 1.9 ms).

Memory access is very important and can slow down computation. It is like when you use setPixel/pixel method to access pixels in pixel buffer – you supposed to use scanlines, that is faster. Here is some interesting article about it. If you don’t have something to read, here is also nice CPU memory bible.

First version used 4 iterators over image pixels. One computation per pixel. And copy the values.

So I decided to make it little faster just by using two pointers. I compute 1/4 of the mask and copy this part to the NW region. And then I copy the rows in the lower part of the mask in correct order – I mirror it.

Improved version used two iteratiors and memcpy the second half of the brush mask.

I found out on friday evening that it does not work though. Circle masks seems symmetrical from user point of view, but they are not. The brush mask respects sub-pixel precision in Krita, so the edge pixels of the circle are not symmetrical. The sub-pixel precision is visible when you work with big zoom level. I have an idea for computation 1/4 of the brush mask, but I decided to post-pone it.

Other possibilities are still around:

1. mip-mapping : pre-compute various levels of brush mask to buffer and interpolate the masks. We do this for Gimp brush. We would interpolate two computed brush masks instead of computate the single mask. Maybe it could be faster, maybe not. The reason for mipmap in GIMP brush painting we have, was to increase the quality of the scaled brushes as Adrian Page, hacker in the Krita team, wrote me in an email. Mip-mapping would require to split rotation from the mask computation. This can lead to different results regarding of the brush mask. Now we consider the rotation in the mask computation. Then we would rotate un-rotated mask by image processing – rotate image. Some conformation rendering test would be needed. The advantage would be support for rotation of the gimp brushes in Krita.
2. cache the brush mask for mouse users: cache the dab as the mask doesn’t change. This would be nice if we did not compute sub-pixel precision. But we do that, so the cache hits ratio would be very small. It would be usable for 100% zoom, when sub-pixel position is zero. And of course big condition for checking of the parameter changes would be required.
3. Compute the mask with graphics card – use shaders: that would be cool, I have some initial experience with shaders but integration would be harder and probably too experimental for our plan. I’m mentioning this as we discussed this with Sven Langkamp in Oslo and so that it is not forgotten.
4. We will probably do some garbage recycling – memory allocation is slow, we can benefit from recycling memory. It is a matter of discussion on IRC at #krita on freenode. You are welcome to join.

Final time of the computation in benchmark for random lines is 1,449.2 ms. It dropped from 18,576 ms. So the painting was 16xtimes faster.But I revert the 1/4 of the brush mask speed up, so the current speed is 3.555 ms. Painting will be 6xtimes faster. The speed is considered to be usable for big brushes now. I invite you to do check-out of the trunk and try to play with big brushes. 200 px is now very usable on my laptop. What about yours?

I updated my WordPress blog. I dropped the previous classic WordPress theme and selected the default one – lazy developer. I did not like the font in the previous one. I don’t have much time to play with web-designing these days. But at least I customized the default Kubrick theme. I changed the fixed width of the theme to wider values. I did also simple custom header with some random strokes with my paintops in Krita. I hope you will like it. Every image in the blogpost is made in Krita.

As always, I took some pictures at FOSDEM 2010. Disappointingly I took less than last year: only 55 instead of 132 (and even that is cheating, because that includes a picture *of* me taken by xvello). Still, better than nothing, I guess... In any case, as always at FOSDEM, I had lots of fun, and that's what counts!

Friday morning, I taught the seventh session of an 8-session (40 minutes per session) course on Inkscape at a Boston-area middle school. (For more general details about the class check out my blog post on day 1.)

Friday’s Class

Well, this Inkscape course is quickly wrapping up. One more class after this past one on Friday. The students’ work was due at the end of this class and they all did great work in prepping their designs for the printer. I handed out a sheet with the export instructions (available for download below.)

We weren’t exactly sure the best approach to gather up the files at first; Ken had set up a shared drive on the network for the students to save their work to, but on some of the Macs, Inkscape’s export bitmap dialog could not see the shared drive (and some could!) What we ended up doing:

• Have the students export their work out to the desktop – 300 dpi, PNG format.
• I asked them to use either their band name or their own name in the file so I could tell them apart.
• Then, ask them open up the appropriate network drive folder and drag both the exported file and original SVG into it from the desktop.
• I then connected to the shared drive, inspected all the files to make sure they had exported correctly (they had! If they hadn’t, I would have gone back to the students whose files had issues and tried to help them re-export them.)
• I then copied the files from the network drive onto a USB key.
• Immediately after I got back to the office, I went through the files carefully, adding the requested T-shirt size from the students’ filled-out T-shirt size sign-up sheet from day 5 of class. My naming scheme was the following format:
  

  01-studentfirstname-bandname-sizeS.png

• I then uploaded the files to a URL, both as individual files and bundled in a zip file for Walter’s convenience – then I emailed Walter the URLs.
• John called Walter from EmbroidMe Chelmsford up to make sure he had gotten the email (he hadn’t yet, so great thinking on John’s part) and Walter set out setting up the T-shirts that morning.

A few things we learned from this process I think you could take away in teaching a similar class to make it run more smoothly:

• Make sure you pass that T-shirt size signup sheet around early on, and keep bringing it back to class until every student has filled it out. Students are absent sometimes, especially in the winter cold season, and you want to make sure you’ve got each student’s size.
• We had one student absent this past Friday. We’ll get his file on the last day of class and get his T-shirt to him after the class is over. That being said, you may want to have the students save out to a shared drive throughout the class (we weren’t doing that, we were having them use their individual accounts) and in the days of class past the halfway mark of the entire course, ask the students if they are going to be there for every day, and if not would they like us to go ahead and print their files if they’re not there or to wait.
• Make it easier for your printer and put the students’ T-shirt sizes in the file name.
• Make sure you get the students’ SVGs as well as PNGs! Rendering PNGs from SVGs with a lot of blurs can take a long time! I was really surprised by this. The Whisp logo took the longest – a good 15-20 minutes to render! If you have the students’ SVG files as well and run out of time during class, it enables you to do the rendering on your own post-class to make sure the printer will get the files on time. It’s also good to have the SVGs in case you or the printer notice any issues with the PNG that might have been missed during class.
• Bundling the files into one compressed file makes it easier for them to download than individual files.
• If you’re on a tight deadline, don’t rely on email only – give your printer a call!

Many students were finished with time to spare, so they had the rest of the period to explore Inkscape on their own. They came up with some very cool sketches using the techniques they learned throughout the class:

You can see the full set of photos John took of the students’ work in the Flickr album for session 7. On Tuesday, if all goes well (fingers crossed!) we’ll hand out the T-shirts and do some fun exercises with Inkscape, so look forward to those photos.

Follow Along on Your Own

Here’s the lesson sheet we used for class on Friday:

Introduction to Inkscape Lesson 7

As always, the OpenOffice.org source files and the outlines for the entire course are at the course page on my website – but please note that’s a rough outline; as we progress through the class I’m coming up with the more-solid lesson plans based on how far the students get each session. By the end of the course I hope to have the course page organized much better.

By the way, if you’d like to follow all the blog posts about this class at one URL without getting the rest of my feed, I’ve set up a category in WordPress specifically for these posts:

http://mairin.wordpress.com/category/inkscape-class/

Enjoy! And please do let me know in the comments if you have any questions or suggestions

This course is sponsored by

Filed under: Inkscape Class

Yaletown at night seen from the bottom of the Cambie bridge at Spyglass place, Vancouver, BC

Seen a few meters from this.

Vancouver, BC, Canada - February 3rd 2010

I had the opportunity to participate in a focus group on NASA's new "citizen science" project, called Moon Zoo, with a bunch of other fellow lunatics, amateur astronomers and lunar enthusiasts.

Moon Zoo sounds really interesting. Ordinary people will analyze high-resolution photos of the lunar surface: find out how many boulders and craters are there. I hope it will also include more details like crater type and size, rilles and so forth, though that wasn't mentioned. These are all tasks that are easy for a human and hard for a computer: perfect for crowdsourcing. Think Galaxy Zoo for the moon. The resulting data will be used for planning future lunar missions as well as for general lunar science.

It sounds like a great project and I'm excited about it. But I'm not going to write about Moon Zoo today -- it doesn't exist yet (current estimate is mid-March), though there is a preliminary PDF. Instead, I want to talk about some of the great ideas that came out of the focus group.

The primary question: How do we get people -- both amateur astronomers and the general public, people of all ages -- interested in contributing to a citizen science project like Moon Zoo?

Here are some of the key ideas:

Make the data public

This was the most important point, echoed by a lot of participants. Some people felt that many of the existing "citizen science" projects project the attitude "We want something from you, but we're not going to give you anything in return." If you use crowdsourcing to create a dataset, make it available to the crowd.

Opening the data has a lot of advantages:

• People can make "mashups", useful sites that display your data in useful ways or combine it with other data. This can generate more interest in your project and more contributors.
• School groups can work on class projects or science fair projects, probably contributing more data along the way.
• It might help the next generation of scientist get started.
• It shows openness and good faith: witness the recent blow-up over the leaked IPCC emails and the debate over how much climate data has been kept private.

Projects like Wikipedia and Open Street Map, as well as Linux and the rest of the open source movement, show how much an open data model can inspire contributions.

Give credit to individuals and teams

People cited the example of SETI@Home, where teams of contributors can compete to see who's contributed the most. Show rankings for both individuals and groups, so they can track their progress and maybe get a bit competitive with other groups. Highlight groups and individuals who contribute a lot -- maybe even make it a formal competition and offer inexpensive prizes like T-shirts or mugs.

A teenaged panel member had the great suggestion of making buttons that said "I'm a Moon Zookeeper." Little rewards like that don't cost much but can really motivate people.

Offer an offline version

They wanted to hear ideas for publicizing Moon Zoo to groups like our local astronomy clubs.

I mentioned that I've often wanted to spread the word about Galaxy Zoo, but it's entirely a web-based application and when I give talks to clubs or school groups, web access is never an option. (Ironically, the person leading the focus group had planned to demonstrate Galaxy Zoo to us but couldn't get connected to the wi-fi at the Lawrence Hall of Science.)

Projects are so much easier to evangelize if you can download an offline demo.

And not just a demo, either. There should be a way to download a real version, including a small data set. Imagine if you could grab a Moon Zoo pack and do a little classifying whenever you got a few spare minutes -- on the airplane or train, or in a hotel room while traveling.

Important note: this does not mean you should write a separate Windows app for people to download. Keep it HTML, Javascript and cross platform so everyone can run it. Then let people download a local copy of the same web app they run on your site.

Make sure it works on phones and game consoles

Lots of people use smartphones more than they use a desktop computer these days. Make sure the app runs on all the popular smartphones. And lots of kids have access to handheld web-enabled game consoles: you can reach a whole new set of kids by supporting these platforms.

Offer levels of accomplishment, like a game

Lots of people are competitive by nature, and like to feel they're getting better at what they're doing. Play to that: let users advance as they get more experienced, and give them the option of doing harder projects. "I'm up to level 7 in Moon Zoo!"

Use social networking

Facebook. Twitter. Nuff said.

Don't keep results a secret

Quite a few scientific publications have arisen out of Galaxy Zoo -- yet although most of us were familiar with Galaxy Zoo, few of us knew that. Why so secretive? They should be trumpeting achievements like that.

How many times have you volunteered for a survey or study, then wondered for years afterward how the results came out? Researchers never contact the volunteers when the paper is finally published. It's frustrating and demotivating; it makes you not want to volunteer again. Lots of us sign up because we're curious about the science -- but that means we're also curious about the results.

With citizen science projects, this is particularly easy. Set up a mailing list or forum (or both) to discuss results and announce when papers are published. Set up a Twitter account and a Facebook group to announce new papers to anyone who wants to follow. This is the age of Web 2.0, folks -- there's no excuse for not communicating.

I don't know if NASA will listen to our ideas. But I hope they do. Moon Zoo promises to be a terrific project ... and the more of these principles they follow, the more dedicated volunteers they'll get and that will make the project even better.

Hi all

I’m reaching production ready levels for the surfacing algorithm , it has already outperformed the instanced metaballs approach in orders of magnitude compared with my earliest raw implementation, just see it for yourself in the following videos

I want to point out that there is still plenty room for improvements and speed gains as currently there’s no cache implemented nor OpenGL VBO´s

hope you like it

Previous implementation:

<object data="http://www.vimeo.com/moogaloop.swf?clip_id=9255657&amp;server=www.vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=01AAEA" height="300" type="application/x-shockwave-flash" width="400"> <param name="quality" value="best"> <param name="allowfullscreen" value="true"> <param name="scale" value="showAll"> <param name="movie" value="http://www.vimeo.com/moogaloop.swf?clip_id=9255657&amp;server=www.vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=01AAEA"> </object>

Current optimized implementation:

<object data="http://www.vimeo.com/moogaloop.swf?clip_id=9255766&amp;server=www.vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=01AAEA" height="300" type="application/x-shockwave-flash" width="400"> <param name="quality" value="best"> <param name="allowfullscreen" value="true"> <param name="scale" value="showAll"> <param name="movie" value="http://www.vimeo.com/moogaloop.swf?clip_id=9255766&amp;server=www.vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=01AAEA"> </object>

Cheers  Farsthary

Hi folks

As many of you may know, in a month Blendiac and WhifeofBlendiac will come to Cuba and visit myself bringing me all the cool stuffs the community send me , especially internet/digital content and support that for me is impossible to get in other way (thanks!!!)  so in order to avoid last time Blendiac’s overworks I propose to send me to this email account links to downloadable contents.

farsthary84@gmail.com

This way, he won’t lose time looking alone for all the interesting resources.

This year’s topics will be:

OpenCL ,  CUDA , ATI Stream , GPGPU , Rendering Revolution , Volumetric sculpting , Sculpting , Retopology , Remeshing , Voxel related stuffs.

Multithread programming , Advanced Programming Techniques , Data Structures .

Demo of the commercially available 3D softs (Max, Maya, Houdini, Softimage, Modo, 3D coat, Mudbox, C4D, Zbrush, Ligthwave, Realflow, etc) to get the state of the art in the competence

And this is very important , Blender resources , because for the increasing number of Cubans that are gaining interest in Blender is simply impossible to get access to them so I propose to gather a huge database of videos (youtube, vimeo,etc), tutorials, timelapses, demoreels (I want to know what the excellent artist do )

And also inspiring artworks are very much appreciated , not restricted to Blender content , cool 3d shorts, demos, etc

I’m not a learning machine so surprise me with enjoyable content

Thanks in advance

Farsthary

As always, we had the KDE Group Picture taken at FOSDEM. It went pretty smooth this year, apart from not immediately hearing when the autotimer of the camera clicked

[Edit: Hmmm why does this not show up in the feeds?]

Yes, that is. After so much time, all code, documentation, testbed, utilities... all is in the box, and all is working!

In one day or two I will announce the beta availability to the lcms mailing list, but meanwhile, you can be the very first to try it.

http://www.littlecms.com/lcms2-2.0beta1.tar.gz

Enjoy!

A modelagem de projetos para arquitetura é um trabalho metódico e cansativo, mas o processo que envolve compor um cenário maior em que esse tipo de edificação deve ser posicionado é pior ainda. O problema é que o projeto principal ainda acompanha diversas ilustrações de referência e até mesmo desenhos técnicos. Mas, ao posicionar a [...]

No próximo dia 10 de Fevereiro um dos ícones da computação gráfica está comemorando 20 anos de existência. O photoshop já está no mercado ajudando pessoas a tratar imagens e fotografias desde o final dos anos 80, e ajudou a Adobe a se consolidar como uma das maiores empresas de computação gráfica do mundo. Ainda [...]

Inukshuk along the seawall in Vancouver, BC, around Stanley Park on Christmas day.

Vancouver, BC, Canada - December 25th 2009

Update: it is actually closer to English Bay.

I’m a big fan of short-form presentations, and I like to give one whenever I get a chance. I also like to encourage others to do them for other conferences I’ve organised or run, like  GUADEC, the Maemo Summit or Fostel (site seems to be down now – shame).

I’ve been an admirer from afar of Ignite for years, for the variety and quality of the presentations that you find at their events, and seeing Global Ignite Week announced a few months ago, around the same time that PLOSS Rhone-Alpes started coming together gave me an excuse to do what I’ve wanted to for a while, and host an Ignite Lyon event! The inaugural Ignite Lyon will be held on March 4th in Université Lyon 2 on the quais.

For those unfamiliar with the Ignite talk format, you get 5 minutes for your talk – 20 slides, which advance automatically every 15 seconds. There are lots of Ignite videos on the site.

Once again I’m teaming up with Vincent Mabillot from Colibre, with whom I co-organised Richard Stallman’s recent stop in Lyon last month, and François Aubriot from PLOSS R-A and DotRiver, as well as all of the members of ALDIL and PLOSS R-A who have time to give in this busy month (in addition to school holidays, ALDIL and Colibre are once again participating in the conference Primevere and the week-long “Libre en fête” festival of free software).

I’m looking for presenters! I want to hear cool stuff – personal passions, unusual hobbies or projects, complete with pitfalls and tiny successes that led to a fun conclusion, advice on how to handle difficult problems we all meet, tips on reducing your carbon footprint, how your non-profit group made a difference in your neighbourhood, cries of passion for people to stop doing something you care about *wrong*. Ignite is not just IT, and that’s what I love about it. I will be giving a presentation myself called “hacking your body”, talking about running as performance testing for real life. Of course, it’s also IT, so the geekier and cooler your project, the better If you’re into soldering your own chopper bicycles, I want to hear about it.

As you’ve figured out, I want to hear from you if you have something interesting to say. We’re expecing 100 people from a range of backgrounds, including entrepreneurs, hackers, makers, DIY fans and general geeks & freaks (in the nicest sense). If you want to submit a talk, please use the online form I set up.

Taken tonight, from the Cambie bridge in Vancouver, BC toward the science center over False Creek.

Not from the same vantage point as this

Vancouver, BC, Canada - February 3rd 2010

A técnica mais usada para modelagem de especializada em arquitetura é a poligonal ou a derivação da subdivisão chamada de edge modeling. O uso de curvas ou técnicas como o NURBS, acaba sendo restrita a modelagem de móveis e objetos que precisem das ferramentas avançadas de modelagem para superfícies. Um dos softwares que possuem grande [...]

On January 23 Alastair M. Robinson silently released first public version of CMYKTool. That would go quite unnoticed if it wasn’t for someone liking to read all sorts of RSS feeds So the very next day linuxgraphics.ru community was already discussing the new tool, discovering bugs and requesting features. The thread was so [...]

More and more we’re seeing organisations outside the free software world  try to learn the lessons of our success, and integrate “open source” practices into their organisation.

Whether it’s companies adopting transparency and other cluetrain or pinko marketing strategies, proprietary software development companies integrating standard free software practices, or one of the other areas where “crowdsourcing” has become the cool new thing, it’s obvious hat we have gotten some things right, some of the time, and it is definitely worth learning the right lessons from projects like Linux, Mozilla, GNOME, or Wikipedia, and trying to reproduce the magic elsewhere.

Sometimes this feels like the cargo cults in the Pacific Islands, trying to make airplanes land as their ancestors saw 60 years ago, by building airstrips and imitation airplanes. But at least they’re trying to figure out what makes our communities successful.

But are we learning enough lessons from others? It seems to me like we’re charging head first like sharecroppers into undiscovered country, only to find that we’ve run into a highly advanced civilisation.

As developers, we’ve invented our own brand of everything, from scratch. We figure out how to run conferences, or raise money from people who like what we do, when these are not new problems.

This isn’t new in IT. The entire learned history of typography got thrown out the window more or less, because with the advent of WYSIWYG editors and the web, everyone has complete control of their authoring tools and Comic Sans is shipped by default, and if I need to reduce the margins to get the letter to fit on one page then by golly I will.

Merchandising and recruitment of new star talent are more examples of things that some other organisations are pretty good at.

So – as an open question – are we learning the lessons from the past which we should be learning, or is it too attractive to think that what we’re doing is so new that every problem we encounter needs a new solution?

One example of a place where there is a wealth of experience out there is convincing people to give money to a cause they believe in. There are dozens of organisations that do this well – humanitarian organisations, political lobbyists, political parties, universities – the list goes on.

Can we figure out how GNOME is like them, and learn the lessons from their fundraising campaigns?

A typical fundraising drive for an organisation like this has three main steps:

1. Get a list of potential donors
2. Convince them that you are doing good
3. Find a pressure point or argument which will convince them to donate

If you look at a mailing for Médecins Sans Frontières for example, you see all of these points in action. Find potential donors – through sign-up campaigns, former donor drives, referrals. Send them a mail package, with a newsletter outlining good work, but with just enough bad news (new conflicts, new refugees, unfinished projects) and artwork (a smiling nurse taking care of a village vs a child ill from a curable illness) to show that money given to MSF will do good, and the need has never been greater.

Your response rate may be small – perhaps only 1% – but that’s enough.

Whether we’re talking about lobby groups, political parties or humanitarian agencies, the same strategies come into play – construct big databases of potential donors, and get them riled up about the thing they’re passionate about being endangered – show them the shining light of all the good work your organisation does, and then drive the sale home by making it really easy to give money or sign up.

University fundraising is an interesting case – and in fact, GNOME’s fundraising model ressembles it now. Your primary source of donations is alumni, people who have been through the university, like receiving updates every year, maybe a class-mate just became a professor, maybe a friend’s daughter got a prize in the annual awards ceremony, maybe a club or association you were in had a good year? And then you leverage the affection with the flip side of the coin – the need, the things we’d like to do better, the project we’re fundraising for which will allow us to do great work.

All of these organisations invest heavily in direct mailing, in building and maintaining databases of supporters, and in monetising them. I recently read a book by a direct mailing copywriter called “My First 40 Years in Junk Mail” and it opened my eyes to what works in that world – and also gave some ideas on the kinds of strategies maybe the GNOME Foundation should be adopting.

The first step  is building and maintaining a list of GNOME fans and supporters, by any means possible, and ensuring that they are made aware of what we’re up to and what we’d like to do. And, of course, continuing to build great products.

Gillius ADF is a sans-serif typeface, heavily inspired by the famous Gill Sans MT typeface by Eric Gill – who designed Gill Sans inspired by the Johnston typeface designed for the London Underground which Gill had worked on as an apprentice.

The Arkandis Digital Foundry created the Gillius ADF font under the GPL with font exception. There is an alternative version available too (that also needs packaging ) called Gillus ADF No. 2. Each font has regular and condensed variants, each with bold, italic, and bold italic versions. The coverage is not bad for extended Latin characters:

Gillius ADF is a nice, clean font that should serve you well both in regular body text in documents as well as for headings and logo treatments. It’s a versatile and very readable font, just like the Gill Sans typeface that inspired it. One thing you might want to be aware of when working with Gillius ADF – just as cultural context anyway – in the same way that Helvetica is used heavily in the United States, especially on municipal and transit system signage, Gill Sans is used heavily in the UK and recalls ‘mid-century’ type usage in the UK. Gillius ADF, since it refers so closely to Gill Sans, might carry a bit of a UK connotation to it.

(Btw, I purposely picked a word with a lowercase ‘g’ in it for my little type sample because I really like the ‘g’ in Gillius Sans. )

Gillus ADF is licensed under the GPL with Font Exception.

• Fedora Font Wishlist Entry:https://fedoraproject.org/wiki/ADF_Gillius_fonts
• Upstream Homepage: http://arkandis.tuxfamily.org/openfonts.html

So, you want to package Gillius ADF?

Zomg! You’re sweet! You’ll want to follow the first steps here next to the ‘if you intend to do some packaging’ header:

• https://fedoraproject.org/wiki/Joining_the_Fonts_SIG

Our fonts packaging policy, which the above refers to, is documented here:

• https://fedoraproject.org/wiki/Category:Fonts_packaging

And if you have any questions throughout the process, don’t hesitate to ask on the Fedora Fonts SIG mailing list:

• https://admin.fedoraproject.org/mailman/listinfo/fonts.

Last Week’s Font

Last week’s font was League Gothic by The League of Moveable Type. Nobody has picked up the font package request yet! Would you like to?

Filed under: Unpackaged Font of the Week

I spent a morning wrestling with git after writing a minor GIMP fix that I wanted to check in. Deceptively simple ideas, like "Check the git log to see the expected format of check-in messages", turned out to be easier said than done.

Part of the problem was git's default colors: colors calculated to be invisible to anyone using a terminal with dark text on a light background. And that sent me down the perilous path of git configuration.

git-config does have a manual page. But it lacks detail: you can't get from there to knowing what to change so that the first line of commits in git log doesn't show up yellow.

But that's okay, thought I: all I need to do is list the default settings, then change anything that's a light color like yellow to a darker color. Easy, right?

Well, no. It turns out there's no way to get the default settings -- because they aren't part of git's config; they're hardwired into the C code.

But you can find most of them with a seach for GIT_COLOR in the source. The most useful lines are these the ones in diff.c, builtin-branch.c and wt-status.c.

gitconfig

The next step is to translate those C lines to git preferences, something you can put in a .gitconfig. Here's a list of all the colors mentioned in the man page, and their default values -- I used "normal" for grep and interactive where I wasn't sure of the defaults.

[color "diff"]
	plain = normal
	meta = bold
	frag = cyan
	old = red
	new = green
	commit = yellow
	whitespace = normal red
[color "branch"]
	current = green
	local = normal
	remote = red
	plain = normal
[color "status"]
	header = normal
	added = red
	updated = green
	changed = red
	untracked = red
	nobranch = red
[color "grep"]
	match = normal
[color "interactive"]
	prompt = normal
	header = normal
	help = normal
	error = normal

The syntax and colors are fairly clearly explained in the manual: allowable colors are normal, black, red, green, yellow, blue, magenta, cyan and white. After the foreground color, you can optionally list a background color. You can also list an attribute, chosen from bold, dim, ul, blink and reverse -- only one at a time, no combining of attributes.

So if you really wanted to, you could say something like

[color "status"]
	header = normal blink
	added = magenta yellow
	updated = green reverse
	changed = red bold
	untracked = blue white
	nobranch = red white bold

Minimal changes for light backgrounds

What's the minimum you need to get everything readable? On the light grey background I use, I needed to change the yellow, cyan and green entries:

[color "diff"]
	frag = cyan
	new = green
	commit = yellow
[color "branch"]
	current = green
[color "status"]
	updated = green

Disclaimer: I haven't tested all these settings -- because I haven't yet figured out where all of them apply. That's another area where the manual is a bit short on detail ...

Rensselaer Polytechnic Institute, or more affectionately known as RPI, is my alma mater. It was pretty clear to me early on that it was the right school for me. Behold, the RPI campus computing center (Voorhees Computing Center):

That’s right, it’s inside of a church – they take computing seriously at RPI – obviously a great place to recruit current and future free & open source hackers!

I’ll be at the RPI Spring 2010 Career Fair in Troy, NY with my colleague John (who also started the Inkscape class project) – we’ll be representing Red Hat as two past RPI students. If you are an RPI student and are interested in a career at Red Hat, please stop by our booth at the Armory between 12 – 5 pm tomorrow – say hi and see what opportunities we might have for you!

By the way, I’ll be back on campus this Friday, February 5th to give a talk about Fedora, from 4-5 PM in JEC 3117. More details are at the Rensselaer Center for Open Source website. I’ll have plenty of Fedora swag, so if you’re in the capital region and are interested please stop by and say hi if you can!

Filed under: Uncategorized

Uma das partes mais difíceis de estudar na computação gráfica 3d é a iluminação de ambientes virtuais que pode se transformar em verdadeiro desafio para qualquer artista. Isso se deve ao fato das cenas e ambientes representarem sempre mudam em cada projeto, fazendo com que o artista realize ajustes na intensidade e posicionamento dos pontos [...]

Yesterday morning, I taught the sixth session of an 8-session (40 minutes per session) course on Inkscape at a Boston-area middle school. (For more general details about the class check out my blog post on day 1.)

Yesterday’s Class

Yesterday’s class, like last Thursday’s class, was primarily a working class. After this class we have only two sessions left, and the students’ artwork is due at the end of next session, so we’ve been giving them as much time as possible during class to work on their designs.

When I passed out the shirt size signup sheet last week, one of the students was absent, so I got his size and sent Walter at EmbroidMe Chelmsford a quick email listing of all the T-shirt sizes we’d need so he would be ready to have the shirts printed when we send the designs on Friday.

I gave some quick instructions on working with the align & distribute tool in Inkscape – since we are getting close to the end of class, I thought going over alignments would be helpful for the students in making final preparations for their artwork to be handed off. One of the scenarios I used to explain align & distribute was making a template for a CD design, and how to use the tool to center the hole in the center of the CD to the circle shape for the actual disc.

Some things that came up while the students worked on their designs.

One student wanted to space some shapes surrounding a center circle at even intervals. I struggled a bit to explain how to do this – we tried using the ‘Remove overlaps’ section of the align & distribute tool, but it turns out that ‘remove overlaps’ behaves really strangely when you’re working with circular shapes. I would expect it to either calculate the spacing between the two objects based on the frame around the circular object, or between the outer edge of the shape at the point where the two shapes are closest together. Instead, it calculates based on the right-most point of the left circle, and the left-most point of the right circle, which results in the tool taking somewhat un-intuitive actions. I ended up instructing her to go around the center circle, clicking two of the outside objects at a time, and using the right-align, bottom-align, left-align, and top-align buttons all around the center circle to get things lined up. A bit more tedious, but at least it seemed to work more predictably than using ‘Remove overlaps.’ You can see her design in the photo above, in case this issue is hard to visualize.

Another student wanted a sword to run through a snake such that one part of the snake was above the sword, and the other was under the sword. We made a copy of the snake using Ctrl + D and a copy of the sword using Ctrl + D, then we used Path > Intersect to get two pieces of the sword from where the snake intersected with it. We used Path > Break Apart to seperate the two sword pieces, and deleted the sword piece that covered the snake in the area where she wanted the snake to run over the sword.

One of the students made some really cool textures using a radial gradient with a lot of different points. However, he faced the challenge of part of his band name not being readable because the background coloration was so vivid behind the letters. I showed him how to make a copy of the text, give it a thick stroke in either white or black, then place it behind the original text so that there was a white outline behind the text to help make it readable. I also showed him how to blur the outline to give it more of a glow effect.

You can see the full set of photos John took of the students work in the Flickr album for session 6. You might start to notice a ‘blood’ theme here I think maybe all the vampires from Twilight have had a bit of influence on our youth

I mentioned in earlier posts that the students were very quiet – during these working sessions they’re definitely a bit more social now, talking to each other and helping each other out. I’m really happy to see that happening.

Follow Along on Your Own

Here’s the lesson sheet we used for class yesterday:

Introduction to Inkscape Lesson 6

As always, the OpenOffice.org source files and the outlines for the entire course are at the course page on my website – but please note that’s a rough outline; as we progress through the class I’m coming up with the more-solid lesson plans based on how far the students get each session. By the end of the course I hope to have the course page organized much better.

By the way, if you’d like to follow all the blog posts about this class at one URL without getting the rest of my feed, I’ve set up a category in WordPress specifically for these posts:

http://mairin.wordpress.com/category/inkscape-class/

Enjoy! And please do let me know in the comments if you have any questions or suggestions

This course is sponsored by

Filed under: Inkscape Class

I'm keeping my promise to write a weekly update on what has happened in Krita. There's usually a lot to write about, and I'm trying to add some generally interesting things, some personal, some artistic, so it's not just a commit digest, but a little bit more.

But I'm wondering how to syndicate it -- Planet KDE is meant for personal blogs, and this isn't personal. I'm not sure about the other planets my blog is syndicated. And I've had complaints that having a pointer to the new issue on my blog is a bit spammy, and I think I agree with that. So I'm intentionally not linking to Krita.org this time :-) (But it's a good read!)

Does anybody have any bright ideas?

---

Update: I just learned that if I can teach krita.org to put the Last Week in Krita articles in an rss feed that's unique for what I post, i.e, personal, but from krita.org, I'm fine. I bet our webmaster can figure out how to do that, right Kubuntiac :-)

One of the most used tools to create rough studies and models for architectural visualization is SketchUp, because of the easy to use and speed in which we can create 3d models. So far, if we wanted to render a project designed with SketchUp and with photo real algorithms, we had to turn to commercial [...] Related posts:

1. Free grass patch for external visualization with LuxRender and Blender 3D One of the elements in external visualization projects that easily...
2. Comparison between YafaRay, LuxRender, Indigo Renderer and Maxwell Render for architecture The number of external renders engines compatible with Blender 3D...
3. Free version of SketchUp with no support for DWG and DXF files A lot of architectural visualization artists start their projects or...

O SketchUp é uma ferramenta excelente para modelagem 3d e visualização rápida de projetos arquitetônicos, mas se existe uma área em que o mesmo deixa a desejar é na renderização. Hoje em dia existem diversas soluções comerciais para solucionar esse tipo de deficiência que abrangem opções famosas como o V-Ray, amplamente usado em conjunto com [...]

After a lot of work in the last two weeks I went a bit under the weather this (for me long) weekend. I think I’ll be fit again when school starts. Sometimes I think it would be smarter to move the schedule of the down time from free time to school time….

But there are two nice places to check out for you in the time until the next show.

GIMPtricks on Youtube are made by Jolie from the Netherlands. I recommend to get a close shave with the healing tool and then check out the rest.

And if you have caught yourself wanting to print a logo on a plain T-Shirt after  you made an image from it - here is the solution in Spanish and English made by a young woman in Venezuela. There are 5 more videos to watch. (Thanks to medyr for the tip.)

So, drown them in Clicks!

I finished all my exams on time, so last Monday I could starting working full-time on Krita. I’ve now been at it for a full week! How does it go?

First week according the plan was aimed at measuring the speed of Krita. We talked about our bottlenecks on IRC regulary. We also talked about them in Oslo. But we didn’t have any numbers. Sven Langkamp did some benchmarks using QTime on iterators, there were some performence tests scattered in unit tests etc. Boudewijn has decided to use new benchmark features from Qt4.6. So I wrote 10 benchmark classes where we benchmarked stuff like internal data memory management for images – our tile engine. Some access classes which access pixels for use called iterators. They allow to iterate over pixels in various ways. Vertically, horizontally , in small rectangles, randomly etc.

Another important thing is compositing. That is the work of class called KisPainter (something like QPainter in Qt but with different complicated features not available in QPainter). We benchmarked the speed of bitBlt operation with two types of memory storage. First is KisPaintDevice and second one is called KisFixedPaintDevice. The later one is lightweight version of the first one. It is similar to QPaintDevice in Qt but again with more complicated features.

Øyvind Kolås a.k.a. pippin, Gegl developer is around. Pippin shared his knowledge about benchmarking with us on irc (btw come and visit as at #krita on irc.freenode.net) We decided to make tests for blur and brightness/contrast filter. The first one is convolution filter, the second one is here because we wanted to be able to compare to GIMP.

We also made a benchmark for the image projection. The projection benchmark loads an image in Krita’s native format, computes the whole image constructed from various types of layers like group, filter, adjustment layer etc. and in the end we again save the file into native Krita format. Our focus through this plan is to speed up painting. So we can’t avoid stroke benchmarks.

Thanks go to Sven Langkamp for his work on presets saving/loading. Using paintop presets, we can use the benchmark code I did, for any paintop. We benchmarked our autobrush default paintop. It is most used paintop for digital painters. I’m very happy about this benchmark as I can test my other paintops easily, all I need to do is create a preset for any paintop, save it in Krita and run the benchmark with the preset.

There results of the benchmars are on our wiki.

So it looks: The data manager, which is responsible undo/redo and basically for storing and retrieving data is fast. It allows us to read/write data at very high speeds.  From 1333.3 Mb/s to 1628.4 Mb/s, according to the benchmark results. We benchmarked on 4096×4094 RGBA image (64 Mb) which was read/wrote 100 times. For comparison memcpy for two buffers of the same size as the image we used is almost the same speed. There is benchmark code for memcpy in KisDatamanagerBenchmark, you can try it yourself if you want

Horizontal and vertical iterators are 11 times slower then Rectangular iterator. The reason is that there is no caching. From valgrind logs we see that fetching and switching tiles is very slow, so we need to implement caching there. Every 64 pixels a new tile is fetched and switched to. Why? Our tile is size of 64 pixels. This slow downs the iteration. We will cache the both iterators to avoid switching and fetching. We will cache tiles, we don’t do that now. The rectangular iterator is quite fast, does not offer so many opportunities to improve. The random iterator on the other hand is the slowest one. Again fetching and switching to tiles is expensive. Some caching strategy would be handy for moving around the image. But the use case for using the random accessor is different so the cache strategy should be somehow adaptive. The random accessor is 13-times slower than rectangular one.

The compositing operation also known as BitBlt of KisPainter is used very often. There is room for improvements, because currently it uses a slow iterator – random iterator. The speed is very decent, but we will try to make a lot faster.

Filters are very slow compared to GIMP. At least according the numbers pippin provided. But first we need to improve underlying issues like the aforementioned iterators to improve their performance. We blur the image with speed of 0.8 Mb/s. Here we need to optimize the convolution painter. Also the speed could be better when we optimize the horizontal iterator.

Strokes are slow because of the recomputation of the brush mask is needed  every dab – every time brush touches the canvas in certain point. That’s slow. You can see from the valgrind log, that the math function atan2 is slow. We have to cache the result to avoid this.

The conclusion at the end of the first week is that we need to cache iterators and cache the brush mask. Some parts of Krita have very nice speed like the tile engine. Then we have slow parts like iterators. I think we can gather a good performance boost with our plan.

This past Thursday morning, I taught the fifth session of an 8-session (40 minutes per session) course on Inkscape at a Boston-area middle school. (For more general details about the class check out my blog post on day 1.)

Thursday’s Class

Thursday’s class was primarily a working class.

First, we passed around a sheet for the students to write out their name, band name, and T-shirt size so EmbroidMe Chelmsford can have the correct size T-shirts ready to go. Then we passed out sheets with a calendar / schedule for the rest of the class. We’re halfway through the course – there are 4 sessions left – so the students’ due date for their design is the end of the second-to-last class on February 5th.

Then, I set out a sheet with some suggested band names that any student who was still stuck on a name could pick from. One idea for using this sheet in your own class could be to cut the band names into little squares and have students pick them out of a hat early on in the course. The students seemed to have settled on either using a band name of their choice (one student is doing the logo for a band he is actually in!) or doing ‘band’ logo using their name.

Last week, I sent Walter at EmbroidMe Chelmsford a demo design created in Inkscape for us to test out how well Inkscape-produced files work with his printing process. Some of the effects such as path clipping and blur did not come out right when he tried the SVG, so we decided to work with 300 dpi PNG exports. The shirt came out great, and I wore it to class as an example for the students, showing them the original file and finished T-shirt side-by-side. I then quickly showed the students how to set their canvas size to 13″ x 15″ so they could see the boundaries of where their designs would print on the T-shirt. One important thing I tried to remind them of is that the shirts will be heather grey, and there is no white ink, so any areas that are white in their file will turn out heather grey / no ink. You can see this in the snowcap of the Inkscape logo mountain in the test t-shirt, as I’m pointing out in the photo below:

The only instruction besides that was a quick run-through on linear and radial gradients. I did not have a sheet prepared for that, but I have prepared one here for your usage. Originally, I had prepared a sheet on importing Open Clip Art graphics, but as Eve and I were talking on the car ride into class we decided that it’d be better to go over gradients – getting the students working with Open Clip Art too early we feared might encourage them to lean too heavily on found art rather than hone their still-developing skills in creating their own artwork. I’ll use that material for the last day of class.

After the explanation on gradients, we encouraged the students to raise their hands as soon as they got stuck on something. By far, the most common issue that has gotten students stuck is the alpha setting in the fill dialog somehow getting turned all the way down, so when they start drawing with the calligraphy pen or shape tools, they can’t see their artwork at all. It’s the ‘alpha’ slider, not the ‘opacity’ slider (the latter they seem very comfortable with.) I’m pretty sure the stuck students were not setting the alpha in that dialog deliberately, so I am not sure how it keeps getting turned down.

Some other issues that came up:

• A couple of students over the course of the class have gotten ‘lost’ on the canvas. We’ve instructed them to hit ‘5′ on the keyboard to get brought ‘back to center’ to find their artwork again.
• A couple of students have gotten confused when a shape didn’t have nodes – I’ve had to remind them to convert the shape to a path first.
• One student today had a really nice illustration of a snake that she made with the calligraphy tool, but she did it in separate strokes and was not sure how to link them together. I showed her how to hold down Shift, select the pieces she wanted to unify, then go to Path > Union to make them one shape. It was a little hard for her to ‘collect all the pieces’ but once she got them all selected she was back on track.

I don’t think these are necessarily flaws in Inkscape, just humps that beginners to the program should learn how to resolve!

I forgot to take photos of the students’ work again – I will try harder for class 6 tomorrow!

Follow Along on Your Own

We have a lot of materials this week for folks following at home.

Here’s the lesson sheet we used for class on Thursday:

Introduction to Inkscape Lesson 5

Here’s the other materials we handed out:

T-Shirt Size Signup Sheet

Band Name Suggestions Sheet

Class Calendar with Deadlines

Here’s the sample design for the Inkscape T-shirt, both in SVG and the 300-dpi PNG Walter used to print the shirt out (the same shirt you see in this post’s photo!)

Sample T-Shirt Design SVG

Sample T-Shirt Design 300-DPI PNG

As always, the OpenOffice.org source files and the outlines for the entire course are at the course page on my website – but please note that’s a rough outline; as we progress through the class I’m coming up with the more-solid lesson plans based on how far the students get each session. By the end of the course I hope to have the course page organized much better.

By the way, if you’d like to follow all the blog posts about this class at one URL without getting the rest of my feed, I’ve set up a category in WordPress specifically for these posts:

http://mairin.wordpress.com/category/inkscape-class/

Enjoy! And please do let me know in the comments if you have any questions or suggestions

This course is sponsored by

Filed under: Inkscape Class

To make allusions to Douglas Adams' work when leaving a company, so I won't. I'm just going to post a couple of pictures I made with my n900...

This is the river Amstel, for which Amsterdam is known. As you can see, it's frozen over...

And this the Hyves office building, seen through the snow.

And these are Tommy and Markus, who together with Tjerk took me out for dinner in a steakhouse. Good food, good company!

I've been working for KO for two days now, after having taken a really nice one-day vacation which ended up with a visit to Ma Brown's Restaurant. That restaurant tends to be closed when Irina and I want to go there, but last Wednesday it was open at last. A warm fire, excellent food, good service... Perfect closing to a day of gadding about both Hollands. (Note to self: Sing Kee in The Hague isn't nearly as good as it used to be, bij Tholen in Haarlem has the best coffee I've had for ages.)

So, the third day, which happened to be a Saturday, I finished my todo list and then went out to buy a proper office chair, the kitchen chair I had been using at my desk up til now being rather bad for my back:

Now I need to find a replacement for the nine hours a week on the train, minimum, that was my designated Krita hacking time. And let's see whether the sculpture classes I can finally get to in time will actually go through. It's been more than 25 years since I last did anything like that...

Oh, and Hyves is still looking for good developers!

MyPaint developers released a much anticipated v0.8.0 on Friday, and one of them, Ilya Portnov, wrote a good introduction to MyPaint and a review of changes in this version. Read on! I can’t stop myself from quoting one of the users who commented on the Russian version of the review: “Yeah, great application! I’m painting again!!! [...]

Hi all

The SPH project from Stephen and me is reaching a new milestone:

I have finally fully implemented the particle surfacing core, it’s done ! , well , there’s a trick: it’s only the core

… and this is in lots of ways unoptimized : I’m researching optimized alternatives and also I will have to implement the complete OpenGL shading (normals,faces…) with the correct blending between different particle types.

Also I think a polygonal cache should be implemented like the current Elbeem simulator does for baking the simulation only once…

Because no matter how many optimizations are made,  for real life situations it will always be slow .

here are some updates , hope you like them.

<object data="http://www.vimeo.com/moogaloop.swf?clip_id=9091812&amp;server=www.vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=01AAEA" height="300" type="application/x-shockwave-flash" width="400"> <param name="quality" value="best"> <param name="allowfullscreen" value="true"> <param name="scale" value="showAll"> <param name="movie" value="http://www.vimeo.com/moogaloop.swf?clip_id=9091812&amp;server=www.vimeo.com&amp;fullscreen=1&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=01AAEA"> </object>

Graphics Planet got an upgrade this week. It now has a better theme, and uses new planet code, which will fix post title issues with blogs on wordpress.com.

A combinação entre o Maya e o Mental Ray é muito conhecida pela maioria dos artistas 3d, pois muito tempo antes do 3ds Max suportar o uso do Mental Ray para criar imagens realistas, os artistas do Maya já podiam fazer isso dessa incrível ferramenta. Mas, apesar de ser extremamente poderoso e flexível na geração [...]

Finally we got MyPaint 0.8.0 released. There were many persons involved coding, creating new brushes and translating. Thanks to everyone who has contributed!

My personal highlight are all the new brushes, nicely grouped and ready to be discovered. This happened even though the number of changes in the brush engine was near zero. Some brushes are even doing effects that I did not expect to be possible.

More on the GUI side, appart from brush grouping there now is a layer list and a new color selector. You can also select brushes by pointing at a previous stroke (press w), and there is a way to draw straight lines (hold shift). The user interface has been translated into 14 languages.

It is also noteworthy that the performance when zoomed out was improved, and of course there were many minor changes and bugfixes.

Personally I am excited about all the new contributions flowing in. But I hope I will also find time to work on the brush engine again. The GUI did require so much attention lately. Anyway, have fun with the new release!

The Stellarium team are delighted to announce the release of Stellarium 0.10.3.

cool
10-bit per channel powered by modern graphic chips. Given the last generations of chips with high bit depth frame buffers, dual link dvi and HDMI it seems not so astonishing. Anyway HP can be praised to have brought this to designers and graphics studios at a reasonable price. Congratulation. (Of course I hope this technology becomes pretty standard and will become even more affordable.) Would be interessting to know how Dreamworks deploys this under Linux - Ati : Nvidia?

To allow to look at the gamut mapping of a CIE*Lab to ISOcoated2 ICC profile in 3D without any CinePaint, here comes a 3D screenshot, available as a gzipped VRML file.

I find it always confusing to say CAIRO_FORMAT_ARGB32 and mean a 8-bit per channel thing. At a first glace I seriously expect it to be a IEEE float format, which it is not. Most users will expect to multiply by the channels count to get the pixel size not to divide the pixel size by the channel count.

If you consider, most of the imaging world has changed its pixel naming to a per channel base, it would be nice to see Cairo following this too. It is pretty common to say 16-bit image processing, which means per channel. Or 8-bit monitor displaying, which is again per channel. The monitor LUT's are sometimes 10/12 or even 14-bit, again per channel. The pixel numbers dont say anything about the colour resolution.

Why bit per channel instead of bit per pixel?
For instance a 16-bit Gray X-Ray image, properly displayed, can be superior compared to a 32-bit/pixel CMYK representation. In this case the numbers are non relevant to the lightness distinction. The example makes clear, what counts are the shades of gray.

Tricks like dithering dont count. Otherwise all people would still use indexed gif's for photos. But I dont know any camera or scanner doing so.

On the other side a 32 bit chunck with 3*10 bit RGB inside would be harder to describe. Is such thing still in use for hardware and must be supported? At least it is not present in cairo_format_t. Out of scope?

Possibly someone can point me to a document describing the necessity of Cairos per pixel naming as is. Is it something to do with tradition? Nethertheless the non selfexplanatory behaviour today makes it feel much like a pitfal.

To exemplify (a F stands for floating point):

colour    bit/channel    bit/pixel        cairo_format_t sheme
---------------------------------------------------------------
RGB                 8           24        CAIRO_FORMAT_RGB24
RGBA                8           32        CAIRO_FORMAT_ARGB32
Gray                8            8
GrayA               8           16
Alpha               8            8        CAIRO_FORMAT_A8
CMYKA               8           40
RGB                16           48        CAIRO_FORMAT_RGB48
RGBA               16           64        CAIRO_FORMAT_ARGB64
Gray               16           16
GrayA              16           32
CMYKA              16           80
RGB[A]... 16-bit float/channel use the same pixel size as the 16-bit per channel integers.
RGB      IEEE Half 16           48        CAIRO_FORMAT_RGB48F
RGBA     IEEE Half 16           64        CAIRO_FORMAT_ARGB64F
...
IEEE floats and 32-bit integers:
RGB          FLOAT 32           96        CAIRO_FORMAT_RGB96F
RGBA         FLOAT 32          128        CAIRO_FORMAT_ARGB128F
...
IEEE doubles:
RGB         DOUBLE 64          192        CAIRO_FORMAT_RGB192F
RGBA        DOUBLE 64          256        CAIRO_FORMAT_ARGB256F

The later can easily be confused with a 256 shades of Gray per channel naming.
Do you really expect a user to always divide the pixel values by the channels count to get an idea about the colour resolution?

To remember the marketing inflation of having 16 million colours and so on is long gone away. Today it is in, to say a software supports 16-bit, which is much more meaningful.
As a side step, manufacturers suggesting theire consumer camera to deliver the full range of 16-bit is still a joke. Such anouncements are demystified regularily.


Windows and osX have long inherited pixel naming conventions.
Cairo as a young project does not. Cairo could express pixels much closer to our current language in cairo_format_t.

Lets end here and come to a suggestion for a new sheme:

CAIRO_FORMAT_ARGB32 -> CAIRO_FORMAT_ARGB_8
CAIRO_FORMAT_RGB24  -> CAIRO_FORMAT_RGB_8
CAIRO_FORMAT_A8     -> CAIRO_FORMAT_A_8
CAIRO_FORMAT_A1     -> CAIRO_FORMAT_A_1

#define CAIRO_FORMAT_ARGB32 CAIRO_FORMAT_ARGB_8

could ashure compatibility.

Later Cairo could add

CAIRO_FORMAT_ARGB_16
CAIRO_FORMAT_RGB_16
CAIRO_FORMAT_RGB_HALF
CAIRO_FORMAT_RGB_FLOAT

... and so on.

After trashing code for a more generic colour rendering core, my gtk development tree is again up and ready.

As usual some colour improvements are included. This means Oyranos is spread more and more over the code. I slowly export CinePaint's colour management to Oyranos. So, CinePaint must at some point rely on it to build. Otherwise I have to provide the bits in two places. The Oyranos dependency will turn mandatory probably already in the 0.23 release.

As well, CinePaint should build by default as a Gtk2 app. Some distribution try to fake the old Gtk1 API by some none useable headers to finally link into Gtk2. As this is non sense for a advanced application like CinePaint, consequently many users experienced failing builds. The configure option --enable-gtk1 should turn the old build mode after the switch.

this text is solely about a idea for a project. The KDE4 site [1] has given their reasoning on why to reject Compiz. Expectedly Gnome will jump in similiar wording. I just want to raise one point about compositing effects/plug-ins. Plug-ins form a great users space to interact with ideas and code.

It is correct stated that Compiz exposes too much details about its internals into plug-ins. So its hard to reuse compiz plug-in code for say kwin.

Anyway the underlying logic is pretty simple.
Shaders are small text files. The desktop has a visible and virtual size, workspaces, monitor outputs, windows, subwindows, edges, a task bar, shortcuts, a property system (Xorg Xatom's) and some more. So from a logical point of view it could be possible to write one plug-in for serveral compositing engines.

What I, as a plug-in author, would find great is a project, which developes a common script language and implements native plug-ins for each of those window managers acting as a script host. Based on a simple and common logic script authors could write text only plug-ins. Obviously shaders are very likely to be part of such a system or possibly OpenCL if mature enough.

I know coming with code or a detailed proposal is nicer. But if someone searches for a nice Summer of Code project, that might become one.

[1] http://techbase.kde.org/Projects/KWin/4.0-release-notes

After the successful Google Summer of Code project of Tomas Carnecky at OpenICC we have now a nice spec for late colour binding on the desktop - read server side monitor corrections. The spec is in the doc directory of Tomas' git repository.

Tomas tould us that the propriarity nvidia linux driver has probably a bug preventing me from successfully running his work on a dual monitor system. Fortunedly he was not right at this and I was able to model after his initial work a second compiz plug-in for dual monitor colour correction of the complete desktop. Its at the moment called colour_desktop.

The snapshot below shows the plug-in with two false colour profiles. The left side monitor has a linear sRGB profile assigned and the right monitor profile has all primaries swapped:

The colour correction workload is for a unused desktop nearly zero and for a running movie slightly noticeable. Of course this server side colour management breaks all older colour managed applciations as there will a double colour correction happen, the early colour binding in the application and the late colour binding in the compiz plug-in. The spec of Tomas holds the solution inside with a atom describing colour region on the server. My colour_desktop compiz plug-in respects these regions and a small example application does both early and late colour binding in one window. The whole stuff is in Oyranos git and it will take a while until we can really distribute stuff like this. First applications should have some time to update to the new window atom under Linux. And second many API's under Oyranos need more refinement.

The following link brings your to a more technical post.

This years Libre Graphics Meeting will happen to be in Montreal from 6 to 9 may 2009. LGM is a major community organised event to bring open source graphic programmers and users together. On the last years meeting, I could meet many persons en face for the first time and discuss one of OpenICC's Google Summer of Code projects. It was a great bazaar of exchanging ideas in a friendly atmosphere and I expect it to be a very helpful event this year too.

For giving you a chance to help in the success of the event, you can donate to cover part of the cost for the attending developers:

after Hal V. Engel suggested the nouveau driver because of its good XRandR-1.2 support, I installed the driver from the X11:Driver:Video repository. With that alone Oyranos has now a basic XRandR support.
Today I wanted to use the current development version of Nouveau and build on my local openSUSE-11.1 installation. It worked not very well. So here comes some suggestions on which packages are needed to sucessfully build the driver. RPM's which should be present are kernel-source, which is huge, xorg-x11-server-sdk and the various xorg-x11-*-devel packages. With them installed the instructions of the Nouveau developers can be followed: InstallNouveau.
After uninstalling all of the nouveau distribution binaries and drm kernel modules X started successful.

Release v0.1.9 is out and in a improoved shape. The packages have fewer licensing dependencies. The package is tested by the newly added check target on various hardware platforms and OS'es.
What is now missed are more maintainers for distributions. So far exist a Fedora package. Hub emailed, he would look into OpenSUSE, which is great. From the bigger players is missed a Debian/Ubuntu and a Mandriva maintainer.
Interessted people can contact me <ku dot b at gmx dot de>.

was a great opportunity to meet colour people in person. Many thanks to ICC for opening the door to speek at the conference about Linux. It was a fairly small talk compared to what others provided. But it was as well for many the first introduction about the possibility to do colour management on Linux at all. So first of all I gave a introduction about licensing and commercials, as this is most often confused by IT managers.

It was very nice to meet Max Derhak, who implemented the mpet tag and developed on the multiProcessElementsType for better support of floating point processing inside ICC profiles. The tag was developed to better support colour conversions for the motion pictures industry. Great to see that there is communication possible to that extent. We looked over the license issue of SampleICC and figured out how to best solve that. He has interessting things on the plan together with ICC.

Meeting people on the streets of Portland, and I do not think this is specific to this city, had a flair like wild west. Many pedestrians where distant at more than a arm's lenght and keept a cautious tone at a first glance. The border between civilised politeness and the feeling of attention in face of a tiger was very fuzzy. Instinctively I had to think about the citicens right in the US to own gun wappons. On the other hand I saw many signs of openness as I found in Europe, if I may compare, mostly in Amsterdam. So I found a nice place of showing quite some tensions.

was a impressive tradeshow, with lots of people from the printing industry. Showing machines is one part. One can get a good idea of what is actual in printing effects, costs and handling, at least if some experience already exists. What wondered me was, that at such a show, where much money is put into booths, still occure obvious lapse with very simple things.
So at the Epson booth, which was fairly large, opalescence or broncing in the proofs was rather the standard, even for the Oris RIP. I had expected they sorted such things out and present the optimum of the K3 devices. But possibly the connection of selling machinery and software in one part is more of an objective in a customer relation. So customers see what they get after buying. This helps decreasing support requests, while increasing satisfaction.
Minolta showed a very nice, and large, laser copier/printer. The colours seemed constant, which is a major concern in using this technology for proofs. Just the selected image was squeezed through a assumedly 8 bit rendering path or a terrible profile. One could easily see in the presented gradients. It's hard to recommend such a expensive device, if one does not know how it can be done better from the software side.

What was really missed was a open source booth. ArgyllCMS/LProf could be shown for calibration and profiling. There is Ghostscript for rendering PDF's, CUPS for spooling, littleCMS for colour conversions and Gutenprint for driving ink jets. I would offer to demonstrate live my CinePaint proofing tutorial. This would be the right audience.
To center around Linux/BSD seems not that much of a break there, with some companies running Linux since years as servers for their workflows. At least Samba would be a good add to the open source list above.
Well, whether it is possible to sort out broncing and provide a better rendering path with pure open source components, would be a good toppic at the open source booth.

While looking over the new czech translations for CinePaint and ICC Examin from Milan Knizek, I stumbled over "fotometricky" inside all intents. Looking at the origins I found to have written photometric and colourimetric into the sources. Thats clearly ambiguous. But why did I come up with photometric at all?
Graeme Gill points out that a ICC style Rendering intent is a couple of dedication or usage of image content and gamut mapping. I am in doubt that this coupling will remain as is. And frankly Graeme has its part in my mindset regarding smart CMMs. Still no solution for my intent naming. Should I call the first ICC rendering intent as officially called "perceptual" and wait until the paradigm changes? Or call it "photographic" or "pleasing"?
It seems best to switch back to the ICC standard until a proper convention can be agreed to.

Probably the confusion comes from german "fotografisch" translated "photographical", which appears in the sources as well.

was for me a really impressive meeting. Really good was the talking on the OpenICC BoF and with other project workers face to face to more easily get a impression about, what are requirements and objections.

We met Carl Worth, and he and Behdad Esfahbod took the time to conceptually let coincide the colour and Cairo internals.

One interessting talk was given about spectral imaging in Krita. Really nice topic shared with the audience by Emanuele Tamponi.
Most talks are covered here.

Kamila Giedroj , Dave Neary, Louis Dejardins and all the other organisers made good preparations. It was a pleasure to attent. Thanks.

The LGM happens to take place 8th to 11th may at the Wroclaw University of Technology. I am quite curious about the city and the people to meet there, most the first time in person. Even though we had sometimes contact some years before.
There are primarily three themes for me,

• be present in a talk about the goals of OpenICC
• give a talk about the Oyranos colour management system
• discuss a, to be prepared, CM strategy for Cairo

Of course other topics like tonemapping, a cross toolkit plug-in GUI API will be interessting to elaborate there as well. Talks in preparation for the Summer of Code projects like Colour Management near X are also promising to become interessting. Lets see what else.

For giving you a chance to help in the success of the event, you can donate to cover part of the cost for the attending developers.
A sponsor contact page is here.

is a small code example for how to do animation in Cairo. Click on the below image to download a 5MB mpeg preview.

The red arc has a mouse over effect and the right below spline with the red line is interactive.

OpenICC is a Freedesktop project that brings together just about everyone who is interested in color for free software applications. That's: ArgyllCMS, CinePaint, Cups, GraphicsMagick, Gimp, Gutenprint, ImageMagick, Inkscape, Krita, karbon, LittleCMS, LPROF, Scribus and Oyranos. And, of course, what's happening here has influence on the the Linux desktops.

This year OpenICC has been selected again as one of the projects that can participate in the Google Summer of Code!

Hot topics for this year are the integration of a colour management system into low level services, like Xorg and Cairo, HDR colour management, hardware accelerated colour conversions, true multiple monitor support, again Tonemapping and a toolkit independent GUI layer for plug-ins and CMM's. Of course we are happy about continuing and improving our existing applications, libraries and all being mentored by experienced developers.

The project ideas range from very simple "get familiar with open source" style projects to advanced topics. Given they are all cross platform, they have potential to influence colour management not only on Linux. With students entering this round we hope to get closer to a colour managed desktop with fun.

I wonder why real absolute rendering, not to confuse with the ICC absolute rendering intent, is so often rejected in the thinking of many colour people. It is quite correct to point to viewing conditions. But arent these secondary? The first place are absolute ligthness and colour values, which can later be reinterpreted. If this relation to the physical capturing gets lost, the data is flatten out; much like a one shot flash light foto only covers a two dimensional representation of the three and four dimensional world. Introducing time and changing the point of view makes a real difference. I think the same applies to colour.
Sorry for me being a bit polemic, but I cant understand that information stripping, or better omiting, is the only valid way to create good photos.

Ok there are different paths open and the current one is shurely selected with reasoning by the ICC. Nethertheless people who like to ask questions to colour management systems run often in a difficulty to find inherent answeres. This can be seen as a flaw as it deprives cognition.
A simple example is: "I have calibrated my monitor, but when I measure Lab values from a colour patch on screen, they are not the same as the program says. Even though the measuring device is the same as for creating the profile."

ICC Examin v0.45_rc8, a release candidate, seems to work on 10.5.x series of Apples OS X. Eric Robinson provided to log file. Many thanks.

Reportedly does ICC Examin v0.45_rc7, a release candidate, fail on the 10.5.x series of Apples OS X. This is a call to help in debugging this issue. What I need is a log showing the crash details. The Programms/Utilities/Console application can guide in finding such a log. My hope is to get an idea of the reasons and bring ICC Examin to the same state like shown in the above screenshot on osX Tiger.

The general idea is simple. To reach a consitent colour management are parties must play better well together. Agreement to similiar dialogs is one part. To aid the layout Oyranos provides not only settings but as well a concept on how to display them in a interface. A html page comes to mind, but Oyranos is more abstract and not that formal.
The widget requirements are easy:
choice, slider, button (with image), button styles (check, radio), text
groups:
frame, tab or choice or tree ..., layout widget array groups with orientation

Oyranos continues with the concept to require a implementation of a native widget set according to the above mentioned Oyranos abstract widget set and some abstract layout requirements to render the Oyranos settings.

The current widget set covers only choices, profile selections and a groups for pages implemented as tab in oyranos-config-fltk.

These dialogs will be easily rendered in control panels of KDE, Gnome and other places with the above mentioned according implementation.

The below screenshot of ICC Examin working as CinePaint plug-in showes the mapping of a CIE*Lab colour grid to ECI-RGBv2 or LStar-RGB:

The snapshot was created by assigning a Lab profile to Bruce Lindbloom's RGB16Million.tif . For better handling I scaled the Lab16million.tif to a handy size. Then the samples where viewed in CinePaint's ICC Examin plug-in. After that I had let CinePaint convert the Lab values to Rgb and ICC Examin showed the colour movement, appearent here as coloured lines. The small squares show the final Rgb postions. The projection is a 3D view into the CIE*Lab colour space from the CIE*b+ direction. The upper samples point to CIE*L 100 the lower to CIE*L 0.

Interessting is the front plane (+CIE*b) with the mapping of green, yellow and some oranges. They work in a almost lightness (CIE*L) preserving way. The left side (+CIE*a) reds, magentas and blues show a strong lightness modification. The snapshot helps me in improving my gamut creation algorithm in ICC Examin.

asked me some questions to publish on his blog. As I know him from discussions and like his gallery, I agreed and sent him my answeres:

Hello Kai-Uwe

As one of the lead developers of Cinepaint and a very active contributor in Color Management (CM) on Linux, you are a key-person when it comes to using Linux for photography. Thank you very much for taking the time to share your thoughts with us and help us understand better what is going on in the Color Management field on Linux.

Read the whole interview on Joels blog...

CMake is wrong in claiming it generates unix makefiles. It generates lots of dependend files, which must be read to understand the whole process. Nothing selfcontained. All is spread over many files and various dependencies. Cmake feels much like a PHP hack. If CMake could render it true to generate native build files, I mean selfcontained unix Makefiles and projects files for other build environments, CMake would be a great tool and probably help reducing complexity. Currently it is more close to autotools laboriousness.

Changing the paradigm from automated configure scripts to a full interactive only configuration process moves the new build environment clearly to Windows. In the same way CMake looses a clear Unix feeling.

To make it clear, I dont like to use libtool with its timeconsuming complexity. But what makes Cmake substancially better? As I often try to compile many different projects, my benchmark is, how quickly can I overcome a unexpected problem during the build process?

The following questions arise quickly [with CMake answeres]:
Do I need to learn a new syntax? [yes]
Are all tools and dependencies in one place, making needed adaptions easy and straight forward? [no]
Does I get a project relevant help message by default to change options or set variables? [no]
Can I easily trace wrong parameters to its source, without the need to go through various files and possible learn theire syntax? [no]
Can I use the tool in existing automated envioronments? [not obvious]

If you search for a elegant and simple buildenvironment, chances are high you dont find it with a current version of this tool.

with the various discussions around a single colour format seems now some movement on the Create email list. Among various alternatives the creation of a new format was most popular one. There seems simply nothing what counts and is extensible while being useful with standard tools. So Cyrille Berger is about writing a format draft to later adapt colour palettes, spot colours and so on to the new format. The format will allow ICC profile referencing and seems useful for many areas in colour data exchanging.

One candidate, a format from Xrite, developed by GretagMacbeth, called CxF was not been available since times. There exist a whitepaper, which no one in the open source community likes to implement, because of its unclear status.

Of course Oyranos needs a on disk format, and ideally one, which will be open for future new areas.

Carl Cole works on a patch to sensibly apply clipping to out of range pixels. The clipping is implemented for the curves and levels tools. In the screencast below you can see how the new clipping works in levels.
CinePaint colour clipping video
And here as screenshot, old wild hue moving towards the three secondary colours:


... and the new levels behaviour preserving hue:


I am pretty shure this behaviour will become quickly standard for open source applications as it is a big quality improvement.

The new Oyranos continues to evolves to a CMM framework. But where to store?

The already mentioned OpenICC directory proposal handles text and binary data, but no active parts. I am now thinking about a good way for making plug-ins and extensions possible. The idea is to define standard API's which can later be implemented by various CMM's. As most binaries are highly architecture dependend theire place must reflect this appropriately. Continuing the current sheme we would get the /usr/lib/color/ + /usr/local/lib/color/ + .local/lib/color/ paths. For the later we had to skip the XDG_DATA_HOME variable as it points to HOME/.local/share, which is not good for our need. After defining the base paths we can append a cmm/ to make the use of the content obvious.

Oh, binaries are not covered by the XDG spec. What now?
A OPENICC_PATH variable with the above paths? Who will set this?

with Oyranos being alpha and still no one using its API's, excepts of projects which I maintain myself, I'd think it is appropriate to come with havy weigth changes to the API's. Still it will remain C, but with more of a object style programming. The simple C calls to modify Oyranos internals are changing to calls for manipulating structs. I hope the changes will be more local and thus more patterns can evolve from using Oyranos.
If you still want the old API's for some reason let me know.

Currently we have two proposals on OpenICC in discussion, which will affect colour managed desktop applications. The first is the ICC Profile in X proposal. Jon A. Cruz brought up the discussion again. I took the chance and wrote a draft version for ICC Profiles in X Specification 0.3. We had discussed several ambiguities and I hope 0.3 will be much clearer.

The other text is the OpenICC directory proposal. It covers the location of colour profiles and configuration data. But it needs more work to become clearer.

Implementations for the first exist in XICC, Oyranos and I think a couple of applications can read the profile out. The paths proposal is in its previous form widespread. But the new paths draft is far away from that.

as is the various properties of options are handled by internal lists. This is fine as long as the complexity is very small. Just many planed features become complex and would need to hold internal data structs in a single list. So my plan is to drop the single property lists to obtain options values and GUI names. The replacement will be build around a single struct and a according extensible API to handle these structs.

The colour management control panel must later be adapted to the new API. But I expect the sources will become more logical. Hope there is nothing else affected and can be set in stone for a stable version 1.0 of Oyranos.

after digging into the named colour API things tend to fall to bottom. A Oyranos Named Colour should be convertible to various colour spaces. So generalised colour conversions are needed.

One way would be to stick to an available CMM like lcms or argyll. The rumors about a CMM API did not turn into a visible reality. Then we could think about how to switch for HDR data to a different CMM.

By the way, a HDR CMM, which will use hard coded colour transformations, will have a hard time due to the complexity. See some thoughts about such approaches here.
Everything except floats can be very comfortable and relyable done by the available CMM's. This is the only decission needed at the moment and should be traceable by the CMM's capabilities registration.
When lcms can handle uint8_t and uint16_t and an other registred CMM IEEE floats, then the later will be used as a fallback for all pure floating point transformations. The prefered way would be a generic CMM like lcms supporting floating point precission.

Then Oyranos must know about profiles and load them. Of course short hands should not be missed. A profile API, loading, on the fly creation, default profile selection, is needed.

The next is a colour conversion context. It will contain a image description. Fortunedly some thoughts where invested in this already a while ago.

Something else?

Oh, yes byteswapping and ICC tag for GUI's interpretation, at least to some extent.

When it is done, ICC Examin has a some more of its capabilities moved to Oyranos with the benefit of being more modular. I hope this helps reducing some the complexity in this application.

The bad news, Oyranos will delay further and probably miss some other wanted features, like the settings virtualisation.

API in ICC Examin is evolving. To make colours selectable from lists, as often embedded in colourimetric data, I decided to prototype an API for named colour exchange. As such a API stands since a long time on the Oyranos TODO list, it shall later be exposed in the Oyranos colour management library.
There it can be used to select colours and get arbitray conversions from it. For instance it will be highly downward compatible with traditional sRGB workflows. The library shall create sRGB values on the fly from different input, such as Lab or Cmyk.
Things like exposing settings as gamut warnings, HDR information and swatch handling must be added.

Here is a screenshot of the upcoming version 0.45 of ICC Examin:


As soon as a file format for colour swatches is defined, it shall be used for storing named colours on disk.

After fiddeling around with all those libraries to bring into the fat mach-o form for ppc and intel machines, I could now build ICC Examin. The package is available as a release candidate for osX.
The osX disk image, containing a universal binary and compressed with gzip (dmg.gz), can be found here:
ICC_Examin-0.43_rc8_U.dmg.gz on SF

Let me know especially whether it works on the mac intel architecture.
To leave a comment, for readers of graphisplanet and similiar, go to the:
comment page on Kai-Uwe's wind blog.

It is often discussed, whether Cmyk or Rgb printing results in better quality, or whether one should buy a Rgb or Cmyk device. I will try to shed some light on this theme.

Normally print devices use Cmyk inks. These are cyan, magenta, yellow and black (k). Some come with additional inks for light cyan, light magenta, (light) gray, red and blue to extend the device gamut and improve smoothness. Or they use special finishes for a better appearance of the print. These devices are far away from being Rgb print devices. The somewhat fuzzy term Rgb printer comes almost from the Windows world, where pictures are sent as Rgb colours to print devices. This is a software or driver aspect. The concept, followed on windows, is to make virtually every colour device a (s)RGB device, and thus simplify software and user interaction. This concept has advantages and disadvantages. See further at wikipedia.

To achieve good results, depending on what quality you like to obtain, the colour conversion should occure with colour profiles according to the desired quality and designed for the combination of your device and the ink/media/software/driver you plan to use. Most colour profiles are stored in the ICC format. But there exist as well internal colour transformations in some drivers or propriarity formats. For instance Gutenprint utilises internal lookup tables and algorithms for converting incoming Rgb to printer side Cmyk colours.
As Cmyk is often almost the native colour space of your printing device, this colour space is often used in professional grade RIP's to better deploy the gamut of a printer.

An other aspect is the look of your print. This includes saturation enhancements or a special tint of the sky, skin tones and so on. It is the aspect of taste in this art, varying with the region and the group of persons.

For CinePaint, the image separated into Cmyk colours, will transport the high bit depth colour information in a most straight forward manner to the Gutenprint print driver. Thus Gutenprint has just to dither with few further colour conversions, resulting in less banding and finer gradients for sky, foggy motives and the finishes on glass and car surfaces. Of course you have the option to use the Gutenprint internal conversion routines and supply Rgb, thus by-passing the ICC conversion. You can read more about printing in CinePaint in my CinePaint - 16-bit Imaging tutorial.

Huhh, compiling all of my toolchain for running ICC Examin on osX PPC/Intel machines. It is not that much fun.
Some libraries are not prepared to handle this case. For the iconv/intl libs I had to remove all obscure -no-undefined statements in Makefile.in. It seems to be in place for BeOS. What do I care, as I dont intent to release those libraries as sources.
Instead -flat-namespace -undefined suppress options helped to get the stuff comiling.
I had to modify ICC Examin to support --disable-dependency-tracking configure option. gcc -M options are not allowed with multiple arch targets in fat files.
As usual, I dont rely what others compile for lcms, tiff and the like. Too often is my HDR stuff brocken. Now these are following as well, but starts more simple. .. OpenEXR compiled fine.

Apple documentation: http://developer.apple.com/technotes/tn2005/tn2137.html

As I released today the 0.22-1 bugfix version, the changes mentioned earlier on this site must be delayed. Lets see as well, if I can get the Python plug-in working to make it a useful distribution part.

and Nathan could not resist to include UFraw allready. Funny. Hope many users enjoy like him: in his news.

Now that the release of CinePaint is out, some things come clearer or simply more evident for handling colour management with Oyranos.

Gray default profile
One thing is the a missing default profile for gray images. I am now adding this to Oyranos. Without it would be incomplete.

Maximum conformity
The other thing is the missing policy display. If I remember correctly something like a first warn message should be implemented. But it seems difficult for a user to understand such messages the first time. Let me explain a bit more. Once Oyranos is installed and CinePaint runs all comes smoothly. A PNG is opened and and gets a default profile assigned. As the Home+Office policy is the first active one. It will be sRGB for untagged data. Fine. The user tweaks that and saves. Now a tiff comes its way and opens nicely, editing, saving. No problem. After sending to a agency they phone and say it was degraded from their accepted WhateverRGB to sRGB. Now what? No message appeared. Repeating the same in CinePaint and looking now carefully on the windows top border, one can observe that there is sRGB right from the beginning.
Thats not possible. CinePaint degrades an image and this silently. Where is the professionalism?
You can imagine, this will provoke many colour people.
Indeed Oyranos first hand policy is a keep it simple policy. Convert all to sRGB and make all the same right from the beginning. The intention is to help that many users without colour ambitions to work without the need to understand colour management. Once a image is loaded in a Oyranos compliant application, every other applicatin should handle colours fine. This is a maximum of compatibility.
For colour people it is simple to change this. In Oyranos' control panel, called by oyranos-config-fltk, one has simply to switch from Home+Office to say Photographer. It is in the first tab. Now your image data are handled much more carefully. No colour space degradiation to sRGB, and a bigger default editing colour space is now active.

The dilema is about making it really good for both unexperienced and high level users. Policies can help to satisfy many different groups. And in the future one can simply create its own policy. But a application author is under pressure to provide success right from the beginning.

The question which arises is, how should a default for a fresh installation be formed? What is acceptable for all as a first start?

This print plug-in in CinePaint's interfacing with Gutenprint is available since quite a time. The blackpreservation option can be found in the first print dialog in the lower part. It affects only CMYK-CMYK conversation. Below is a colour conversion from a ISOcoated to a desktop inkjet with very different gamut shown. The inkjet's black has a brownish shade. The screenshot shows the visual output on screen:
It is not perfect, but gives you an idea what is available now. The on the fly creation of the device link happens in the background within littleCMS (or lcms), CinePaints internal used colour management modul.

of the brush strokes seems limited. The blue may camouflage. Anyway for a non vector drawing it is ok. Now scaling works correct:

This years the fair in my hometown was a nice experience. 40 people, all beginners, where listening to my, in their eyes somewhat exotic, colour management and CinePaint explanations. They where probably attracted by the title. I must admit, my intention was to have a discussion with specialists, but these people seems not to come regulary to Chemnitz. But with a small change I hope the audience could take a good impression home.
Beforehand I tried to bring the CinePaint release out, but found some no go issues. Now, with the nice feedback from the fair, I started to solve a long outstanding thing - the precission in the drawing core. The inherited code does nice things, but is, well, a not finished kernel. What I want is a polished look of brush strokes. Things which dont belong to a stroke must go away. What I found is − the CinePaint engine lacks precision in drawing positioning. Some code snippets to overcome the resulting effects are found but where never finished. I looked at the continued projects and thought, it would be best to stay within the CinePaint code complexity and not switch to the complexity of an other application. The results can been seen below.
Drawing quality before (left) and after the changes (right):
There should be still more done to better work out of the box. As well these changes made some other things obvious − see the stripes in the blue stroke. As well the brush scaling code is now insufficient. Hmm ... an other delay in the release. Btw. as you might have noticed the tablet issue for Gtk2 is fixed.

A modelagem 3d no SketchUp é direcionada na maioria das vezes para projetos de visualização arquitetônica, mas o escopo dos seus projetos pode envolver qualquer área. Quando comparamos as ferramentas de modelagem do SketchUp com as de um software de CAD como o AutoCAD, algumas ferramentas básicas de composição de objetos fazem falta como a [...]

Let`s take a small break on the GPU rendering articles and go to another trend, this time is about internet. We have a bunch of applications been released this days with online versions like office suites and even illustration tools like the amazing Sumo Paint. A few weeks ago I have showed a project from [...] Related posts:

1. Free courseware on technical drawing with AutoCAD I just found out about another great free resource to...
2. Project Cooper: Blending AutoCAD and SketchUp for architectural 2d drawing For architectural projects that must be presented as 2d drawings,...
3. DoubleCAD XT: Free alternative to AutoCAD This article is not directly related to Blender, but since...

Peter Rukavina on the iPad :

The power of the net for me has always rested in its utility as a vehicle for freely producing, sharing, mashing-up and distributing stuff, not in its utility for allowing me to watch re-runs of LOST more easily.

I agree completely.

Also, see Andrew Leonard on the iPad for Salon.com:

Apple’s deal has always been that in return for giving up some freedom, the company will provide a fabulous user experience.

I’m loathe to comment on a device I’ve yet to try, but based on my experience with a (now bricked) iPod Touch, I can imagine this being a great device. I just can’t get excited about a device that keeps the control over what you can do with it in the hands of a private company.

One positive aspect is that it does focus around a web experience, and the web itself remains open.

A revista gratuito sobre computação gráfica 3d, animação e cinema chamada de RenderOut! está com mais um número disponível para download. A edição de número 13 mostra a mesma qualidade de conteúdo e um especial sobre o fenômeno Avatar. Esse é um capítulo a parte e ainda deve merecer um artigo próprio aqui no blog, [...]

I've written in the past about Python GUI programming using the GTK and Tk toolkits, and several KDE fans felt that I was slighting the much nicer looking Qt.

So my latest article on Linux Planet, Make Pretty GUI Apps Fast with Python-Qt, shows how to develop a little poker game using the python-qt toolkit.

I didn't want to dwell on it in the article (and didn't have space anyway), but pyqt turned out to be a bit of a pain. There's no official documentation -- or at least nothing that's obviously official -- and a lot of the examples on google are out of date because of API changes. None of the tutorial examples explain much, and they never demonstrate the practical features I'd want to do in a real app. It was surprisingly hard to come up with an application idea that worked well, looked good and was still easy to explain.

And don't get me started on this whole "Slots and signals are revolutionarily different even though they look just like the callbacks every other toolkit has used for the last three decades" meme. I'm sure there is a subtle technical difference -- but if there's a difference that matters to the average UI programmer, their documentation sure doesn't make it clear.

All that aside, PyQt (and Qt in general) does produce very pretty apps and is worth trying for that reason.

The suit images in the article are adapted from some suits I found on Wikimedia Commons (the "Naipe" set). I wanted them to look more 3-dimensional, so I applied my blobipy GIMP script as well as scaling and resizing them. I really liked those shiny-looking Tango heart and spade emblems (also on the Wikimedia Commons page) but I couldn't find a diamond or club to match.

The poker program I wrote has menus and a second round of dealing, where you can mark off the cards you want to keep. I couldn't fit all that in a 700-word article, but the complete program is available here: qpoker.py or you can get it in a tarball along with the suit images at qpoker.tar.gz.

Ooh, the strain.

Hi

I want to share this, when I read it I feel really sad:

The biggest OpenSource host site SourceForge has pledged to the EEUU decistion to forbid users from Cuba,Iran,North Korea,Siria and Sudan to access their content….

and this is true: I can no longer download a single byte from them  This is a sad day for the Open Source ideal where everyone should have access to the information without political

restrictions or governmental selfish interests …. for those who have hopes in Obama’s flexibilization with Cuba I have to tell you that isn’t going to happen, period.

Blockades are not a solution against governments, the only ones that suffer are the powerless people, this approach should be forbidden like Atomic bombs are , because they have a similar effect if not worse

I don’t want to talk of political issues in this blog but when you were born in a cruelty blockaded small country without hopes, news like this simply make you think that you really can’t take more

forgive my rant , Farsthary

Hi all

Last night I finished the implementation of surface refinement for particles, this allows to increase the resolution of the mesh for smoother surfaces. I still need to redefine my current surface evaluation from particles because I’m getting the wrong isosurfaces but still I could show you my progress.
This will be useful not only for particle fluids but also for the whole particle system (Newtonian,Boids,Keyed), that’s why we plan to release first the fluid particles engine independently from the surface generator very soon

here´s some screenshots:

In the past few days a lot of interesting news and demos about GPU rendering appear o twitter and user forums. It`s quite clear that after the announcement of Octane Render and Arion, we will start to see even more releases related with GPU render. I will start with the announcement of a GPU render [...] Related posts:

1. LuxRender may use GPU power in the future Since the announcement of Octane Render last monday a lot...
2. Arion: Another GPU based unbiased render engine A couple days ago I was talking about the announcement...
3. iray Demo: Realtime rendering for architectural with Mental Ray From all predictions about the future of architectural visualization, one...

O uso de interações simples em softwares de computação gráfica com base nos movimentos do mouse como o clássico clicar e arrastar. Esse é um tipo de comportamento que vejo com muita frequencia em artistas que migram do 3ds Max para o Blender 3D, pois no 3ds Max é possível usar essa ação de clicar [...]

It’s easy to romanticize the medium of our youth. I’m too young to miss vinyl; for me vinyl means Nana Mouskouri’s Christmas album. No one really misses cassettes; except maybe for mix tapes, which we mostly loved because of how much work we put into them. CDs are also hard to lament. They were never very portable; it seemed to take 10 years to develop a portable CD player that didn’t skip. Mostly, though, they were digital. There is really no difference between CD audio and a similarly configured audio file on any other digital medium.

When technology advances, we often realize that we miss the things that were flaws in the previous generation of devices. We miss the warm crackle of vinyl. We miss the sense of accomplishment from hours spent painstakingly crafting the perfect mix tape.

Now that we are awash in the glut of availability of digital music, I’ve come to realize that I’m missing one of those flaws. When I could only afford to buy one CD, I was stuck with it. I would listen to it until I knew every word and every chord.

Now that I have so much music at my disposal, even when I do find music I enjoy, it’s often enjoyed on “Random” or while I work, where my attention is spread far too thin. As a result, I seldom get to the level of familiarity with an album that I did ten years ago. I might get there with a single song, but seldom an entire album.

I do not assume that listening to the same album until it’s burned into your head is inherently better than a more cursory listen to a broader selection. However, familiarity is one of the fundamental elements that makes music something more than just sound. Our brains are good at spotting patterns, and we like completing patterns. Great artists use familiarity as one of their instruments to hack the brain into thinking notes, chords, and rhythms are playful, unexpected, or satisfying.

The deeper you know a piece of music, the greater the opportunity to enjoy it. Each note means something different when you know its coming.

So, I’m trying to artificially re-create a limitation that caused me to get to know a limited number of albums deeply. The limitations used to be accessibility and (mostly) cost. This year, I’m creating my own limitation. Each month, I’m choosing one album to focus on. It won’t be the only thing I listen to, but it will be the first thing I go to each time I start up some music. I’ll also listen to the entire album, in order, each time I’m looking to listen to a long stretch of music.

I’m curious to see if there is any more joy to be squeezed out of music by concentrating on a small set of albums this way.

Last year, without any such regime, I did end up enjoying a few albums this at this level: Fantasies by Metric, Far by Regina Spektor, Welcome to the Night Sky by Wintersleep, Three by Joel Plaskett, Into Your Lungs by Hey Rosetta!, Read Less Minds by Mardeen, and a few others.

The albums I’ll choose for each month won’t be the best albums of the year (many I might not have heard at all before I choose them, as was the case when buying albums 10 years ago). For January, I have chosen the album Nice, Nice, Very Nice by Dan Mangan.

It’s a good way to start the experiment. It’s a good album, but not something I would count among my all time favourites. If it had been one of a dozen albums I was listening to, I would never have gotten as much enjoyment out of this album as I have in the past few weeks.

I have eleven more albums to go this year. I will certainly include the upcoming release from Wintersleep. Suggestions for other albums are welcome.

A onda de lançamentos s softwares usando técnicas como o Path Tracing e as GPUs para criar renderização em tempo real parece que não deve parar! Essa semana tomei conhecimento de mais um software especializado nessa tarefa para o Maya, chamado de FurryBall que funciona usando o mesmo princípio do VRay RT dentro do 3ds [...]

Hi all
I’m progressing a lot in the surfacing , I have implemented a spatial hash structure for boundless marching cubes acceleration that is working ok

For the isosurface evaluation I still have to investigate a few more approaches since I’m getting only surface slides of the fluid stream currently.

Currently I have a lack of updates in my site because the college net is nearly collapsing due to the VILSEL and several viruses of the same family that keep the network saturated
KAV and NOD made very little for it, any effective solution ?

Cheers Raul

League Gothic is a sans-serif Gothic typeface, originally designed by American typeface designer Morris Fuller Benton in 1903. The League of Moveable Type has made this typeface available as a font under the the Open Font License as it was designed pre-Steamboat Willie and is under the public domain. Morris Fuller Benton designed over fifty typefaces, including well-known (to designers at least) ones such as Franklin Gothic, ATF Bodoni, Century Schoolbook, News Gothic, and Parisian.

How can you use League Gothic? It’s a very bold and strong font, easily readable from far away. Actually, it reminds me a lot of the Marvel Comics logo, so naturally I used it to create a tightly-spaced Batman (DC Comics) related type specimen. In all caps, the font has a very tall feeling because the legs of the letters are very tall – the x-height seems to be much taller in proportion to the full letter height than in other typefaces. The League of Moveable Type page for League Gothic has a nice type specimen for the font – it’s a clear and readable typeface for info graphics, but also could make for a nice, epic-feeling logo.

League Gothic has coverage of some accented characters in Latin Supplemental, but Latin Extended A and B are not covered:

League Gothic is licensed under the Open Font License.

• Fedora Font Wishlist Entry:http://fedoraproject.org/wiki/TLOMT_League_Gothic_fonts
• Upstream Homepage: http://www.theleagueofmoveabletype.com/fonts/7-league-gothic

So, you want to package League Gothic?

Way to go – you’re rad! You’ll want to follow the first steps here next to the ‘if you intend to do some packaging’ header:

• https://fedoraproject.org/wiki/Joining_the_Fonts_SIG

Our fonts packaging policy, which the above refers to, is documented here:

• https://fedoraproject.org/wiki/Category:Fonts_packaging

And if you have any questions throughout the process, don’t hesitate to ask on the Fedora Fonts SIG mailing list:

• https://admin.fedoraproject.org/mailman/listinfo/fonts.

Last Week’s Font

Last week’s font was Tuffy Infants 2 by Thatcher Ulrich. Nobody has picked up the font package request yet! Would you like to?

Posted in Unpackaged Font of the Week

A migração de diversos serviços e softwares para plataformas baseadas em internet é uma tendência sem volta para a maioria dos softwares, e isso não é diferente com ferramentas especializadas em computação gráfica. Já mostrei diversos softwares aqui no blog que tiveram sistemas portados para plataformas web, sendo que muitos desses projetos são patrocinados pela [...]

I’m actually so confident I’ll be home on WebOS that I already sold my iphone this time.

Yuri Apostol wrote a great tutorial on drawing volumetric objects* in Inkscape: The tutorial covers things like smart use of gradients, blur, clipping paths and simulating the missing conical gradient fill. * the text says “…and my little scarf!”

Just a quick note to mention that my Ubuntu Developer Week session on Application Indicators got moved to today. It's at 1900 UTC. It'll be an overview of what we're doing, why, and some of what application developers need to think about when implementing AppIndicators in their code. I hope to leave a lot of time to questions as well. Stop on by #ubuntu-classroom on Freenode and bring questions!