Home » Forums » Users Forums » Bug reports

Wipe - Luma Bug

10 posts / 0 new
Login or register to post comments
Last post
Fri, 03/04/2011 - 13:43
#1
Dalgo
Dalgo's picture
Offline
Joined: 10/21/2009
Posts:
Wipe - Luma Bug

Using wipe effect kdenlive works fine, but all luna effects makes crash!

from terminal:

** (:6121): WARNING **: Invalid borders specified for theme pixmap:
/home/kkk/.themes/Arbeit Macbuntu New/gtk-2.0/Combobox/line.png,
borders don't fit within the image
: Fatal IO error 9 (Bad file descriptor) on X server :0.0.
KCrash: Application 'kdenlive' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
sock_file=/home/kkk/.kde/socket-kkk-1/kdeinit4__0

** (:6121): WARNING **: Serious fd usage error 12

** (:6121): WARNING **: Serious fd usage error 16

But why there is problem with theme?
And after crashing there is no bug report window :o

Ubuntu 10.10
KDENLIVE 0.7.9.

0
Your rating: None
Top
Tags:
Fri, 03/04/2011 - 13:48
#2
Dalgo
Dalgo's picture
Offline
Joined: 10/21/2009
Posts:
Re: Wipe - Luna Bug

after changing system theme terminal shows this:

: Fatal IO error 9 (Bad file descriptor) on X server :0.0.
KCrash: Application 'kdenlive' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
sock_file=/home/kkk/.kde/socket-kkk-1/kdeinit4__0

** (:6334): WARNING **: Serious fd usage error 16

** (:6334): WARNING **: Serious fd usage error 14
kkk@kkk-1:~$ kdenlive
project monitor connected
clip monitor connected
QWidget::insertAction: Attempt to insert null action
QWidget::insertAction: Attempt to insert null action
Object::connect: No such signal Monitor::refreshClipThumbnail(const QString &, bool)
: Fatal IO error 9 (Bad file descriptor) on X server :0.0.
KCrash: Application 'kdenlive' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
sock_file=/home/kkk/.kde/socket-kkk-1/kdeinit4__0

** (:6359): WARNING **: Serious fd usage error 16

** (:6359): WARNING **: Serious fd usage error 14

Top
Fri, 03/04/2011 - 15:44
#3
sunab
Offline
Joined: 12/28/2008
Posts:
Re: Wipe - Luna Bug

hi,

2 recent git commits to MLT fixes some luma transitions stuff.
Unable to reproduce now, after update.

sunab.

Top
Sat, 03/05/2011 - 17:41
#4
Dalgo
Dalgo's picture
Offline
Joined: 10/21/2009
Posts:
Re: Wipe - Luma Bug

After update it works :)
but the quality is not so good : http://img816.imageshack.us/img816/4720/shot0001nd.jpg
why it is that?

Top
Sun, 03/06/2011 - 00:31
#5
ddennedy
ddennedy's picture
Offline
Joined: 06/26/2007
Posts:
Re: Wipe - Luma Bug

This quality issue is a problem with the build using --luma-compress, which forces the images to be reduced to 8 bit from their 16 bit origin. Try other wipes that end with .pgm and compare to the ones ending with .png or .pgm.png.

Only .pgm is supported in 16 bit (but .pgm does not always imply 16 bit). Yes, 16 bit .png is valid, but that bit depth is not preserved through the software layers required to load a .png.

Top
Sun, 03/06/2011 - 01:03
#6
sunab
Offline
Joined: 12/28/2008
Posts:
Re: Wipe - Luma Bug

So I will remove the --luma-compress option from my packaging, as I see in MLT 0.6.0 changelog "Make --luma-compress imply --luma-8bit".

sunab.

Top
Sun, 03/06/2011 - 07:59
#7
ddennedy
ddennedy's picture
Offline
Joined: 06/26/2007
Posts:
Re: Wipe - Luma Bug

sunab, I want to clarify that change message so as not to give anyone the wrong impression. The change you reference was to address a problem in some environments with loading a 16-bit grayscale PNG _at all_. However, even when it is loadable, it is not loaded as 16-bit because MLT and libs does not support that. 16 bit PGM is handled specially directly within the luma transition partly because it is easy to load, and we wanted to have the higher quality it affords. PNGs are loaded through gdk-pixbuf or qimage, which only support 8 bits per component:
http://library.gnome.org/devel/gdk-pixbuf/stable/gdk-pixbuf-gdk-pixbuf.h...

In any case, I agree with your change to the package. :o)

Top
Sun, 03/06/2011 - 18:00
#8
sunab
Offline
Joined: 12/28/2008
Posts:
Re: Wipe - Luma Bug

I have modified my packages and run a test, this is good ... Here is the before/after image (50%resize), the benefit is obvious.
Modifying this has a little side effect : the luma files are now named file.pgm instead of file.pgm.png, and when you have an old kdenlive project file with the old naming, kdenlive does not find the requested file name and the wipe transition is empty.

@ Dan : Do you think it is possible to implement a kind of fall back protocol in kdenlive allowing to switch automatically from *.pgm.png to *.png (and reverse) if one or another is not found?

ps : I'am asking nobody to do it. My question could be : in your opinion, is it easy to do?(it could be my first contribution in kdenlive code).

8bits_vs_16bits_luma_wipe.png
Top
Tue, 03/08/2011 - 00:19
#9
Dalgo
Dalgo's picture
Offline
Joined: 10/21/2009
Posts:
Re: Wipe - Luma Bug

After update all works fine, but just don't get how to use that 16bit option!

And also resize and Pan and Zoom option works 100% better then previous kdenlive versions (even rendered video's looks better then exported frames from kdenlive) :) and that's just AWESOME.

This software is growing, that's for sure!!!
thumbs up!

Top
Mon, 03/14/2011 - 00:08
#10
ddennedy
ddennedy's picture
Offline
Joined: 06/26/2007
Posts:
Re: Wipe - Luma Bug

sunab, regarding the fallback, interestingly enough, MLT already has a fallback to look for .pgm.png if the .pgm does not exist. It should be easy to add the fallback from .pgm.png to .pgm in src/modules/transition_luma.c
I will leave it for you since you are interested.

Top