Help talk:Adding images

From Camera-wiki.org
Jump to: navigation, search
This is the discussion page for Adding images. Click here to start a new topic.


Discussion pages are for discussing improvements to the article itself, not for discussions about the subject of the article.


Contents

Outstanding!

A huge thanks to the rock-star Dustin McAmera for adding that explanation & sample code for grouping images! --Vox 14:48, 15 March 2011 (PDT)


Worrying redundant templates


Link pointing to the Flickr pages

It took me two painful hours to browse the images in Camerapedia's Flickr pool and add a link back to the corresponding page in each place where we were making a direct hardlink.

From now on, any image that does not have a link pointing to a page in Camerapedia's Flickr pool is suspect, and needs to be commented out if the source cannot be found easily.

--Rebollo fr 13:17, 10 June 2006 (EDT)

大変お疲れ様でした!白髪 20:16, 10 June 2006 (EDT) PS is there more work to be done? (Not that I can even start on it for 48 hours or so.) More importantly, how did you find the links to images hosted elsewhere, and is there more work to be done there? (I looked in "Special pages" for "Pages with images" or similar, but didn't find anything.) -- Hoary 22:15, 10 June 2006 (EDT)

I ran a link checking software on the whole site. You learnt me the existence of these tools some weeks ago, and I thought they could be used for such an usage. If the software is reasonably well conceived, it allows you to search for a regular expression in the links. I tried with "jpg" and easily found the links to anything other than Flickr.
There were two images directly linking to a commercial site, and one to a site where it is stated that the image was taken from a commercial site (!) These three were immediately deleted. There are two pages (Riley and GAF) where I am confident enough that the contributor and the author of the website are the same. I left them in place, but I will investigate and ask them if they can put the images in Flickr.
Now there are still some images that are in Flickr, but not in Camerapedia's pool. The same tool I used will point me to all the pages with a Flickr hosted image, but won't do the difference between the legit ones and the others. It won't be too long to check however. --Rebollo fr 05:50, 11 June 2006 (EDT)

Excellent work, Sir! -- Hoary 10:02, 11 June 2006 (EDT)

Update: the Riley page is OK and I have received a private mail to confirm it. The GAF page is certainly not OK because the images have the eBay watermark, so I removed them. I will contact the site owner.
The Fujipet, Polaroid 600/600 SE and Yashica Electro GX pages are probably OK in the sense that the owner of the images is certainly Cameron. There are problems remaining because the Fujipet image appears in Flickr with "© all rights reserved" in the user page of some of Cameron's pseudos. Also I am not sure if the signature in the Yashica Electro GX is required by the Creative Commons licence, or if it needs to be removed. I am trying to contact him.
If you find other images with no link, please tell me. --Rebollo fr 10:14, 11 June 2006 (EDT)

Creative Commons and GFDL aren't the same . . . and other problems

We read: You must assume that any image is copyright in such a way as not to allow this unless it is accompanied by a clear statement contradicting this, e.g. that it is copyleft under a "Creative Commons" license.

Fine. But that wouldn't imply that a CC-licensed image could be used.

Let's suppose that I found an explicitly CC-licensed image, which I'll call X.jpeg, on a non-Flickr web page that I'll call X.html. But writing [http://foobar.org/X.html http://foobar.org/X.jpeg] raises numerous problems. Now let's suppose that I copy it to C'pedia's part of Flickr. Uh, I don't think so -- Flickr has its own conditions. Now suppose that C'pedia is suddenly given millions by some philanthropist: could it now be hosted here? No it couldn't, because this site is GFDL and CC is not GFDL.

I don't pretend to understand the issues that are raised by incorporating images hosted by other sites, and am a bit too tired right now to attempt to think it through. However, I suspect that the only thing to allow are links to the Flickr area (as long as Flickr permits this) -- and the admission of photos to that may need its own policing (groan) -- and links to sites that editors here credibly claim are their own. These editors had better be willing to have these photos appear elsewhere, because the main page of this site says "Content is available under GNU Free Documentation License 1.2" and it would be hard to claim that an image appearing within the page is not "content". -- Hoary 05:17, 12 June 2006 (EDT)

Is it possible to upload a public domain image to Flickr's CP pool? Flickr's guidelines are not very clear. --Rebollo fr 05:53, 12 June 2006 (EDT)
You can do anything you like with something that's in the public domain; therefore, yes. -- Hoary 06:43, 12 June 2006 (EDT)
Even if that means adding the public domain image to your own pictures? Flickr requires me to upload pictures that I took myself. In a broad meaning: pictures on which I have rights, so public domain is OK, Creative Commons is OK too if I mention the author and do the other things required by the licence. In a restricted meaning: pictures that I took myself bar none, so nothing else than what came out of my camera when I pressed the button myself. --Rebollo fr 06:50, 12 June 2006 (EDT)

Real name

Vox, you've just now made the following edit (adding the bit I've underlined):

Image_by: photographer, author or copyright holder. For Flickr users it's preferred to use their real name, capitalized normally, when this is publicly available (screen names can change over time).

You mean, instead of the Flickr handle?

Let's suppose that the Flickr handle of a kind provider of photographs is "squirrelface", and that "squirrelface" announces that his real name is Nicolas Bourbaki. What should we do?

As I understand it, addition of

image_by= XYZ

will (via some mechanism that I don't understand) automatically generate the addition of "[[Category:Image by XYZ]]". Well, do we want "[[Category:Image by squirrelface]]" or "[[Category:Image by Nicolas Bourbaki]]" or "[[Category:Image by squirrelface (Nicolas Bourbaki)]]" or "[[Category:Image by Nicolas Bourbaki (squirrelface)]]" or something else? Zuleika 07:40, 29 March 2011 (PDT)

This will definitely require more discussion with whoever coded the mechanism which generates image-by categories. Ultimately, we want one page per photographer. The difficulty is that people change their Flickr screen names, sometimes unrecognizably. ("Century Graphic" became "Dustin McCamera.")
A person's real name, alone, is probably the most stable way to name their images-by page. Thus it should be the preferred way to enter attribution into the Flickr template. It's still not the whole solution because any variation (capitalization etc.) still seems to spawn a new category. --Vox 08:13, 29 March 2011 (PDT)

Arranging images, intend to revise

This help page is linked directly off the wiki main page. It is important as a how-to tutorial; but it is also where newcomers may get their first impressions about our project.

The section on grouping images still needs to be made clearer and more consistent. The problem of arranging images is one that has confused several would-be contributors (and I'm the one who has talked to them). The Flickr template is (reasonably) self-explanatory; and wiki tables are at least somewhat mnemonic. As Dustin McCamera originally suggested, beginners will find it most comprehensible to combine those two tools, even if a particular image arrangement could be written more compactly in another syntax. So this is the method I feel we should promote here. This does not prevent any editor from using some other syntax they prefer.

The wiki tables currently shown in this section have double pipes before each image; while apparently that is harmless, I believe single pipes are correct (double pipes are used to separate cells all typed on the same line). --Vox 20:58, 24 April 2011 (PDT)

Perhaps I'll get to this later, if nobody else beats me to it. In the meantime, this page has bigger problems. See the section below. Zuleika 01:39, 25 April 2011 (PDT)

It seems that many changes are being made (or contemplated) to the Flickr image template. This makes me raise the question whether the future template will support the fields image2= and image2_source= which are shown at the bottom of this section

I think this feature is questionable, because it makes a special case of grouping two images side by side. I don't think it's worth adding complications to the new Flickr template to support it.

If this feature may not supported in the future, I suggest we comment out the description of the image2= and image2_source= version from the help page. We don't want people to design wiki articles which depend on this. --Vox 17:14, 26 April 2011 (PDT)

As I had mentioned this here earlier, and got no response, I went ahead and moved the two-image option to the Help:Arranging images reference page. I still think it's a low-priority feature to include in the Flickr template. --Vox 09:48, 29 April 2011 (PDT)

I don't understand what we say about the licenses

I don't understand what we say about the licenses. Here are the upper rows of the table, with my addition of two index numbers in white on red:

{{creative commons}} for images licensed under Creative Commons check license on Flickr before any re-use
{{non-commercial}} for images licensed under Creative Commons similar,(1) but explicitly non-commercial
{{commercial}} for images licensed under Creative Commons similar,(2) check license on Flickr before any commercial re-use
  • (1) Similar to what?
  • (2) Similar to what?

For the first, I can only think: "Similar to the row above. This to me implies: "Just like the row above, except that commercial use is definitely a no-no, so if that's what interests you, don't even bother looking."

For the second, I can only think: either (a) similar to the row at the top; or (b) similar to the row immediately above.

Well, which?

Let's try option (a). The very title is "Creative Commons (commercial use allowed)" (my emphasis). Not allowed in some circumstances or possibly allowed, but allowed. "Whoopee," think would-be commercial users. "Funny, though, that commercial use is allowed, but other use requires a reading of the license. Oh well, none of this 'wiki' stuff seems to make any sense anyway...."

Let's try option (b). So "Creative Commons (commercial use allowed)" is "similar" to "Creative Commons (not for commercial use)" (my emphases). Hang on, we're saying that the allowing of commercial use is similar to the prohibition of commercial use? This is getting screwier and screwier.

In an effort to find out, I click on Image license: Creative Commons (commercial use allowed). Its title announces that commercial use is allowed. Yet its text says that "Commercial use of this specific image may be allowed" (my emphasis). Uh, what? For now let's not worry about the fact that no namespace "Image license" exists. Instead, let's look at the subtitle. Shouldn't it be "commercial use in some circumstances", or similar?

"Whew," I think, "Who wrote this?" Some fool called Zuleika, it would seem. However, Zuleika retained (i) the title, and (ii) the exact clause "Commercial use of this specific image may be allowed" from a previous editor.

The whole thing makes no sense to me. Actually, the whole enterprise makes no sense. Why do we, a bumbling group of non-lawyers, link to our own pages? Even when the blatant contradictions within these pages are ironed out, they'll still be phrased inexpertly. Why don't we instead specify the precise license, and link to that precise license? Zuleika 01:39, 25 April 2011 (PDT)

An item on our To Do list is to create an image-importing tool which would automatically copy the exact license terms using the Flickr API. It will probably be Steevithak writing this (unless some other code whiz appears), and importing the full specific CC license is his intention.
Camerapedia only had a single "creative commons" option, and most instances in CW continue to use this —regardless of whether an image license specifies non-commercial or not. Recently, someone added "non-commercial" option to allow for a stronger statement that commercial re-use was forbidden. This is just an interim patch-up, awaiting the more automated solution. I would not invest much energy in trying to fix it.
I feel that the option "commercial" is superfluous. We already have "creative commons," and tell people to check the user's Flickr page for the exact license. It also seems to be an encouragement to copy and exploit the image—why? I would remove that option from the table.
I have added a link to Flickr's page about CC licensing.--Vox 07:32, 25 April 2011 (PDT)
That all sounds very sensible or welcome or both. Zuleika 06:50, 26 April 2011 (PDT)

Floating an image left or right; no table

2354347335_6278c0a66c.jpg

Early Wirgin Edinex
Image by John Nuttall (© Creative Commons)

5068593056_bd068b9eee_m.jpg
Pentacon FM, export model of
the Contax FM
Image by Marino M. (all rights reserved)

Just a little demo that might interest somebody:

Here we have an image in a DIV floated to the left, and another in a DIV floated to the right. The image on the left (I mean, the actual JPEG) has quite a bit of white space on all four sides, so here I've given it a right-hand margin of minus 35 pixels. I've also explicitly put the caption below it into a paragraph, in order to give this paragraph a left-hand margin of 60 pixels and a top margin of minus 40 pixels.

It's just an illustration of what can be done without tables but with some CSS. But of course for most images no such specific CSS is required, and a default floated DIV could have margins of zero above and on the outer side, and a fixed amount (10 pixels?) below and on the inner side.

As I view the page in the browser + window size + other variables I happen to be using now, the tiny blue square-plus-arrow icon for links appears in the middle of the text I've written. It's a result of the negative margin, which of course is unusual. But I could probably render it invisible by use of the CSS "z-index" property or similar. (I'm a bit rusty at this kind of thing.) Zuleika 07:28, 26 April 2011 (PDT)

We know the div approach from the beginning of camerapedia. We used it a lot, and let these divs float left or right as You do. You'll find many <div class="floatright plainlinks" ... stuff in old pages. What's new is Your margin pixel thing. But if DIV or TABLE, You can define margins as well with tables, it's a matter of Your personal taste. What's really in discussion to make things XHTMLized. There are recipes to solve disadvantages of XHTML, but concerning images these require the original HTML image tag. That's because the workarounds for XHTML disadvantages need size-control of the applied images. But You can't resize external images as we use them from Flickr by means of wiki syntax, and the img tag is forbidden in the Mediawiki wiki for some ideological reasons. Maybe Steevithak as our hoster can help by suppressing the mediawiki img tag suppression somewhere deep in the mediawiki code. Then we could create an even strict XHTML template, but only applicable for resized images.
HTML demo page shows that table based image presentation can be as nice, as well as many illustrated pages in this wiki, and You have the advantage to align the tables with the images in the center as well as floating right or left. The same may be possible for divs if You only use the align attribute for that tag. But that's just "XHTML 1.0 Transitional". Remember that even Mediawiki software fails to deliver that minimal XHTML recommendation completely. U. Kulick 08:16, 26 April 2011 (PDT)
I don't understand "to make things XHTMLized", or (in this context) "XHTML disadvantages".
You say: You have the advantage to align the tables with the images in the center as well as floating right or left. The same may be possible for divs if You only use the align attribute for that tag. The align attribute is not necessary, as I have already demonstrated here. Zuleika 08:25, 26 April 2011 (PDT)
Thank You for Your help, thus Steevithak don't need to tune MediaWiki code. But we still need workarounds for XHTMLization since we use float CSS attribute for side alignment and margin CSS attribute for middle alignment. That's still "XHTML disadvantages". U. Kulick 09:24, 26 April 2011 (PDT)
I'm sorry but I still haven't a clue of what you might mean by "XHTMLization". Zuleika 09:38, 26 April 2011 (PDT)
Common HTML code --> XHTML code = XHTMLization U. Kulick 09:41, 26 April 2011 (PDT)
There is no change from HTML to XHTML. Zuleika 09:48, 26 April 2011 (PDT)
Are you perhaps talking about the difference between (a) markup that validates against a Transitional DTD but not against the corresponding Strict DTD, and (b) markup that validates agains the Strict DTD (and of course against the Transitional one too)? If so, how about "strictness"? Zuleika 02:58, 27 April 2011 (PDT)
You tampered with what I wrote. Please do not do this. This is not an article, it is a talk page, in which people infer that I wrote the material that I clearly say is by me, and that I take responsibility for it. If you wish to change it, make a copy of it elsewhere and change that. Or if you think that I should do it, suggest that I should do it. Just as I would not change material signed by you or anybody else. Zuleika 09:48, 26 April 2011 (PDT)

PS removal of the little link icon is easy, via the class "plainlinks". Rather than fix this above, I refer interested readers here. Zuleika 18:58, 4 May 2011 (PDT)

Image and list

I note that the Flickr image template includes plainlinks; you don't get the logo if you insert pictures using it without a div. That's what I usually do, unless I'm setting out an arrangement of more than one picture.

A thing I've tripped over a couple of times though is the effect of a left-aligned image on a bullet list next to it. Some of my contributions have been little more than a picture and a bulletted list of specifications.

Suppose I want this list:

Random list:

  • Drinks
    • Coffee
    • Orange juice
  • Food
    • Cinnamon and raisin bagel
    • Soft cheese
    • Blackcurrant jam

I insert it with

Random list:

* Drinks

** Coffee

** Orange juice

* Food

** Cinnamon and raisin bagel

** Soft cheese

** Blackcurrant jam


If you just insert the picture with the template, and no div, you get this:


Random list:

  • Drinks
    • Coffee
    • Orange juice
  • Food
    • Cinnamon and raisin bagel
    • Soft cheese
    • Blackcurrant jam


I guess the bullets are placed beyond what is regarded as the left margin of the text. If you insert the Flickr image template inside a div started with <div class=floatleft plainlinks> you get this: the bullets disappear.

Random list:

  • Drinks
    • Coffee
    • Orange juice
  • Food
    • Cinnamon and raisin bagel
    • Soft cheese
    • Blackcurrant jam


If you specify the margins in the start of the div it's better, and would be fine for a single-level list. This is started with <div class=floatleft plainlinks style="margin:0px 20px 5px 0px">: you can see the bullets, but it still loses the division into levels.

Random list:

  • Drinks
    • Coffee
    • Orange juice
  • Food
    • Cinnamon and raisin bagel
    • Soft cheese
    • Blackcurrant jam


Finally, this one is started with <div class="plainlinks" style="float:left; margin:0px 20px 5px 0px">. It's no different.

Random list:

  • Drinks
    • Coffee
    • Orange juice
  • Food
    • Cinnamon and raisin bagel
    • Soft cheese
    • Blackcurrant jam


In the unlikely event that I want a two-level list in this situation, anybody see what's wrong?--Dustin McAmera 09:12, 7 May 2011 (PDT)

Attempt

Random list:

  • Drinks
    • Coffee
    • Orange juice
  • Food
    • Cinnamon and raisin bagel
    • Soft cheese
    • Blackcurrant jam

Comment: This is only a solution for special page designs. next attempt

Random list:

  • Drinks
    • Coffee
    • Orange juice
  • Food
    • Cinnamon and raisin bagel
    • Soft cheese
    • Blackcurrant jam

O yes, that is a valid solution for a real problem we have had on page Kodak.U. Kulick 09:39, 7 May 2011 (PDT)


Excellent! Thanks for that! :) --Dustin McAmera 10:02, 7 May 2011 (PDT)

Quoting attribute values

I hesitate to revise this page, because I disagree with the use of table markup for what needn't be a table. Would it be OK though to put attribute values in quotation marks?

If you're interested, see this on the practical benefits. Quicker: see the explanation of error 82 here. Both of these are general, and indeed the former is intended for HTML 4.0, in which quotation marks may be skipped. In XHTML, they may not be skipped; see Wikipedia's list of "Common errors" in XHTML. Now, adding quotation marks around attribute values is surely part of the job done by HTML Tidy during the conversion by MediaWiki of wiki text into what's served to the browser. But this job should be kept as simple as possible. Zuleika 19:10, 4 May 2011 (PDT)

MediaWiki corrects unquoted attributes by adding quotes. What was wrong in the samples above? <div class= floatleft plainlinks > did not work w/o quoting "floatleft plainlinks". Automatic XHTMLization works only with simple value attributes!U. Kulick 10:05, 7 May 2011 (PDT)
Hang on a bit. My text in the section above says I didn't put quotes around floatleft plainlinks, and I didn't. I tried doing so before putting my question here (I mucked about in the sandbox), and noticed that it doesn't make any difference to the result. Uwe has added quotes to the code in my examples, in the revision at 18:01, but not to my commentary (so the examples now have double-quotation marks round floatleft plainlinks, but the accompanying text doesn't). Maybe you're not talking about my problem here; but I don't see any difference in the result from what I had without the quotes (I had to check whether it was me that left my commentary not matching the examples); so the presence/absence of the quotes wasn't the issue (right?). Anyhow, my point is I don't think these particular quotation marks are relevant to your quarrel, although I like Uwe's solution, and I have no strong feelings about using a table to get a solution to my problem. No offence intended, but I'm now going to take out the added quotations in the section above; right or wrong, the code and the commentary on it should match, just in case anyone else reads it.--Dustin McAmera 10:46, 7 May 2011 (PDT)
Sorry, but Zuleika mentioned a source "XHTML#Common_errors" and I sought for the related fault in our samples. I saw that because it is a common error of mine too: to forget quoting the classes. I guess nobody forgets quotes when using a style attribute. The class attribute is a little more abstract. Of course quotes would never be forgotten if we would use quotes simply for all attribute values. I checked the resulting HTML and found that only one of the classes were used where two were defined by You w/o quotes.U. Kulick 11:10, 7 May 2011 (PDT)

U. kulick asks "What was wrong in the samples above?"

If "above" means the material that I (as Zuleika) had written, then as I pointed out it's explained here even for HTML, which in principle doesn't require quotation marks. By contrast, XHTML does require quotation marks. Yes, the HTML Tidy stage of the conversion may put in quotation marks where required, but HTML Tidy cannot read authors' minds and therefore at times makes mistakes when fed seriously faulty code. When the code is almost right, it does a better job.

Yes, content and commentary should match. They should be consistent either one way or the other. Here there's a right way and a wrong way, so it seems perverse to regularize the wrong way.

And this has nothing to do with the question of how much tables should be used for material that isn't inherently tabular.

U. kulick: "Of course quotes would never be forgotten if we would use quotes simply for all attribute values."

No, they would still be forgotten from time to time, because all kinds of errors are made from time to time. But I think that they might well be forgotten less if the prescription to use them were given simply.

I got this right in "Attributes". I shall be very annoyed if that too is altered for the sake of consistency with a wrong idea, rather than consistency with the facts. (I did not add there that the quotation marks needn't be double and could instead be single, and I didn't give the reasoning for the use of quotation marks, because that's a help page for a wiki, and not course material.) -- Hoarier 17:00, 7 May 2011 (PDT)

Br template

We're told:

The template {{br}} (giving a page break) can be used as "prefix" to move the table of images [...]

It's not a page break, it's an elaborated line break. (Though this was probably just a typo.)

If you want a title to clear what's above, you can just stick style="clear:both" in the right place within it. (Or if there's already a style attribute there, then you can add "clear:both" to it, separating this from any other declaration with a semicolon. There's no need for a line break.

But of course this glorified line break is easier to remember and to type. Fair enough. However, I infer both from my understanding of the theory transclusion versus substitution and from a message titled "transclusion vs substitution" sent to the camera-wiki list at 03:39 on 23 April 2011 that substitution ({{subst:br}}) would be preferable. Zuleika 19:22, 4 May 2011 (PDT)

Personal tools
Namespaces

Variants
Actions
Navigation
External
Tools