Episode 138: A mixed Bag

Download the Video! (41.2 MB, 21;40)

A really mixed bag today. First I reveal my criteria for selecting the images of the last show and tell, why I think that deleting of not so good images is a good idea. Then I show a bit of how I recorded the sound in Hamburg and how I used Cinelerra to include the sound in the show. This can be a good way to make a slide show out of your images. Add the stuff from “Cinelerra in Japan” and Michelle’s instruction videos and you are set.

Finally I “prove” that higher bit depths are important for editing – not for input or output.

A proper blog entry will follow when my DSL line is repaired.

34 thoughts on “Episode 138: A mixed Bag

  1. Why didn’t you use the Cue Gardens portrait for your job application? It has much more style and depth then this one. Well, it seems it still did its job…
    The artefact from the curves will not go away with 16 bits. Even in ps you can only do one strong and maybe one or two weak curves before you get it. It it less but not much. Just do curves only one and it is ok. And curves in the only one with 16 bits has some plus. All else is ok in 8 bits, because only Curves are bent and has non-linear calculations.

  2. The feed has been fixed – please reload if you still get the old episode.

    I’ll try the curves with CinePaint in high bit depth and compare it with GIMP.

    The Kew Gardens portrait is years old, they want to see the current state of the ruin. ;-)

  3. Thanks for discussing your personal criteria for keeping/deleting images. It was – as I guessed it might be – very helpful to hear your thoughts; and also your discussion more generally about what to archive.

    A few of terabytes of RAID network drive is not impossibly expensive these days, so you might think archiving is not an issue. But high-end DSLRs now generate a 12+Mb RAW and a 3+Mb JPG for every shot; and a couple of hundred shots on an outing is not unusual. So you can fill even such seemingly ridiculous amounts of storage space remarkably fast.

    But storage capacity, as you pointed out, is not itself the main issue. Merely storing the data is useless if you can’t retrieve an item you want. The vast pile of images we amass so quickly is effectively useless without some serious ‘digital asset management’ (e.g. with Digikam). But organising and tagging all this stuff is time-consuming and tedious, so some ruthless deleting before you go to that trouble is essential if you’re ever going to reduce the task to a size that will motivate you to do it (and I confess to finding it all too easy not to be motivated!)

    I think you implied that your ‘Delete’ criterion has to do with the question ‘Am I seriously ever going to edit this picture or show it to anyone?’ I guess that’s what I try to do, too – and should try harder to do more ruthlessly.

    I’d be very interested to hear how others here decide what to delete, and how else to keep their archive under control.

    Many thanks for another excellent and thought-provoking show.

    (And roll on floating point arithmetic in GIMP!)

    mac

  4. mac: ‘Am I seriously ever going to edit this picture or show it to anyone?’ – EXACTLY. I’ll steal that sentence.

    Added to that – do *I* want to look at the image again. For example as an aid to recall the situation, either emotionally or in the more technical aspects of the images like the layout of a scene, the light and so on. I sometimes do such shots.

  5. @mac
    You’re right. Storage is no big issue, you get 1.3TB drives for ~100€ these days and if you md two or three together they give good reliability and speed.
    However, filling that up quickly is also true. At the book fair I took about 5500 shots in just four days, totaling to around 104GB, raw only. Scared me the heck as I started to make backups on sunday evening…
    Shooting raw+jpeg is a waste in almost all cases, as the raw file already contains an embedded jpeg you can extract with dcraw -e. As most programs will use this included jpeg for previewing and thumbnails anyway you can save space and work this way and the camera buffer will last longer.
    For the untagged pile of old images I found a lazy solution: digiKam shows untagged files as a separate category and everyday I just select ten old photos from there and tag them. This way they will get done over time and it’s not much work.
    Deleting photos _is_ important, but I rarely do it in digiKam or another program. The really bad candidates won’t even survive in the camera and the others get deleting while skimming through the photos imported from the card. I use Gwenview and my cleanalonerawfiles script for this. Whatever survives that will stay, mostly. At least it will make it onto the backups.

  6. I allways use NEF+JPG. First I delete the images, I don’t like. But that are not to much, because I don’t take that much pictures. 200, maybe 300 on a complete day, which includes variations and second shots after bad metering. The second step is to separate the NEFs into the “Originals” folder. Then I use my RAW-converter and convert it back into the TMP folder and compare it with the JPG. I need this step, because sometimes I overdo it in the converter and get back to the ground. After that I delete the original JPGs as well.
    But using the embedded JPG could be a good solution. My program shows the embedded JPG in the thumbnails, but when I select the image, the program renders an own version of the NEF. That’s why I need the original JPG.

    After I read somewhere, that it is better for data safety not deleting single files from a memorycard, I keep all pictures until I format the card in the camera before use. Don’t know, if this is true, but I never had problems with my memorycards so I will do it furthermore.

  7. congrats on your new job!
    sadly mtg will suffer cause of the move. living in a new area needs two years to become resident

  8. I got a nice video from nachbarnebenan, showing the curves result in cinepaint. You’ll see it in the next show. Until then I’ll say nothing. ;-)

    Purr, I don’t think this project will suffer much outside of the time where I move my stuff. I need a certain level of stress to do this. Not to much… ;-)

  9. Pingback: Links 10/4/2010: RIM Buys QNX, Palm Pre Runs Almost Everything | Techrights

  10. Interesting episode, and congrats on the new job. A question on the 16 bit issue . . .

    My basic thought process has been that the fact of jpeg compression means I only want to do that compression once and curves (in GIMP) never for best quality images. So, raw (NEF) images are converted in ufraw, and curves done there if necessary. Then saved as 16 bit tiff. The tiff’s are opened in GIMP only for crop, clone, other manipulation, and then the final is sharpened if needed and saved. I was thinking that this sort of 8 bit manipulation has a minimal impact and then the image has only been JPEG compressed once, even if I have saved it as an XCF when I can’t finish in one session.

    Does this make sense? Is there some faulty reasoning here, or missed assumption?

  11. Patton wrote, “…curves (in GIMP) never for best quality images.”

    You can apply a Curves filter once in GIMP without any effective loss of image quality.

  12. @Patton: You will loose your Exif-data in the final image, if you use a 16bit-TIF with Gimp. At least this was the case in my tests.

  13. I should qualify that:

    You can apply a Curves filter once in GIMP without any effective loss of image quality … as long as the Curves filter does not apply more than a 200% change.

  14. @nachbarnebenan: Thanks for your excellent tip about selecting 10 untagged images with Digikam and tagging them. ( ‘How do you eat a mammoth? Cut it into steaks, and eat one a day!)

    Thanks, too, for your comment about RAW+jpeg. I’ve been shooting in both for a while, but I have to confess that I’ve rarely – if ever – used the jpeg for anything. I may try your ‘RAW-only’ approach, which will save a lot of complications about renaming two sets of files and keeping them in sync!

    @Patton: I’ve tried using UFraw for curves (I guess you’re referring to the ‘correct luminosity/saturation’ tab), but I don’t find it as easy to use as curves in GIMP, because the UFraw interface for the curve is so small. Also, I use the ‘dropper’ a lot in the GIMP curves tool to locate tones precisely on the curve, and there’s no equivalent in UFraw. I’d be interested to hear if you’ve found ways round these issues.

    (PS. In case Udi is reading this – I think UFraw is a brilliant piece of software that I absolutely could not do without!)

  15. Rolf,

    How will I get cinepaint? I looked on the side but there is no installer offered. Only downloads for Apple and others.

  16. @Sus
    To get cinepaint, you can download the tarball and install from source. To make that easier there is a script on the download page to install dependencies and then do the install. If you are not familiar with running scripts post back for explicit instructions.

    Patton

  17. @Fornit. Yes, loss of EXIF is a problem. Sometimes I don’t care, like when I am processing for printing. If it matters, the work-around is pretty easy. My camera makes a jpeg and nef. Before processing in gimp, I load the jpeg as the background then the tiff as a layer. The jpeg brings the exif data with it. I could just copy the info with exif tools, but having the background layer gives me a reference image while working.

    @mac. I don’t have a problem with the small curves window, but you are correct about the dropper. No work around for that.

    @saulgoode. Yes, I know that the conventional wisdom is that you can’t see the difference if you use a modest amount of curves in gimp. But if there are “combs” in the histogram, then you have lost data that can’t be printed. I wonder if anyone thinks it matters more for printed output vs. screen?

    Good discussion all.

  18. Patton,

    I not fully understand the instructions. Is cinepaint.org not the source? Where can I get it if not there? All I found there is Apple-related stuff, I have no Apple.

  19. Sus, first check if cinepaint is not already there, it may be. If not you can get it with apt-get install cinepaint or yum install cinepaint if you have fedora.

    Rolf, I hope you check the video before posting it.

  20. @Nemo
    While I still haven’t found the source of the video corruption, the one I send Rolf is fine.
    And you were right, as soon as you move the selection out of the layer boundaries it will not crop anything. I haven’t noticed this until now but it seems more like a bug to me.

  21. Ich kann leider kein Englisch und wurstle mich irgendwie durch. Vom zusehen verstehe ich meist worum es geht und wie man die Effekte bekommt. Aber das mit dem Porträ ist unklar. Mehr Kontrast ist gut aber es ist viel zu viel. Und nach dem korrigieren sieht es auf einmal anders aus. Kann es sein das da ein Stück fehlt? Oder vertauscht ist.

  22. Das Portrait war ein Beispiel dafür, dass man mit den 8 Bit von GIMP eben doch nicht alles machen kann. Viele Farbabstufungen verschwinden.

    Du wirst etwas ähnliches in der nächsten Folge sehen, allerdings mit einem hübscheren Modell. Da sieht man dann den Unterschied zwischen 8 Bit und der großen Bittiefe von Cinepaint.

  23. Dann ist das natürlich logisch. Aber warum 8bit? Gibt es dafür einen Grund? Normalerweise hat man doch 24 oder 32bit für ein Bild. Ich kenne das nur aus alten Zeiten wo die Grafikkarten nicht mehr machten. Soll aus dem Bild ein .gif werden oder so? Dann ist es logisch geht ja nicht mehr.

  24. > You will see something in the next episode, but with a prettier model.

    That is interesting. Now we see the other half from Meet the GIMP. We got her voice over 2 years before in issue 22 and sound nice. Now we see her. And in high bits depth and hd. Cool!

    When will next 2.7 beta appear?

  25. @Sebastian: GIMP hat 8 Bit pro Kanal, also 4*8 = 32 Bit pro Pixel. (RGB+Transparenz). Ist so, weil “damals” Standard und dann nur schwer zu ändern. Das soll mit GEGL wesentlich besser werden, Fließkommazahlen für jeden Kanal. In den Kommentaren gab es einige Meinungen, dass 8 Bit reichen, ich wollte zeigen, dass sie doch nicht so gut sind. (Explaining to Sebastian what the stuff with the heavy curves was about. He doesn’t understand English.)

    @Corazon: Even better, the model has about 30 years less traces of life then my partner…. ;-)

  26. 16bit are nice to have, but if you use a raw-converter for the basic work and just do decent changes afterwards in Gimp, there are only rare cases, you see a difference. It’s a little bit of a hype here. Everyone wants that only program which just have that feature. But it’s not even the only program, who can do that.

    I sent Rolf an example via e-mail, where you see the differences between 8bit and 16 it very well. But you would never do such changes in reality. In some cases, I’ve see differences on some gradients after “normal” changes. But I think, this wasn’t caused by the 8bit, it was probably the JPG-compression. So an 8bit TIF would be a not to bad start.

  27. I found the explained file. As unpacking it fills my whole desktop with files. I spend all morning deleting. And I am not safe I have all. I found no installer or instruction to deal with this. How do I this?

  28. I have the same problem with curve like Rolf. I edited many fotos from the wedding only home see the other monitor was bad setup. All fotos miss blue and green colour and not much shadow and light only middle.
    I own backup but only changed variant. I edit and save and open next foto. Only home I notice Gimp ouverwrite the original. And many fotos are now mushy and some have colour specles.
    Can I repair this someway? I need the fotos, only I make fotos to the wedding.
    I can sent fotos but not show them online please.

  29. Hi Rolf,

    let me take this opportunity to thank you for your wonderful screen casts. This is highly appreciate in the Longtom family.

    Let me also take this opportunity to tell you that the link for cast 138 is not working and is leading me to a 404, just to let you know.

    I’ll have a look again later to see if you managed to fix that.

    Once again thanks for your efforts!!

    Regards

    Longtom

  30. Pingback: MTG: Эпизоды 2 квартала 2010 « Блог фотолюбителя :)

Anything to add from your side of the computer?