Re: [libregraphics-resources] Guidelines for submitting and reviewing test images |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/libregraphics-resources Archives
]
- To: libregraphics-resources@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [libregraphics-resources] Guidelines for submitting and reviewing test images
- From: Jehan Pagès <jehan.marmottard@xxxxxxxxx>
- Date: Thu, 12 Feb 2015 19:21:40 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+iXSDddABzy6Qe9jtCGpZjGxJncFBVx2o2eCaA3TX8s=; b=VlR6fnvszs97o0TasG6X1+wSt7Ta1O9fzMy6GGWd90qeRCzLHfIGxRj2XLEZFiJRzm AaAiee4IJrgRntHHnjNYZEhsK1vATzAdjsyiyNlh2oq/1iQ45g4HXnUPe0K2mQsr1ksO k6Xmxdmp6DX3jMx6kADRKqlhU4IXYTXQmmdhyrr90Q9gebNygt4kteEuBsFjNmCfnmOz VftYwUwzaTVZl/38BjR3yWRdRhP1imRodLNKgEkvyhUEh5zT54ZAvs9UvuAHAi1c7Yw5 GVch5TLdd99q3j5JwmN97+IbGK/iJyszz2X5RiTwcjYHbgoyfqCG5xg1JP3KbmnbRzYq lw4w==
Hi,
On Thu, Feb 12, 2015 at 5:52 PM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
> Proposed submissions to the website should probably include a suitably sized
> jpg along with a description of what the full-size file is good for, and an
> indication of copyright information. I think the best way to come up with a
> good procedure is to work through some actual submissions. So here is a
> proposed submission in the category of raw files for testing raw processors:
>
> http://ninedegreesbelow.com/files/test-images/very-yellow-flower.jpg
> http://ninedegreesbelow.com/files/test-images/very-yellow-flower.cr2
>
> It might be a good idea if people who want to submit an image first send
> just a jpeg, of perhaps maximum width/length of around 900px, in order to
> not be in the position of having to download a 36MB raw file or a 200MB tiff
> just to see what the image looks like.
>
> The jpg should be accompanied by an indication of what kind of testing the
> image would be good for, along with usage notes and the desired licencing
> information:
>
> What the very-yellow-flower.cr2 raw file is good for:
> * This raw file is good for testing a raw processor's ability to not clip
> RGB data upon outputting an image with colors that exceed whatever interim
> color space the raw processor might push the data through. For example,
> RawTherapee pushes all images through ProPhotoRGB during its default
> rendering, and consequently severely clips the blue channel of the very
> yellow flower image to solid black, even though th blue channel is actually
> fully detailed. This is true even if the user requests a suitably large
> output color space. See
> http://ninedegreesbelow.com/photography/linux-raw-processor-review.html#radiometric,
> section F5, Figure 4 for details.
> * This raw file is also good for testing how the raw processor handles
> highlight detail that exceeds 1.0 after the white balance multipliers have
> been applied. UFRaw clips the highlight detail in the very yellow flower's
> red channel, even if the user tries to use negative exposure compensation
> and even though there are no clipped pixels in the raw file red channel. See
> http://ninedegreesbelow.com/bug-reports/ufraw-highlights.html for details.
>
> My apologies for starting with such a complicated-to-describe test file. But
> it is an excellent raw file that reveals serious raw processor limitations,
> and especially so for people who primarily work with black and white
> renditions and really want to preserve channel detail.
>
> Usage notes:
> The "camera" white balance in very-yellow-flower.cr2 is "UniWB", but the
> actual white balance that should be used during raw rendering is "Daylight"
> (the image was shot in full afternoon sun).
That's all very good. I see 2 additional points:
1/ the submitter should be the resource author. Then I guess one needs
to provide a valid email, which won't be displayed, since we may want
to be able to contact a submitter in case of copyright claim. I'm not
sure we need a real name though (especially if the license is public
domain/CC 0).
Though we could accept resources if the submitter has been given the
rights to submit these (either because they were published somewhere
else under a corresponding license, in which case we'd need the
original link; or because there is another kind of relationship, like
an assignment of rights, in which case I guess we'd require a scan
maybe?).
2/ If people are recognizable on a photo, I think we'd need the
authorization from the recognizable subjects too, no?
> Licencing:
> I set the copyright as CC BY
> (http://creativecommons.org/licenses/by/4.0/legalcode), but I'm willing to
> make it public domain/CC0. Use "exiftool -a -G very-yellow-flower.jpg (or
> cr2)" to see the embedded copyright information in the very-yellow-flower
> images.
>
> We might want to write up a page that informs people of useable copyrights,
> how to choose a licence, and how to embed the copyright information. I don't
> know how to embed the Creative Commons xmp file generated by the licence
> chooser at http://creativecommons.org/choose/.
>
> Acceptable copyrights:
> We probably should come up with a short list of acceptable copyrights, with
> public domain/CC0 perhaps being the preferred status, followed by CC BY.
> Images should probably have the relevant copyright information right inside
> the image metadata, as well as stated in words on the website, and the two
> sets of copyright information should match.
I'd personally go up to accept even CC by-sa, though I completely
agree that for the purpose of a reuse project, CC by or public domain
are ideal.
Jehan
>
> Elle
> --
> http://ninedegreesbelow.com
> Color management and free/libre photography
>
> --
> - Archive are available at:
> http://listengine.tuxfamily.org/lists.tuxfamily.org/libregraphics-resources/
> - To unsubscribe: send an email with title "unsubscribe" to
> libregraphics-resources-request@xxxxxxxxxxxxxxxxxxx
>
>
--
- Archive are available at: http://listengine.tuxfamily.org/lists.tuxfamily.org/libregraphics-resources/
- To unsubscribe: send an email with title "unsubscribe" to libregraphics-resources-request@xxxxxxxxxxxxxxxxxxx