Re: [Gimp-developer] Export issues
> Date: Sun, 27 May 2012 12:20:09 -0400 > Subject: Re: [Gimp-developer] Export issues > From: nicolas.robid...@gmail.com > To: strata_ran...@hotmail.com > CC: gimp-developer-list@gnome.org > > Warning: Unless your crop is aligned with JPEG block boundaries > (I don't know if GIMP uses 16x16 blocks at all when exporting. It may > stick to 8x8 for all channels?) Subsampling ratio is part of the JPEG export options. So 4:4:4 = 8x8, 4:2:2 = 8x16 or 16x8 , 4:2:0 = 16x16. -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Export issues
El 27/05/12 18:10, Richard Gitschlag escribió: Unfortunately that is the whole point of the distinction - "Save" is now intended strictly for XCF. Me, I would like to see an option where instead of just displaying a message to "use Export for non-XCF formats" that message box should have "Export / Cancel" buttons to make the transition easier. I think this is a great idea. I'm a graphic designer and I can understand the difference, but a lot of home users I know will need some time to understand and use the new way. This does, of course, mean that Exporting as a non-XCF file no longer resets the saved state of the image. GIMP will now constantly ask you to "Save changes?" if you haven't saved an XCF copy (even in workflows where there is no need to have one) of the image. And you do know JPG to JPG in general is not a good workflow to be using due to it being a non pixel perfect (lossy) compression? (Okay, if part of your workflow involves resizing it to a smaller resolution then this alleviates the matter - I do it a lot myself.) I understand this, but when you work whith JPG images to be used on a weblog or webpage, there are no need to use a high quality workflow (it is more important to have little image sizes than high quality images). So, working from JPG to JPG it is good, it is great!. Sometimes I have 1024x1024 images, and I only need to open, aply level adjustment, resize and save. With Gimp 2.6 I only use 3 clicks (drop image, clic on levels, clic on close, clic on yes). Now I have to do more work to do the same. If I want to use a quality workflow (for example to working with complex images with layers, mask, and so on) I will use XCF, SAVE and lately EXPORT. But when I only want to do a simple task, 100% of times, I only want to open, apply a litle modification, and close (overwriting the original file). El 27/05/12 18:12, Alexandre Prokoudine escribió: http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=187e20f3673ffd1d437c9aeb1232c4764760616f The fix will be available in 2.8.1. Great new! ;) I hope this version enter soon on Debian testing. :D Thank you! Salu2 de jEsuSdA 8) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Export issues
> And you do know JPG to JPG in general is not a good workflow to be using due > to it being a non pixel perfect (lossy) compression? (Okay, if part of your > workflow involves resizing it to a smaller resolution then this alleviates > the matter - I do it a lot myself.) Warning: Unless your crop is aligned with JPEG block boundaries (generally 8x8 or 16x16, often 8x8 for the Y channel and 16x16 for the Cb and Cr channels, starting at the top left corner of the image. I don't know if GIMP uses 16x16 blocks at all when exporting. It may stick to 8x8 for all channels?), cropping is a very destructive operation, likely to increase file size significantly at equal perceptual quality. It's even more destructive if the internal representation is 8-bit (which of course is not the case with goat-invasion). ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Export issues
On Sun, May 27, 2012 at 7:28 PM, jEsuSdA 8) wrote: > The firs is about PRESETS. When I export as JPG and I configure the > parameters, then I click on "Save prefs", but when I export as JPG a new > image, the presets are lost instead I click on "Load prefs" button. This is > a uggly thing who made me lost a lot of time and patience. :D http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=187e20f3673ffd1d437c9aeb1232c4764760616f The fix will be available in 2.8.1. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Export issues
> Date: Sun, 27 May 2012 17:28:53 +0200 > From: lis...@jesusda.com > To: gimp-developer-list@gnome.org > Subject: [Gimp-developer] Export issues > > Another issue appears when open a JPG image, edit it and close. > Instead of saving the image using the same original formt and > parameters, Gimp try to SAVE as XCF. If I want to SAVE, be sure I will > clic SAVE. If I clic close (without saving) is cause I want to save the > image exactly as I load it. Unfortunately that is the whole point of the distinction - "Save" is now intended strictly for XCF. Me, I would like to see an option where instead of just displaying a message to "use Export for non-XCF formats" that message box should have "Export / Cancel" buttons to make the transition easier. This does, of course, mean that Exporting as a non-XCF file no longer resets the saved state of the image. GIMP will now constantly ask you to "Save changes?" if you haven't saved an XCF copy (even in workflows where there is no need to have one) of the image. And you do know JPG to JPG in general is not a good workflow to be using due to it being a non pixel perfect (lossy) compression? (Okay, if part of your workflow involves resizing it to a smaller resolution then this alleviates the matter - I do it a lot myself.) -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
