That question is kind of overly broad, as it essentially asks to explain all ways a floppy image can be composed and written - which is next to infinit. A short search may turn up quite a lot of hits.
So I'd like to focus on that 'nibble copy' part:
'Bit nibbler' (*1) is a term coined in times of GCR for what today may be called 'raw copy'. It describes access to disk data based on magnetic flux changes, in sequence as they are written. While used on many platforms, it was especially popular on the Apple II, as it's disk system was almost entirely software defined. A fierce race between protection schemes and copy programs lasted over the whole time the Apple II as mainstream machine.
Lock Smith is still one of the best known ones. It was the first (widely known) program that did not copy logical data by using the standard RWTS (*2) routine, the lowest level of DOS access, but reading and reproducing the raw, GCR data.
Lock Smith made its name by constantly improving - from simply nibble wise copy all the way to track timing and orientation. But it wasn't the only one. There was a whole armada, from rather plain COPYA and COPY II all the way to NIBBLER and BACK IT UP. In fact, when copying disks - at least in a more than 'one a month' fashion - one had to use a wide variety of programs, as each had its advantages - including plain copy programs, as not every disk of a set was protected to the max. Plain (DOS based) programs had the advantage of needing less memory to hold the image, so a copy could be done faster than with programs that had to handle nibbles.
In addition, while these programs were good at automatically copying many default schemes, one still had to figure out the details for each disk, and often different schemes for different tracks.
So for ... well, let's say "less casual" operation, one had to make notes, create a data base on how to copy which disk. This was mine:

*1 - initially often written as 'nybbler'
*2 - Read or Write Track and Sector - the very basic routine DOS provided to access and en/decode a 256 byte sector.