[CinCV] Shape Wipe images
Hi, I saw your Shape Wipe Images at: http://cvs.cinelerra.org/transitions.php and I installed them in the same folder as the default Shape Wipes that come with Cinelerra, but the program doesn't see them. How do I install them so that Cinelerra sees them? I looked everywhere, including the IRC channels, but no one seems to know how to do that. Help would be much appreciated! Thanks George
Re: [CinCV] Shape Wipe images
On Sunday 08 June 2008 08:42, George Chan wrote: Hi, I saw your Shape Wipe Images at: http://cvs.cinelerra.org/transitions.php and I installed them in the same folder as the default Shape Wipes that come with Cinelerra, but the program doesn't see them. How do I install them so that Cinelerra sees them? Cinelerra does not see them. You can place them wherever you want. You have to specify the shape to use in the transition configuration. The last one you specified, will be the default for subsequent transitions. To specify the shape, right-click on the transition icon in the timeline, choose Show. In the window that appears, there's a browse button. You know how to continue from here. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Some ideas for Lumiera... (was) PiTiVi Has some ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Murphy schrieb: Some people see editing as taking a long film and splitting it up. For me it about organising lots of small clips into a big one and PiTiVi was fairly good for that. Hi Tim, yes, both concepts are equally valid and are known since the beginning of cutting film. I heard some people associate them with the two prevalent types of editing machines, where the horizontal working editing desk type machines would rather fit the split and chain together approach, while the vertical working moviola-type machines would rather tend to support vaporize it into tiny clips and then build the movie up. I would like tools that make it easy to see all my clips (first frames) organise them into some rough groups and sequences - a kind of album a bit like google picasa but with ordering. As far as I can see, we (Lumiera devs) are well aware of the importance of storyboard work, organizing your clips in the media bins etc. It may look as if we don't care, but this is just due to the fact we need to concentrate at the goal and with it the timeline first. Having said that -- especially this media manager and storyboard part would be a nice opportunity, where another developer could work without much interference with the work on the editing core. Btw, as our our current planning, Lumiera will have several perspective like GUI arrangements for focussing on different tasks. Edit in low resolution Is one of our prime objectives. Support will be built into the core. Use separate, asynchronous processes. Of course we do it this way ;-) Our rendering and data backend works mostly asynchronous with respect to the GUI. Christian is about to build an elaborate cache, which maps to a user provided caching area/file on disk. I (for the middle layer) will collect and provide the necessary information to invalidate cached data precisely on edit operations. I know this is ambitious, so please don't expect any results soon :-P I also think that video processing tasks should be run in a separate process from the gui so that they can't cause it to crash if they crash themselves. No, No, No! That would be completely misguided, IMHO. We should never bend the architecture in order to isolate against possible crashes. The application must not crash, period. We should never tolerate possible crashes. That's the broken window theory, you know. Besides that, there may be arguments in favour of running the GUI in a separate process, e.g. to have the core and backend running on a dedicated video processing machine somewhere in the network. But there is also a massive drawback with this approach: having multiple processes means you need Inter Process Communication, which is costly both in terms of execution and development resources. Cheers, Hermann V. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITBITZbZrB6HelLIRApskAKCDAcuP8bFZz3RA23d6GzwLhyY4sACdGYVI jGXSM7oxNCqQWAKu1n+D87M= =+Gs5 -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Some ideas for Lumiera... (was) PiTiVi Has some ideas
I also think that video processing tasks should be run in a separate process from the gui so that they can't cause it to crash if they crash themselves. No, No, No! That would be completely misguided, IMHO. We should never bend the architecture in order to isolate against possible crashes. The application must not crash, period. We should never tolerate possible crashes. That's the broken window theory, you know. Besides that, there may be arguments in favour of running the GUI in a separate process, e.g. to have the core and backend running on a dedicated video processing machine somewhere in the network. But there is also a massive drawback with this approach: having multiple processes means you need Inter Process Communication, which is costly both in terms of execution and development resources. When a program or just a part of it crashes, then it doesn't fulfil the job which was requested, for the user experience both are equally bad. Isolating things into subprocesses won't fix this and costs a lot more work and performance. The real problem with a crash is that the user might loose unsaved work. Lumiera *might* crash sometimes because of programming bugs (we are not perfect, but we aim to be) or by problems out of our reach, buggy codecs, power failures and so on. We have to ensure that the user *never ever* looses any work by a unintended programm termination, point. The plan is to make it bullet proof against data loss by saving project data in a database like dump+log like fashion. This gurantees recoverability even better than the current 'Load Backup' feature of cinelerra which is already a cool thing. As side effect the user gets almost unlimited selective undo too. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] [Bug 499] New: Green lines/bands in Portrait images
http://bugs.cinelerra.org/show_bug.cgi?id=499 Summary: Green lines/bands in Portrait images Product: Cinelerra Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: File Loading AssignedTo: cinelerra@skolelinux.no ReportedBy: [EMAIL PROTECTED] Cinelerra 2.1CV (C) 2006 Heroine Virtual Ltd. Compiled on ven apr 18 02:54:47 UTC 2008 This problem has haunted me for a long time now. Basically, if I load images off a camera, and they are portrait (i.e. taken with the camera sideways), when I load them into Cinelerra, I get green bands or green lines across the image. Opening in Gimp, and changing things and resaving doesn't seem to help. It's not just in the display, as rendering the video shows the lines too. Reproducible: Always Steps to Reproduce: 1.Load a portrait JPG (Both off a Minolta DSLR and my Canon Compact) 2. 3. Actual Results: Green bands/lines across image Expected Results: Image should display without the green lines -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] [Bug 499] Green lines/bands in Portrait images
http://bugs.cinelerra.org/show_bug.cgi?id=499 --- Comment #1 from [EMAIL PROTECTED] 2008-06-08 21:32 +2 --- Created an attachment (id=240) -- (http://bugs.cinelerra.org/attachment.cgi?id=240action=view) Screenshot of image with green bands -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] [Bug 499] Green lines/bands in Portrait images
http://bugs.cinelerra.org/show_bug.cgi?id=499 --- Comment #2 from [EMAIL PROTECTED] 2008-06-08 22:14 +2 --- Interesting. I see it with my own JPGs, too. Regardless of whether the orientation is coded in EXIF or whether the JPG data itself is portrait. -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] [Bug 499] Green lines/bands in Portrait images
http://bugs.cinelerra.org/show_bug.cgi?id=499 --- Comment #3 from [EMAIL PROTECTED] 2008-06-08 22:17 +2 --- (In reply to comment #2) Interesting. I see it with my own JPGs, too. Regardless of whether the orientation is coded in EXIF or whether the JPG data itself is portrait. I'm glad it's not just my photos!! I've read similar bug reports that seem to be related to MJPEG, but I don't think this is related. The only other thing I could think of is that something is encoded differently in the fields when taken as portrait. I should actually try rotating a normal photo and see if it has the same problem... A task for the morning, its sleepy time here. Tim -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Some ideas for Lumiera... (was) PiTiVi Has some ideas
Hi, 2008/6/8 Christian Thaeter [EMAIL PROTECTED]: I also think that video processing tasks should be run in a separate process from the gui so that they can't cause it to crash if they crash themselves. No, No, No! That would be completely misguided, IMHO. We should never bend the architecture in order to isolate against possible crashes. The application must not crash, period. We should never tolerate possible crashes. That's the broken window theory, you know. Ha! ;-) Fair enough. I suppose that all my most annoying crashes in Cinelerra have been in the GUI anyhow (according to Valgrind). I look at the crash output of the program and every time I decide that I simply don't have the energy to learn enough about Cinelerras internals to find the root cause of the problem because it's so potentially complex, being multi-threaded and having it's own GUI toolkit. Anyhow when a standard toolkit is used I expect that half the problems will just never happen. Cheers, Tim
